Transfer ORM Event Model Examples - BeforeCreate and BeforeUpdate

2008 May 21
tags: Learning · Transfer
by Paul Marcotte
The topic of how one might track created and modified dates came up on the transfer list today and Brian Kotek mentioned how he uses the transfer event model to track changes when creating or updating Transfer objects. I thought it might be interesting to see just how easy it would be to implement his approach. The transfer event model is an implementation of the Observer/Observable pattern in which one object registers itself to listen for events from another object. When an event occurs on the observable object, the observer (a.k.a listener, or subscriber) is notified. The transfer event model currently supports seven events, each of which require the observer to implement a specific "listener" method. Here's how I decided to implement Brian's approach.

CAVEAT LECTOR I rushed this post out without thinking through the implementation. This is an incorrect and possibly dangerous way to use the transfer event model. Please see Bob Silverberg's post on this topic.

I define a configure() method within all of my transfer decorators. Configure() is invoked when a transfer object is instantiated. This makes it a perfect candidate to add additional behaviour by registering the Transfer object to listen for specific events. In this example I'll setup the transfer object to listen for the BeforeCreate and BeforeUpdate events. <cffunction name="configure" access="public" output="false" returntype="void">
<!--- register for transfer events --->
<cfset getTransfer().addBeforeCreateObserver(this)>
<cfset getTransfer().addBeforeUpdateObserver(this)>
</cffunction>
Once registered for these events, the Transfer object must implement the following methods. <cffunction name="actionBeforeCreateTransferEvent" access="public" returntype="void" output="false" hint="I set the created date before I am persisted for the first time.">
<cfargument name="event" hint="The event object" type="transfer.com.events.TransferEvent" required="Yes">
<cfset setCreatedDate(now())>
</cffunction>

<cffunction name="actionBeforeUpdateTransferEvent" access="public" returntype="void" output="false" hint="I set the created date before I am persisted for the first time.">
<cfargument name="event" hint="The event object" type="transfer.com.events.TransferEvent" required="Yes">
<cfset setModifiedDate(now())>
</cffunction>
Assuming that we have two properties on our Transfer object for CreatedDate and ModifiedDate, setting those values is now nicely de-coupled from a service or controller layers. Which is one of the reasons I really like using transfer decorators. Additionally, if you are in the habit of creating these properties on all your business objects, you could place these methods in a base decorator and call super.configure() within the configure() method of your transfer decorator.