ColdFusion Architecture For RIAs - Part 3
This is the third 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 the second, we looked at how to use the built-in CF 8 features to create a version of that application that uses AJAX to improve user experience. Although in order to create a better user experience in each version of the application I'm writing a good deal of client code, the purpose of this exercise is to examine how much refactoring/effort is needed on the server-side to support the UI changes. In this, the third installment, I am now going to replace the CF driven HTML front-end with a Flex application.
Note, I was a little lazy and kept the code and the runtime files in the default Flex Builder directory structure. As with the AJAX version, 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 using Flex for the front end. You can download this code at http://www.horwith.com/downloads/abook-flex.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 "bin-debug/main.html" file in the "abook-flex" directory created when you unzipped the compressed file, though depending on how your environment is set-up you may need to recompile the source. The interface is now extremely different (duh, it's Flex, not HTML). The A-Z links are now A-Z buttons (I could have taken a "prettier" approach but this suffices for my needs) and there's a 'show all' button. Like I said, buttons aren't the pretties way to do this in Flex (nor the fastest, in all likelihood) - I just threw them in there like that real fast. The address book entries are all displayed in a pretty data grid. I could have easily paginated it but don't mind the default scrollbar behavior for data sets this small. You can edit entries inline in the data grid, but I didn't take the time to add delete or 'add new' functionality, though it wouldn't be much effort to do so. You may notice (though in an app. this small you also may not) that the data loads a little quicker than it did with the AJAX/HTML versions. That's largely due to the fact that Flex is smart (and sneaky) about when it draws things, and partly due to the performance benefits you get out of the box by using AMF (Flash Remoting) to talk with CF. Definitely a nicer interface.
So how did the server side code need to be modified? First let's look at the old server (CF/AJAX) UI. For starters, all of the '.cfm' files are gone - replaced with a single '.mxml' file that is our application. This file has a datagrid, populated when the app initializes, for displaying all of the entries, and functions for asking the server for the entries, adding a new, empty row (add), handling edits, and for filtering the displayed entries. Basically - it's a grid populated by an ArrayCollection, with a few UI elements and some functions for passing elements of the ArrayCollection back to the server. There's also a class (a data transfer object in the 'dto' directory) that represents an address book entry - the ArrayCollection is actually an array of these. Note that the DTO class file has a [RemoteClass] metatag - this maps my server-side addressbookentry object to the AddressBookEntry AS class so my custom object types translate seamlessly back and forth. Sorting and filtering is more efficient than in the prior 2 versions of this application, as Flex has native support for filtering and sorting content on the client.
The 4 ColdFusion Components from the first version of the application are all still intact in the Flex version - and none of the 4 were changed in any way yet again. What has changed is the addition of a 5th CFC, 'facade.cfc', which is a simple implementation of the facade pattern. Like the facade in the AJAX version, this CFC accesses the user's address book the simplest way possible - by directly referencing the session scope. There are only 2 methods (and barely any code) in the component - one method for retrieving all entries and one for adding/editting an entry. Though I haven't been as diligent in trying to optimize both approaches as I possibly should be, in my opinion integrating a Flex UI with CF is much simpler and more straight forward than with an AJAX front end.
Though this Flex application really doesn't do Flex justice in terms of it's capabilities, it does do a decent job reflecting how much more robust the interface can be and how much simpler it is to integrate ColdFusion with a rich client written with Flex.
Note, I was a little lazy and kept the code and the runtime files in the default Flex Builder directory structure. As with the AJAX version, 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 using Flex for the front end. You can download this code at http://www.horwith.com/downloads/abook-flex.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 "bin-debug/main.html" file in the "abook-flex" directory created when you unzipped the compressed file, though depending on how your environment is set-up you may need to recompile the source. The interface is now extremely different (duh, it's Flex, not HTML). The A-Z links are now A-Z buttons (I could have taken a "prettier" approach but this suffices for my needs) and there's a 'show all' button. Like I said, buttons aren't the pretties way to do this in Flex (nor the fastest, in all likelihood) - I just threw them in there like that real fast. The address book entries are all displayed in a pretty data grid. I could have easily paginated it but don't mind the default scrollbar behavior for data sets this small. You can edit entries inline in the data grid, but I didn't take the time to add delete or 'add new' functionality, though it wouldn't be much effort to do so. You may notice (though in an app. this small you also may not) that the data loads a little quicker than it did with the AJAX/HTML versions. That's largely due to the fact that Flex is smart (and sneaky) about when it draws things, and partly due to the performance benefits you get out of the box by using AMF (Flash Remoting) to talk with CF. Definitely a nicer interface.
So how did the server side code need to be modified? First let's look at the old server (CF/AJAX) UI. For starters, all of the '.cfm' files are gone - replaced with a single '.mxml' file that is our application. This file has a datagrid, populated when the app initializes, for displaying all of the entries, and functions for asking the server for the entries, adding a new, empty row (add), handling edits, and for filtering the displayed entries. Basically - it's a grid populated by an ArrayCollection, with a few UI elements and some functions for passing elements of the ArrayCollection back to the server. There's also a class (a data transfer object in the 'dto' directory) that represents an address book entry - the ArrayCollection is actually an array of these. Note that the DTO class file has a [RemoteClass] metatag - this maps my server-side addressbookentry object to the AddressBookEntry AS class so my custom object types translate seamlessly back and forth. Sorting and filtering is more efficient than in the prior 2 versions of this application, as Flex has native support for filtering and sorting content on the client.
The 4 ColdFusion Components from the first version of the application are all still intact in the Flex version - and none of the 4 were changed in any way yet again. What has changed is the addition of a 5th CFC, 'facade.cfc', which is a simple implementation of the facade pattern. Like the facade in the AJAX version, this CFC accesses the user's address book the simplest way possible - by directly referencing the session scope. There are only 2 methods (and barely any code) in the component - one method for retrieving all entries and one for adding/editting an entry. Though I haven't been as diligent in trying to optimize both approaches as I possibly should be, in my opinion integrating a Flex UI with CF is much simpler and more straight forward than with an AJAX front end.
Though this Flex application really doesn't do Flex justice in terms of it's capabilities, it does do a decent job reflecting how much more robust the interface can be and how much simpler it is to integrate ColdFusion with a rich client written with Flex.
There are no comments for this entry.
[Add Comment]