Frameworks

I must admit to having been excited at the prospect of the Pet Market frameworks project when Simon proposed it to us at the Fusebox & Frameworks Conference in September. I once tried to do something similar by creating a small blog application using the three popular frameworks that I was aware of at the time (Fusebox 3-4 and Mach-II) and the onTap framework.

Unfortunately I did all the work myself and didn't have a great venue like the ColdFusion Developer's Journal to publish the results. In the end I think my efforts at a useful comparison of frameworks fell short of what I'd hoped. Naturally I'm excited to see Simon take the initiative to enlist the aid of various framework authors and publish the results in the journal. Although I personally lament the fact that the Pet Market application isn't perhaps an ideal medium to demonstrate the unique strengths or advantages of some frameworks (not only the onTap framework, although in my case display tools in particular spring to mind), I do believe the Pet Market application provides probably the best neutral ground for comparison.

My own conversion of the Pet Market application took a bit longer than I expected. At first I thought it was good that the Pet Market application was designed purely for demonstration purposes and wouldn't be used in a production environment.

On further reflection I wonder if perhaps the opposite is true - that the original application is worse for its attempts to educate programmers new to ColdFusion because anyone using it as a learning tool is apt to learn some bad habits. Here are a few examples of what I mean: no primary keys or foreign key constraints in the database containing many related tables (no enforcement of referential integrity); display code executed in a domain-model CFC; and serpentine multi-step form templates containing both form display and post logic in the same file. I'll omit my complaints about the way in which multiple historical postal addresses are stored. Having said all that, here's an application ripe for the kind of structure any good framework will provide.

A Statement of Benefits
Here's a brief list of the benefits I've found using the onTap framework to reinvent the Pet Market application in no particular order.

• Eliminated code while simultaneously adding functionality
• Replaced ad hoc queries with Object Relational Mapping (ORM) and vendor-agnostic SQL abstraction
• Convenient caching of domain-model objects (products, categories, etc.)
• Products in the shopping cart are locale-specific, dictionary-order sorted (i18n)
• All files located in a single parent directory (no CustomTags directory or other external resources)
• Elimination of the custom tag for the application's layout (individual content templates don't reference the layout tag/template - decreases coupling of the content and format)
• Automated branding of images (home page graphics differ from the remaining site)

Due to time constraints and project requests from Simon, I was unable to implement any of the XHTML or form-management and validation features of the framework and as a result can't list them as benefits in using the framework in this instance although under normal circumstances I would have. The onTap framework's form tools would have replaced a fair amount of custom form validation code in this application in a manner that provides identical client-side and server-side validation with very little coding on my part. The XHTML features would have also provided a more modular method of generating the display, allowing anyone who might license my application to easily modify the display without editing any of my code, eliminating headaches related to later upgrades of my original software.

A Place for Everything and Everything in its Place
Because the onTap framework is designed to take advantage of directory structures, getting started with the migration of Pet Market to this framework is easy. First I created a /petmarket/ directory under my framework application root directory in which the Pet Market sub-application would execute. In this directory I put a copy of all the ColdFusion templates in the original application's /wwwroot/ directory. I could have put these templates in the framework root directory, although I didn't want to create a separate copy of the onTap framework core (3MB) for only the Pet Market application, so I created the subdirectory so it could execute as a sub-application under my existing framework installation. Then I copied the new /petmarket/ directory also into the framework /_components/ directory to mirror the root directory. Files in the root directory will be directly accessible to browsers, while files in the /_components/ directory won't (they're protected by an Application.cfm template). Once these files are copied, I replace the contents of each of the templates in the root /petmarket/ directory with a one-line cfinclude tag to drive the framework content:

<cfinclude template="#request.tapi.process()#">

This sort of minimalist index template should be familiar to anyone using Fusebox, Mach-II, Model-Glue, or the Hub. What's different in this case is that we have many Web-accessible templates instead of having all page requests routed through index.cfm.

To be fair the same can be done also with any of these other frameworks, although the other frameworks are rarely implemented this way because they don't inherently gain any noticeable benefit from using this structure and as such it's generally easier to simply route all requests through the index.cfm template. However, with the onTap framework the name of the base template is used as a part of the execution path to determine which templates are executed by the framework. So using cart.cfm has an inherently different result than using index.cfm as the base template. Of course there's nothing preventing you from routing all requests through index.cfm, although using this multi-template strategy let me migrate the application more quickly thanks to not needing to edit any of the links, form targets, or cflocation tags in the application. Had I used any of these other frameworks, which use form/url parameters and XML configuration files to direct their execution, they would have required that I edit every URL in the application to add the appropriate event parameter (FuseAction, event, etc.).

Although I chose a directory structure that let me ignore URLs in the application, I chose not to take the same approach with images. Although I could have simply left the Pet Market images in the /ontap/petmarket/images/ directory and ignored any image tags in the application HTML, the framework provides some added features with regard to images and for this reason I decided to put the images in the framework's designated image directories.

Yup, multiple image directories.

Although most HTML applications put all images in a single directory, the onTap framework provides a method of easily targeting methods contextually to provide simple branding and replacement of images by context. Interestingly enough, the Pet Market application provides a perfect example of why I included this feature in the framework in spite of the fact that the original Pet Market authors never imagined that I would write this framework revision: more evidence that this is a good feature to have.

When you view the Pet Market application in a browser, you'll notice that the layout presents several images of different animals at the top, linked to category pages for the various categories of pets, such as dogs, cats, and reptiles. As you browse through the application, however, you might notice that a different set of images is presented on the home page than on any other page in the application. In the original application, the location of this image was tightly coupled with the layout custom tag: the layout tag contained logic to determine if the current page was the home page and displayed a different set of images (including the size of the image as part of the name of the graphic file). I put copies of each of these smaller five images in the directory /ontap/_components/petmarket/_images/category/ for most pages in the application to use, renaming them to remove the image size from its file name. This makes the image name succinct and canonical and the name of the image file accurate, even if the size of the image changes later. Then I copied the five larger images to the directory /ontap/_components/petmarket/index/_images/category/ for the home page to use with the same succinct file names.

Throughout the HTML for the application I then replaced all image tag SRC attributes with the function request.tapi.getIMG() containing the name of the target image. This function checks a series of nested image directories and returns the URL to the first image it finds. So when the layout requests request.tapi.getIMG("category/dogs.gif") it will use the image located in /petmarket/index/_images/category/ on the home page and on every other page it will use the image located in /petmarket/_images/category/.