Posted By : Dan Wilson     August 27, 2007 8:45 AM

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:

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:

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:

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

There are no comments for this entry.

Add Comment Subscribe to Comments

Add Comment Subscribe to Comments