So you want to use Transfer ORM in your ModelGlue:Unity application (Part 1)

Previously, we connected Transfer ORM into our ContactOMatic application. Now, we will use it to get some things done! The completed files for this exercise are included at the bottom of the post, just click on the 'Download' link.

Using Transfer with MG:U is quite different than hand coding all the data access instructions so I separated out the new Transfer enabled code from the old hand coded bits to help compare similar operations between the two styles. This means the ContactOMatic is not an example of Architectural Purity! Shock! Horror! Gasp!

To make the separation, I added another ModelGlue configuration file, named ContactAction.xml, to the main ModelGlue.xml file through the use of the include tag as follows:

view plain print about
1<include template="/ContactManagerMG/config/ContactAction.xml" />

Note: I also created another directory in ContactManagerMG/views called Section2 which holds the Contact Profile. If you are coding along at home, you should create the directory and add the new directory path to the viewMappings property of your ModelGlueConfiguration located in /ContactManagerMG/config/ColdSpring.xml.

Another Note: Remember to set your application reload setting inside /ContactManagerMG/config/coldspring.xml to true. You also may need to add &init=true to your url to trigger the initial application configuration reloading.

The Include command appends the configuration data to the parent configuration. I use this often to keep my ModelGlue configuration files nice and small.

The ContactAction.xml file contains a single event, Contact.Profile. In the broadcasts declaration section of the event-handler, note the use of the GDM (Generic Database Messages). GDMs are covered extensively in the ModelGlue:Unity documentation. The ModelGlue:Unity documentation is quite good and covers all 4 types of Generic Database Messages; List, Read, Commit, Delete. Here is the code for the Contact.Profile event-handler:

view plain print about
1<event-handler name="Contact.Profile">
2            <broadcasts>
3            <message name="modelglue.GenericRead">
4                <argument name="object" value="Contact" />
5                <argument name="criteria" value="ContactId" />
6            </message>
7            </broadcasts>
8            <views>
9                &lt;include name="body" template="ContactProfile.cfm">

10                    <value name="whichMenuIsCurrent" value="home" />
11                </include>
12            </views>
13            <results>
14                <result do="view.template" />
15            </results>
16        </event-handler>

Our GDM example in the ContactOMatic is a top level instruction to the ModelGlue framework to load the specified object, a Contact, and expect a filter criterion called 'contactID' to be present in the event scope. The final result of the GDM is a hydrated contact object correlated by the Primary Key of the value of ContactID in the event object. This object is then placed into the event scope, marking the end of the GDM read operation. In ContactManagerMG/views/Section2/ContactProfile.cfm you may see how the object was pulled from the viewstate scope and used to populate the Contact Profile.

Additionally, the Contact Object is configured with a ManyToOne relationship to Contact Type. Access to the ContactType is like so:

view plain print about
1Type: #Contact.getContactType().getContactType()#
2--------- Non-OO translation --------
3The Contact Object has a ContactTypeObject that will get the Contact Type for this Contact

Finally, on the topic of architecture, the use of dependent libraries and frameworks can be an issue in some environments. Thus the use of Generic Database Messages in ModelGlue allows the ORM implementation to be decoupled from our application. What this means is that although my application now depends on Transfer to function, in reality it only depends on ORM functionality accessed through the ORMAdapter and located by the ORMService components. This is an important distinction because should another super cool ORM named 'Persist' (You know who you are) come on the scene, I can swap ORMs by simply creating an adapter to plug the Persist ORM to ModelGlue.

GDMs are one way to use Transfer in our ModelGlue:Unity application. In our next series, we will cover other means of leveraging TransferORM for fun and profit.

Download Download

There are no comments for this entry.

Add Comment Subscribe to Comments

3/24/08 1:10 AM # Posted By udip

Dan, I downloaded the code and tried to run it without any changes
for the url http://localhost:8500/contactmanagerMG/index.cfm?e.... I am getting an
error.., any ideas??

Message    The method getContactType was not found in component C:\ColdFusion8\wwwroot\transfer\com\TransferObject.cfc.
Detail    Ensure that the method is defined, and that it is spelled correctly.

3/24/08 1:20 AM # Posted By udip

I think I figured out the earlier problem all I had
to do was to enter contactid in the url..
so for my case http://localhost:8500/contactmanagerMG/index.cfm?e...

3/24/08 2:52 PM # Posted By udip

Dan have you done form validations using Transfer? if so can you post an example..

4/16/09 6:35 AM # Posted By Joe

Am getting error:

   Element MEMENTO.CONTACTID is undefined in ARGUMENTS.

when click the name URL from the contacts list

9/23/09 4:23 AM # Posted By Philip Bedi

I am still getting following error even i added contactid in url

The method getContactType was not found in component C:\Users\philip\Downloads\transfer_v1.1\transfer\com\TransferObject.cfc.
Detail    Ensure that the method is defined, and that it is spelled correctly.
Extended Info    
Tag Context    C:\sites\ContactManagerMG\views\Section2\ContactProfile.cfm (17)

11/19/13 6:29 AM # Posted By Sebastiaan

Hi Dan,

Have you gone any further with this tutorial? Cannot seem to find anything more on Transfer ORM ;-)

The previous ten episodes were good to walk thru, thanx!

Add Comment Subscribe to Comments