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.

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.

Once registered for these events, the Transfer object must implement the following methods.

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.

I'm pretty new to Ant, so I'm thankful that a lot of other developers have examples and sample build files that I can use as a guide to learning Ant. After writing a few small build files, I wanted to tackle something a little more ambitious. I like to keep all the frameworks that I use up to date from their respective repositories, and, when deploying a new site or project, I will typically include the framework dependencies as a minimal include at the project root. This requires a bit of work, exporting and stripping out documentation, examples and tests from my local checkout of the framework files. As a learning objective, I decided to write an ant build file to maintain my own "nightly build" of each framework customized to carry only the core files.

[More]

I really picked a winner for my first Coldfusion conference. Unfortunately, I wasn't able to attend every session that I wanted, so I guess I'll have to come back next year! It's really hard to pick a favorite, but the Agile, Coldspring and Coldbox workshops all stand out.

Over and above the excellent content and presenters, I got to meet and hang out with some really great folks. I'd start name dropping y'all, but you know who you are...

The evening meals had a lot of variety. First there was the fabulous Brazilian churrascaria steakhouse Fogo de Chao, then two classics White Castle and Mickey's Diner, and finally the wonderful Sakura topping it off.

Big thanks to Jared, Steven and the entire steering committee for putting on a great conference!

Transfer ORM is, as the name implies, an object relational mapper for Coldfusion. Transfer has a myriad of advanced features which can be intimidating for newcomers. Fortunately, Transfer can be installed and used very easily without learning some of the more advanced features. What follows are instructions you can use to install, configure and use transfer in a few simple steps.

Installation

UPDATE: Release Candidate 1.0 is now available.

The last official release of transfer is 0.6.3. This version is now quite old and it is recommended that you use the bleeding edge release (BER) from subversion. If you have any misgivings about using the BER, rest assured that many production systems are running the transfer BER. It's stable.

To install the transfer BER, point your subversion client to http://svn.riaforge.org/transfer and checkout or export the source from /trunk/transfer. You can either set a mapping for "/transfer" in the cf administrator, or drop the source transfer folder in your web root.

Configuration

To use transfer in an application you'll need to setup two configuration files. One for the datasource that transfer will use and another to describe the objects that transfer maps from your relational database. These files are typically named Datasource.xml and Transfer.xml, but you can use any name you like and/or append a .cfm extension to prevent the files from being visible in a web browser.

Datasource.xml

The transfer datasource.xml config specifies the values for the following:

- a datasource name that currently exists in the cf administrator - a username (if required - leave blank otherwise) - a password (if required - leave blank otherwise)

Transfer.xml

The transfer.xml file is used to define the properties and relationships of transfer objects that are mapped to the relational tables in your database. Objects can have onetomany, manytoone, or manytomany relationships. The following xml is the object definitions from the tBlog sample app.

Integration

Using Transfer with Coldspring

Using transfer as an application scope "singleton".

Usage

To grasp the full breadth of the transfer API, you really need to review the Transfer docs. I'll cover the four methods you will likely work with the most in the beginning. They are, get(), new(), save() and delete().

Using the tBlog object definitions above, to retrieve a post object use:

To have transfer return a new instance:

To modify and save a new post:

A small, but significant, benefit of using Transfer ORM, is that when you save an new object the object's state reflects it's new persisted state. So you can find out the new id by simply calling.

Lastly, transfer delete() method works like save(), you pass the transfer object to the method.

Much, much, more

This quick start is intended to help impatient types (like myself) get a taste for how simple it is to start using Transfer ORM. As you become comfortable with the Transfer API, you will definitely want to explore features like Transfer Object Decorators, the Transfer Event Model and Transfer Query Language (TQL). Mark Mandel has put a great deal of effort to into Transfer since it turned POSS. If you are not comfortable using the bleeding edge source code from subversion, keep an eye out for a 1.0 Release Candidate.

I've finally decided to stick with a theme for my first CF conference. The goal is to increase my frameworks acumen and better my development methodology. So with that in mind, here's my cf.objective() schedule. Let's hope it sticks.

