Programming is hard work, or it can be. For developers there seems to be a tendency to write and rewrite the same code. Often it seems most of our work boils down to the fundamental four: Create/Read/Update/Delete (CRUD).

This portion of the application development life cycle can be so time consuming, so repetitive, and so tedious at times that it's all we can do to keep from getting ourselves into a rut, or continue working once we're already in one. With the volume of code this represents, it's no wonder that we turn to frameworks and life cycle processes like FLiP to provide consistent structure, accelerate development times, and bring manageability to what can otherwise be a surrealistic management nightmare of cut-and-pasted code.

For a long while the only ColdFusion framework with a following has been Fusebox. Since August of 2003 (very nearly coinciding with the appearance of the Mach-II framework) I've been working hard developing the onTap framework. Unlike other frameworks, onTap focuses on much more than the controller layer in a model-view-controller (MVC) approach to application development, including many custom tags and function libraries to extend the ColdFusion server's native APIs. All this work on low-level functionality like e-mail, caching, database analysis tools, database agnostic querying, modular display components, etc., has kept me pretty busy in the past year and it's superceded any work on complete applications until very recently. I knew the framework community needed a forum - I'd known this for quite awhile but hadn't found the time to build one. I didn't want to use a tool created with another framework for reasons I hope are obvious. Now that I've finally created the Forums onTap application and I've implemented it on the framework site, I can say that I'm quite satisfied with all the underlying work that's gone into the framework up to this point.

I won't say Forums onTap required less time to develop due to the onTap framework because it hasn't. What I will say is that I've achieved several objectives with this application by using the onTap framework that I most likely would not have achieved if I'd used another framework or no framework at all. The time savings as a result of using the framework have, however, allowed me to achieve these additional objectives in the same amount of time that I would normally spend developing a similar application.

The Best Buggy Whips Money Can Buy
A forum application in and of itself is nothing special. There are dozens, maybe hundreds of free forums available these days for various Web development platforms. If I'm going to develop something so common, I want to make it better than the others. With this in mind I had several objectives:

• Browser-driven installation
• Common security API
• Rich user interface
• Extensible forum API

What? No Coding?
The first objective of browser-driven installation is something I've written and spoken about before and is part of the fundamental objectives of the onTap framework. As application developers, the reasons for this may not be immediately obvious to you. If you imagine for a moment that you aren't a skilled application developer but merely an intrepid businessman who's acquired a ColdFusion-enabled shared hosting account and are setting up your first dynamic Web site, the reasons might become more obvious. As developers we've become accustomed to manually installing and configuring applications by hand-editing templates and text files with file paths, datasource names, and other information. This situation is unheard of amongst traditional desktop applications. Imagine the horror of a typical computer user when told that he or she must manually edit an ini file or Windows registry entries before Winamp, AIM, or Microsoft Word will function. In the world of desktop applications this would never be tolerated, and with onTap it's no longer necessary with dynamic Web applications.

In order to achieve this objective, I began with a copy of the onTap framework core components and added to that the onTap framework Plugin Manager application (see Figure 1). Both of these components may be downloaded from the framework Web site at www.fusiontap.com. The Plugin Manager component must be extracted or copied into the framework root directory and should then be immediately functional. Unfortunately the scope of this article doesn't allow me to offer an in-depth analysis of the Plugin Manager or how plug-ins can be installed and managed. What I can say is that the installed Plugin Manager supplies a rich API that provides common tools for installing and configuring individual plug-ins like the Forums onTap application. Each individual plug-in must include its own installer to utilize the Plugin Manager API in much the same way that traditional desktop application installers interact with their target operating systems like the Windows Add/Remove Programs Wizard.

Of course creating an installer for the forum application does increase the amount of time required to develop the forum, although I think this is time well spent. Ideally a well-written installer will mean less time spent answering e-mails from intrepid developers when they're confused about how to install and configure your application.

Logins and Trade Secrets and Encryption Keys - Oh My!
When was the last time this happened to you? You visit a Web site and discover it has a members-only area. You need some information from the site so you fill out their sign-up form, check your e-mail, and log in. You look to find their forum to ask your question from others on the site and discover that you now need a membership! But wait! Didn't you just sign up to be a member on this site just a few minutes ago? What gives?! Forum applications are often installed into existing Web sites that already have some other dynamic services as well. The site owners understand the need for a forum though they don't feel they have the time to design and develop one, and why should they? With plenty of existing forums available in the community they usually choose one they like, install it as is, and leave it alone. The task of integrating the forum with their existing application member-management and security if considered is rarely undertaken. But why should visitors or users be required to have two separate logins for the same Web site?

