Why I’d Like To Make The Sexy With Transfer

Ok, so the other night, I opened the sample Transfer/Coldbox application for the first time. It was pretty simple looking, and I had it up and running in minutes.

The first thing I noticed was THERE WAS NO MODEL DIRECTORY! This messes with my head. I like seeing my application visually broken up into MVC. When I don’t see it, I get a little flustered, hunting around for the different components’ locations. Where are they???

Anyway, the first thing I opened was transfer.xml.cfm. Nothin’ much goin’ on there. Looks like the usual..

Next, I went to transfer.xml.cfm. What’s this?

<package name=”users”>
<object name=”users” table=”users” >
<id name=”id” type=”UUID” generate=”true”/>
<property name=”fname” type=”string” nullable=”false” />
<property name=”lname” type=”string” nullable=”false” />
<property name=”email” type=”string” nullable=”false” />
<property name=”create_date” type=”date” ignore-update=”true” />
</object>
</package>

Ok, I can tell that looks like a table definition. I run the sql file in mySQL and sure enough, there’s my matching table. This guy is defining the DB table in this transfer xml file. Neato!

Next, I open up ehGeneral.cfc, which is our handler:

<!— Create our Transfer Factory —>
<cfset var DSFile = getSetting(“TransferSettings”).datasourceFile>
<cfset var TFile = getSetting(“TransferSettings”).transferFile>
<cfset var Definitions = “/” & getSetting(“AppMapping”) & “/” & getSetting(“TransferSettings”).Definitions>
<cfset var TransferFactory = CreateObject(“component”,”transfer.TransferFactory”).init(DSFile,TFile,Definitions)>
<!— Place in Cache Indefinetely —>
<cfset getColdBoxOCM().set(“TransferFactory”,TransferFactory, 0)>

That looks simple enough. I know from my dealings with Coldbox, we can initalize a singleton in application scope, just like we do with onApplicationStart() in Application.cfc.

In onRequestStart(), we have this line, which makes the Transfer factory object available every page request:

<cfset rc.Transfer = getColdboxOCM().get(“TransferFactory”).getTransfer()>

Next, I open up the users.cfc handler. I spot this gem:

<cffunction name=”doAdd” access=”public” returntype=”void” output=”false”>
<cfargument name=”Event” type=”coldbox.system.beans.requestContext”>
<cfset var rc = event.getCollection()>
<cfset var oUser = “”>
<!— Get Transfer Object —>
<cfset oUser = rc.Transfer.new(“users.users”)>
<!— Populate it with RC data —>
<cfset getPlugin(“beanFactory”).populateBean(oUser)>
<!— Add new User —>
<cfset rc.Transfer.save(oUser)>
<cfset getPlugin(“messagebox”).setMessage(“info”, “User inserted”)>
<!— RElocate to listing —>
<cfset setNextRoute(“users/dspUsers”)>
</cffunction>

Hmm… looks like it’s creating a new user object for us to use.  Then it’s being populated with data. Oh, and we’re not writing SQL. It’s just DOING it for us. Cool!

What does all this mean? I guess it means this (Note these are random thoughts as I think, and sometimes my thoughts don’t sound like I put much thought into them, you think?):

1. We have no model because Transfer IS the model. It builds the model on the fly. Any getters/setters are created by Transfer as data is processed and/or requested.

2. If my client wants a new field (NAWWWW! Clients never do that!), I can simply add it in the object’s mapping in the transfer xml file, and add the item in the form of course. I’m done. Since I’m not writing queries, and Transfer is basing its DB interaction from the object mapping, it will automatically expand/contract to whatever is defined in the object mapping.

So what did I do next? What any logical-thinking person would do  – I built my own example. I added a new cars table. A new cars.cfc handler. And a new cars object mapping in the Transfer xml file.

Hey, it worked! I look forward to diving into this more as I build the new Code Scan Tool project.

If I’m wrong on any of my conclusions here, please correct me. I don’t want to disseminate (Spelled right?) any misleading information.

Poof!