Thanks to all the folks who have read and commented on this blog over the past year. I've met a lot great people and learned more than I imagined.

A quick review of my stats for the year shows 44 posts with an average of 865 views and just under 2 comments per post. The top three categories are ColdFusion, ColdSpring and Transfer. I started blogging to share my learning experiences and ideas. Year two will be a lot more of the same. :)

If you are into Unit Testing and haven't yet heard of MXUnit, I definitely recommend giving it a whirl. Some things that stand out for me, thus far in my evaluation, are the simple, but extensible, assertions, the ecplise plugin, and the debug output. One gotcha that has come up for people when using the eclipse plugin, is that is was designed assuming that the package path to your components resolves directly from your web root. For people who run separate server instances, virtual machines, or develop locally with Apache virtual hosts, this is a show stopper. Luckily, for folks, like myself, who prefer to develop locally with Apache, getting the MXUnit eclipse plugin to work is simply a matter of adding a couple of Alias directives to your vhost.

[More]

Now that I'm on a CF8 hosting plan, I've started leveraging some of that goodness in my applications. The first thing I have implemented is application level mappings to keep my configuration files and components out of the web root. Here's how my current project layout rolls.

/project
  /config <-- Coldspring and Transfer config files
  /model <-- model components
  /root <-- web root
    /admin  <-- secure admin screens

Basically, I want to create mappings to config and model. I did a little googlin' and found a nice snippet on Sean Corfield's blog on looping over a list to build the mappings. I aped that code with a slight mod for my setup.

I dev on Mac and deploy on Windows and my local folder structure is slightly different from my host. The first part of the code is just a test of whether the site is being served up locally. When on the production server, the mapped folders are in a folder with the same name as the app.

This is a great alternative to using Apache Alias or Virtual Directories in IIS for mappings. That is, until I tried using the mapping from within the admin folder. Suddenly the path was not recognized. I initially thought this was a transfer issue, but that was not the case. I tried several variations and workarounds. Eventually, I figured out that the mappings were fine for files in the web root where Application.cfc resides. So why was the path not available to files in a folder below the web root? The answer was pretty simple. The admin folder had no Application.cfc, thus no mappings.

Remembering another gem by Mr. Corfield regarding extending Application.cfc via a Proxy, I created an Application.cfc in the admin folder and the required proxy in the web root. Instead of repeating the code for creating the mappings with only the path prefix changed, I wrapped the creation of mappings up in a method.

And call it from the Application.cfc in the admin folder using the appropriate prefix.

Application level mappings are handy, but the per directory limitation does not make for a tad more code. Overall, I think it's a small price to pay for the benefit gained.

UPDATE:

I sat in on John Mason's Testing with cfcUnit ColdFusion Meetup presentation a few days ago. Not only did I learn a few new things to help me with unit testing, I found a new ColdFusion host.

There were a few things that sold me on FusionLink as a provider. They've been in business longer than I've been a ColdFusion developer, they encourage secure connections for ftp, pop3, smtp, and databases, and they bundle a subversion repository (also under ssl) with the plan. Changing hosts is not something I do on a whim. There's a lot of work involved. Fusionlink made the migration a breeze. The only hiccup in the entire process was that my domain was locked and I had to wait to change the DNS server settings. If you're looking for ColdFusion hosting, do yourself a favour and check FusionLink out.

Yesterday, I asked Mark Mandel for some advice on tuning my object model for performance. Mark, being an ever-so-helpful (P)OSS author, gave me a few suggestions. Turns out that someone asked basically the same question on the transfer list today. Jaime Metcher made a couple of excellent points on choosing between queries and object composition. Paraphrasing, Jaime, when working with large data sets (the type of thing you might be tempted to use arrays of objects for), you will get better performance using a query. If you want to display a single instance of some object and the view is truly a composite, then your model should reflect that composition. Understanding this helps with choosing between onetomany or manytoone relationships for your object compositions.

[More]