ColdFusion Architecture For RIAs - Part 2

This is the second of a series of four blog entries I'm writing to demonstrate CF in a RIA architecture. In the first entry, I introduced the simple CF version of an address book application. In this installment, we'll examine what changes need to be made to that code base in order to make it work using an AJAX client.

I'll begin by stating that, to keep with the Adobe technology theme, the AJAX functionality that ships built-in to CF 8 was chosen. These CF AJAX server enhancements were fairly well received by the CF developer community and from what I can tell were very well received by Adobe's CF clients, and I don't think anyone was surprised to see AJAX support added to the server. That said, my personal experience with the CF 8 AJAX functionality so far has left a bad taste in my mouth - at least with regards to the tags that generate an AJAX UI. As soon as you need to make them do something that isn't natively supported via the tag attributes, developers find themselves banging their head against the wall. It's that same old "trying to fit a square peg into a round hole" feeling that I run into from time to time with frameworks, CMS products, and even CFML itself on some occasions. There are a lot of excellent AJAX libraries out there and in my experience developers are often times better off downloading, learning, and using one of those... but I digress.

For this version of our address book application we have two objectives: re-use what we can from the first version of the code (http://www.horwith.com/downloads/abook-cf.zip) and offer some RIA benefits/characteristics by taking advantage of ColdFusion AJAX support. You can download this code at http://www.horwith.com/downloads/abook-ajax.zip. To test, first extract the zip file to a web root served by ColdFusion. If you haven't run the first version of the application on your server yet, you'll want to download and follow the instructions for that application in order to configure your database and datasource. You can browse the application simply by browsing the "index.cfm" file in the "abook-ajax" directory created when you unzipped the compressed file. You'll notice a few differences in the interface. The address book entries are all displayed in a pretty JavaScript grid. The entries are paginated for you, with nice navigation controls for moving around the pages... moving from page to page does not require refreshing the page in your browser. The A-Z links are still there, and work as before, but again we no longer refresh the page. The "Add Entry" button now displays a virtual window with a form, that you can submit, drag around, or close. Also, the "Edit" links have vanished - you can edit records directly inside the grid that displays them. Definitely a nicer interface.

So how did the code need to be modified? First let's look at the UI. For starters, the 'entry.cfm' file from the first version has been deleted and the form moved into a CFWINDOW in index.cfm for in-line use. Index.cfm has an ajaxproxy at the top, so we can communicate with the server from JS. The HTML table has been replaced with a CFGRID which gets it's data via the 'bind' attribute. Several JavaScript functions, all which very simple, were added to the page - primarily for refreshing the grid (via methods of the ColdFusion.Grid object) and for interacting with the add entry window (via methods of the ColdFusion.Window object). At the bottom of the page, the CF8 ajaxOnLoad() function is called to populate the grid when the page loads.

The 4 ColdFusion Components from the first version of the application are all still required for the AJAX version - and none of the 4 were changed in any way. What has changed is the addition of a 5th CFC, 'addressbookintrepretor.cfc', which is a simple implementation of the facade pattern. This CFC accesses the user's address book the simplest way possible - by directly referencing the session scope. Not a practice I generally encourage, but acceptable in a facade. There are 5 remote methods in the component - 3 of which just accept data and pass it to the address book (for deleting, adding, and editting entries). There's one entry that simply returns the current entry count (based on a filter) since the AJAX UI can no longer just reference the recordcount of whatever query is being displayed. The fifth method is the getEntries method which is used to populate (and re-populate when filtering) the data grid. This is the only method that actually has any AJAX-specific code in it - it takes the array of objects, converts it to a query, then returns the result of operating on that query with the CF 8 'queryConvertForGrid()' function.

The interface is inherentely a little prettier and the user experience is definitely more pleasant. If you've never used the CF AJAX functionality before, it takes a little while to add the code needed for this version - and if you don't know JavaScript at all it will take even longer... but for an application this simple anyone should be able to do what I did in a few hours (anywhere from 2-6 hours) with little prior experience. Were the enhancements worth the extra time? I don't really know, you tell me. What I will say is that since I'd written all the server side code and a simple HTML version already, I thought it was realistic to expect that I'd have time to add a nice interface for deleting gridrows and to write code to elegantly handle making the grid refresh and resort whenever I clicked on a header or add/edit/delete entries. Clickable headers alone is trivial, but as soon as you throw all the CRUD functionality into the mix, the amount of effort required increases to a number that, in my opinion, isn't worth it.