Dave Ross

Subscribe to Dave Ross: eMailAlertsEmail Alerts
Get Dave Ross: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: ColdFusion on Ulitzer

CFDJ: Article

ColdFusion Developer's Journal Special "Frameworks" Focus Issue: SAM

Reengineering the CF Pet Market with Sam – a more sensible code base

The custom tags folder in the original application contained a single tag, "wrapper.cfm", which basically creates the look and feel of the site (header, footer, navigation, etc.). Each browsable page wraps a call to the wrapper tag around whatever it wants to display, and the tag calls a few CFC methods and performs a few includes. Many of the browsable files in the original application also use includes between the opening and closing calls to "wrapper" in order to generate their output. Figure 5 shows the contents of the "customtag" directory in my SAM application, which contains not one but seven custom tags! This is because of what we discussed earlier in the article - all objects have an accompanying custom tag that makes the object functionality and its different views easy to invoke via a tag-syntax interface. It's fairly obvious which objects are used by each of the custom tags simply by looking at the tag names; in fact, all of the tag names directly correspond with the name of a CFC, save one. The "purchase" tag facilitates the flow of a multi-step checkout process when the user wants to check out the shopping cart. In more complex applications, I oftentimes do have a purchase object, but it was overkill for this simple application and limited timeframe. Creating all of these tags took very little time - I already had the search and user tags, and most of the work for all of the tags was nothing more than copying code from the original include files, adding some CFC interaction and instantiation, and putting it all into a nice format.

Figure 6 shows the cfm files that are in the original Web root. There are 16 files in all - each one is either browsed directly or included by another file. Figure 7 shows the files in the SAM Web root. There are 10 files in this version and, other than the Application.cfm file, these files only represent the files that are directly browsed by users. There are no includes and no CFC instantiation or interaction in any of these files, and all display code is generated by custom tags. One result of this technique is that the browsable files are tiny. The original site has quite a bit of conditional logic and formatting in the browsable pages, whereas the browsable pages in the SAM application consist of absolutely nothing but calls to custom tags and nested plain text for the simple pages that need nothing more than the default look and feel and some centered text.

The power of the Sensible Assembly Methodology's use of APIs is illustrated nicely by the code in the Pet Market checkout process. In the original application, one file contains all of the business logic to process data submitted in seven steps and to facilitate the flow between these steps, which includes performing a <CFINCLUDE> for the display component of each step. With SAM, the same file consisted of a call to the page wrapper and a nested call to the purchase tag. Doesn't this just mean that I moved all of that ugly code into a custom tag? No. In fact, it doesn't mean this at all. The purchase tag doesn't do much more than wrap the appropriate look and feel around the view for each step. The view for each of the seven steps (aside from the final "success message") is generated by a call to some other custom tag - whether summary data or forms. Each step in the checkout process (each custom tag) bears the responsibility for processing its own data and telling the purchase tag to display the appropriate next step. It's a much better example of code reuse and a clean separation of the flow of control from the view and business logic.

In general, I felt that the CF Pet Market wasn't the best sample application to re-implement within a framework or methodology because it is both simple and has some odd quirks and inconsistencies. For example, some objects have numeric auto-incrementing IDs in the database and some have strings (like UUIDs or locales) for primary keys. Some functionality should be there but isn't (like an admin area, for example), and some functionality cannot be supported by the database as-is (preferences are stored in the session but can never be committed to the database, for example). This isn't a big deal, but it's frustrating when you are the developer who has to work on it. On the other hand, most developers are only willing to spend a limited amount of time developing a sample application or looking at another developer's sample application, so perhaps the simplicity of the Pet Market application is a blessing. When implementing my SAM version of CF Pet Market, I was careful to leave all of the existing functionality exactly as it is in the original. By that I mean that I didn't set out with the goal of modifying, enhancing, or adding to the existing functionality. It's an exact replica of the original application from an end-user point of view, an exact replica with a much more portable code base that's easier to read and maintain.

Building an application as a conglomerate of APIs makes it very easy to reuse code within an application. Were the owner of the pet market site to come to me tomorrow and ask me to add an administrative back end for managing all of the data, it would take no time at all - I just need to create pages that call the custom tags and pass them the appropriate data. This reusability also means that I can take each of these components individually and use them in other applications. If my next project needs a shopping cart, I have a cart and tag all ready to go. In fact, the "cart," "user," "search," and "product" objects and tags in this application were all added by me copying files that I already had from other applications. All I had to do was customize them a little for this app. I had to resist leaving in extra functionality that would have made it too robust - for example, the user object that I began with actually had all of the functionality required for roles and groups based authentication and authorization. It was beyond the scope of these requirements so I removed all of that functionality. I had to make the object factory "requestObject()" method accept a string argument rather than numeric because, though my applications always have numeric IDs in the database, this one didn't. SAM applications are usually aware of "context" - what part of the application the current request is being made within. Again, this was overkill for the Pet Market application so I removed this feature. This is one of the things I like about methodologies as opposed to frameworks - because a methodology has no core files, the developer is encouraged to modify all of the files to suit his or her needs. Having generic versions of objects, and tags to work with those objects that you can quickly and easily integrate with any application, is how developers who use SAM are still able to achieve quick results without having a framework already in place.

I prefer to use the Sensible Assembly Methodology because the applications are easier to maintain and extend, because the skills and code are transferable anywhere, and because it doesn't inhibit or hide anything from the developer while encouraging best practices. Perhaps what I like more than anything, though, isn't the idea of SAM as an alternative to using frameworks, but the fact that the modules developed with SAM are so portable that they should be able to integrate with any decent framework with little effort from the developer. There is still so much about the Sensible Assembly Methodology that I have yet to document or explain, but I strongly suggest taking a look at the code at www.cfpetmarket.com for my sample application as one good place to start.

More Stories By Simon Horwith

Simon Horwith is the CIO at AboutWeb, LLC, a Washington, DC based company specializing in staff augmentation, consulting, and training. Simon is a Macromedia Certified Master Instructor and is a member of Team Macromedia. He has been using ColdFusion since version 1.5 and specializes in ColdFusion application architecture, including architecting applications that integrate with Java, Flash, Flex, and a myriad of other technologies. In addition to presenting at CFUGs and conferences around the world, he has also been a contributing author of several books and technical papers.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
SYS-CON Belgium News Desk 02/01/06 01:29:21 PM EST

I've been fairly outspoken for quite some time now about the fact that I don't subscribe to any one framework. I've also spent many years refining what's proven to be the best methodology possible for developing ColdFusion applications. I recently promised my boss that I would learn and evaluate several of the popular ColdFusion frameworks.