Frameworks

Neil Ross (pictured) writes: recently spoke to a group of attendees at the Fusebox and Frameworks Conference 2005 about the framework that I call TheHUB. Then when I was asked to write this article, I thought it would be a great way to compare and contrast it with several of the frameworks discussed at that conference. So I jumped at the chance to share my approach to developing ColdFusion applications.

I use a framework and methodology called TheHUB, which is an approach that I developed over the past couple of years, and I discussed the origins and motivations for this approach at the conference. The bottom line is that TheHUB is easy to learn, easy to use, and easy to maintain. It has a much smaller footprint than other application frameworks and is flexible enough to allow you to develop applications the way you want without adding lots of restrictions to the way you code.

The Basics
The first thing to understand about TheHUB is that all you're being asked to do is to conform to a pattern of application development. This pattern is similar to the development of a Fusebox application where you indicate a "fuseaction" for each request.

When following the pattern of development prescribed by TheHUB, you format your hyperlinks and form actions in such a way that you identify the template to be loaded by passing along the URL, a key/value pair that specifies a template to be loaded from a specific directory within the folder structure of your site or application. The analysis and processing of the request is implicit and there is a piece of core code that TheHUB uses to analyze the query string on your request and load the appropriate templates.

This approach leaves you, the developer, free to decide how to organize the code, for example, along the lines of what is display code and what is not or along the subject area line. This gives you flexibility as the application evolves and expands.

Preparing the ColdFusion Server
The "readme" file that comes with the downloadable Pet Market code includes the server setup information. You'll need to create your data source connection within the ColdFusion administrator. You'll also need to create a virtual directory in IIS or a virtual mapping in the built-in Web server. Do this by following the directions in the "readme" file included with the download. You'll edit the "jrun-web.xml" file to include the mapping to your Pet Market directory.

Preparing TheHUB
TheHUB has very few core files that are needed for the actual operation of an application. I actually removed several of the sample files that come with the download because I didn't need them for the application to function (see www.cfpetmarket.com). Now, when I do a file count and comparison I find that there were 100 files in the original application and only 102 in the converted application.

There are a few lines of code in the core files that you'll need to update. TheHUB relies on a variable called "request.frameworkhub" in order for an application to function properly. This variable is set within the "globals.cfm" within the "cmn" directory of the core files download for TheHUB and points to the page that you want to run all of the page requests through. The code within the "index.cfm' is pretty simple and just handles the include of the requested templates:

<cfinclude template="cmn/varhandler.cfm">
<cftry>
    <cfinclude template="#request.dir##request.tmp#.cfm">
<cfcatch type="missinginclude">
    <script>
    alert("The page that you requested has experienced an error.
    You'll now be redirected back to the page you last viewed.");
    history.back();
    </script>
</cfcatch>
</cftry>

This is normally the "index.cfm" template, but it can be another template as long as you copy the code over to that new template and update the reference to it in the "globals.cfm".

For this application, update the "cmn\globals.cfm" so that all you need in there is:

<cfscript>
     request.frameworkhub="/petmarket/index.cfm?";
request.cfcPath="petmarket.extensions.components.petmarket";
</cfscript>

Normally there are other variables set within this block, but they're not needed because they are a part of the Pet Market application that we are converting.

Organizing the Code
I'm not going to pretend to know the best way for you to organize code for any application that you're working on today or tomorrow. I know that every developer thinks about development and how he or she wants the applications structured, so TheHUB is nice enough to let you organize your code so that it makes sense to you. I got started converting the Pet Market code by doing a quick review of the application. After looking through the application for a few minutes, I decided to organize the code into three main groupings or subject areas:

1. DSP: Generic display code
2. Cart: Display code specific to cart functionality
3. Extensions: Intact structure from the downloaded zip

I created a directory for my application and called it "PetMarket" so that I could run the applications side-by-side. I wanted to make sure that the functionality was the same from screen to screen and that my interaction with the application didn't differ with any action that I took within the application.

Updating the Code
I mentioned earlier that the most important thing to know about TheHUB is the format of the hyperlinks and form actions. The next step to converting the Pet Market application to a "TheHUB" application is to reformat all of the hyperlinks and form actions. All requests will flow through the "frameworkhub". This is just the template used to conduct traffic for the application. You'll need to update all hyperlinks and form actions to flow through that template.

Let's look at an example. If the hyperlink you're updating goes to the "preferences.cfm" template in the directory where you located that template, in my case I put it in the "dsp" directory.

Before:

<a href="preferences.cfm">preferences</a>

After:

<a href="#request.frameworkhub#dsp=preferences">preferences</a>

The key to making these changes is consistency. I ran a "Find All" for both "<a href=" and for "action=" so that I could modify each form action and all hyperlinks within the application. Everything functions the same but I'm running all requests through TheHUB now.

Beyond the Basics
In addition to the changes to the code for the hyperlinks and form actions, there were a couple of other small changes that I made:

1. Update CFLOCATION tags to use the "request.frameworkhub" variable
2. Update CFC object instantiation calls to use the "request.cfcpath" variable

That's about it. The longest part of the process was reviewing the code from the original Pet Market download files. Of course, not every application will be as easy to convert as this one.

Conclusion
This exercise was undertaken so that you would have a side-by-side comparison of the different application frameworks in action. It should give you a good idea of the complexity of the frameworks highlighted in these versions of the Pet Market application. This article shows that the work involved in moving your development approach to TheHUB is actually pretty painless. It gives you all of the flexibility that you need to make good decisions about code organization, maintenance tasks, and the extension of the application. Also note that if you compare them, TheHUB has a much smaller footprint than other frameworks and does not clutter up your application folders with files that you'll never use or even understand.

If you start from scratch using TheHUB as your application framework, you'll find that you can easily extend and maintain the applications that you're building without the overhead of maintaining configuration files.