The scenario I just described is the motivation behind creating the Members onTap and Roles onTap plug-ins for the onTap framework (see Figure 2). These two plug-ins provide a rich API for managing members (new member signups, member preferences, etc.) and roles-based permissions for complex Web applications. This allows the forum to utilize a common API for creating and managing its members and permissions, and this same API can be used with any other applications installed in your onTap framework site. Since the member and security management API is installed separately from any applications (like the forum), all plug-in applications can share the same set of members and roles, eliminating the need for multiple logins or memberships on your site.

Both the Members onTap and Roles onTap plug-ins can be downloaded from the framework site and like the forum application are installed through the Plugin Manager interface.

I Only Have I's For U
There's been a lot of talk in the community and from Macromedia in the last two years about rich Internet applications. This is the term Macromedia uses to describe applications that use Flash (or now Flex) in an application's presentation layer to offer the application users a friendlier interface that more closely resembles a traditional desktop application. This is important because while scriptable Web applications are less expensive to develop than traditional desktop applications, the limitations of working in a multibrowser environment have been a significant handicap to developing clean, intuitive applications that are pleasing to use rather than annoying or challenging for the user.

Although Flash and Flex are still challenging and expensive to implement, Web standards like CSS, XHTML, and DOM are fortunately achieving better support with the latest breed of browsers. As modern browsers like Opera, the latest Firefox, and other recent Gecko-based releases become available, it is an increasingly viable option to use DOM to create rich user interfaces inexpensively. While DOM may still have its limitations compared to Flash or Flex, it can provide most of the same functionality for free to almost as many users (or browsers if you like), it's often faster to load, and the onTap framework makes it very easy to design.

The forum application uses two user interface elements or techniques in particular, which makes it unusual amidst the morass of Web forum applications. The first element is an implementation of the onTap framework's HTML forms library to display form validation (and some other less obvious niceties like clickable labels for radio buttons and checkboxes). When the forum application is installed you are given the opportunity to select client-side (JavaScript/DOM), server-side (ColdFusion), or a combination of form validation. The default is for forms to be validated both in the client browser and on the ColdFusion server.

In itself this is moderately unusual, although what's really unique about this implementation is the display of error messages. We've all seen Web forms that use either client-side validation (with its annoying JavaScript alert windows), or some form of server-side validation presenting an error or list of errors at the top of a form. Even if a form uses both forms of validation, the error messages supplied are usually delivered in their native mediums (HTML for server validation or a JavaScript alert for client-side validation). Forums onTap however delivers both server-side validation and client-side validation in the HTML medium so that there is no variation in display between errors occurring before or after the form is submitted. As an added bonus these error messages are not accompanied by a nerve-jarring alert sound effect.

The second interface element can be seen when viewing the list of messages in an individual forum thread (see Figure 3). By default the forum offers four modes in which to view forum threads. The first is a simple linear mode in which the messages are displayed in chronological order. The print mode is very similar only excluding some graphical elements. The remaining two views are described as "top" and "left" indicating the location of a DOM tree presenting a list of the messages in the thread sorted by branch. In these modes only one message at a time is visible on the page and the user may select messages to read from the tree. Recent messages are marked in the tree with a graphic and any branches containing new messages are open by default when displayed. Although obviously not for everyone, this provides a very clean and intuitive way to examine longer and more active forum threads, which often fragment into several distinct conversations making them difficult to navigate.

Both the rich forms interface and the tree navigation are examples of the onTap framework's HTML library - a very rich and powerful tool for creating modular display and an important part of achieving the next objective. Although the HTML library seems daunting at first glance (particularly to developers who are accustomed to seeing templated display code), its principals are ultimately very simple, based on the existing standards for CSS, XHTML, and DOM. Once you have a good grasp of the fundamental principles of these Web standards, the HTML library becomes quite easy to understand and use.

A Horse of a Different Color
I've saved the best for last: extensibility. The word extensibility has become something of a buzzword, immediately conjuring up images of XML or XHTML for many developers, in spite of the fact that simply using XML doesn't make an application extensible. In fact I would argue that the majority of applications using XML today are not any more extensible than their non-XML cousins. When I say extensibility, I'm talking about something much more tangible. This element alone was the thrust of my first ColdFusion Developer's Journal article entitled "Features Without Fixtures." It has become my mantra for application development and the driving force behind the development of new features for the framework. What I mean when I say the forums are extensible is that I can make customizations to them, add features, remove features, change not only the formatting (as with CSS), but also mold the content or completely rearrange the interface - and I can do this all without editing a single line or even a single character of the forum code. I can...and I have!

The Forums onTap plug-in application is designed with a wider audience in mind and as such its interface offers no considerations for the formatting, layout, or navigation of any site or application it might be installed within. In my case I installed the forum application within the onTap framework documentation site - which serves a double purpose as both the documentation included with the core application (also an exercise in extensibility) and as the official onTap framework Web site. This documentation site uses a pair of iframes for its primary navigation, one to the left containing a tree with links to various documents, and one to the right containing the content. Above these frames is the site title and an area containing a hierarchical view of your current position in the framework documentation.

The forum application also has a similar hierarchy-driven navigation built into its displays (typically referred to as breadcrumbs). Although both sets of navigation work, I would much rather have a single contiguous hierarchy rather than confuse visitors with two separate hierarchies. So by using the extensibility features of the framework, I've been able to merge the forum navigation with the documentation site navigation. I've done this without editing a single line or a single character of either the forum application code or the documentation site code.

This grail of extensible development is made possible by two things in particular. The first is the framework's core feature - directory-based automation of template execution. In short, the framework examines the directories you create to locate templates to execute. New templates may be executed in any given page merely by adding the template in the appropriate directory. Each request is divided into several stages (application, onrequestend, htmlhead, local, etc.) and your new templates may be executed in any of these stages simply by knowing which directory to place your template in. In the case of the forum application I wanted to move links from the forum display into the frame-parent document. Since the forum navigation is created in the local stage, I have to add my template in the local directory after this navigation is created.

The second key to this process lies in the HTML library described above. The HTML library creates all of the elements in an HTML page as a series of structures and arrays prior to display. This provides a very easy way to make even the most complex modifications to the display at any time before the elements are written to the ColdFusion server's output buffer. If you don't like the label next to a form element, simply locate the structure representing the table cell (or other HTML element) containing the text and change the text. Or better yet, use one of the HTML library's built-in functions designed to do just that. Simple, clean, and safe: no need for complicated regular expressions to modify HTML content created with the cfset or cfsavecontent tags.

Knowing that the navigation would be an element people might want to modify, I gave it a distinctive name to make it easy to identify in the code. I then created my new template in the forum application's local directory and applied an event-filter to the navigation element. This event filter (in the form of a ColdFusion user-defined function) is called just before the navigation element is written to the ColdFusion output buffer. Receiving the navigation element as an argument, this event filter then loops through the navigation links one at a time and appends them to the navigation element in the frame-parent document using a handy function declared in the documentation site's API. Once the documentation site's navigation is updated, it's a simple matter to suppress display of the original navigation element in the forum display using a little CSS.

This hierarchy navigation wasn't the only customization for the official framework site. I also wanted to include the forum in the framework's left-pane tree; the site's primary navigational element. This is a similarly easy task performed in the same manner by adding a template in the appropriate directory to take advantage of functions available in both the framework documentation site API and the forum API. This new template displays a branch in the tree showing the forum home page and allows users to expand the tree to see forum categories and individual forums.

If you're asking yourself why I've gone to all this trouble, the answer is simple. When I publish new versions of the framework or of the forum application, I can install them cleanly over the current versions without worrying about my modifications because the new versions don't impact any of the existing code. These are "features without fixtures".

Conclusion
I could talk for quite some time about the various merits of the onTap framework and how they've influenced this project. Obviously I have a bias and the medium of a magazine article such as this offers me little room for in-depth analysis. In summary, I've been able to meet my four major objectives of extensibility, security, rich user experience, and easy installation all by using the features available in the onTap framework - and while I haven't saved time doing this, I believe I've produced superior results.

• Figure 1
• Figure 2
• Figure 3