The latest version of Fusebox - version 4 - has been taken out of beta and placed into general availability. Over the last seven years, Fusebox has grown from a collection of best practices and snippets of code into a full-featured, robust framework on which developers can build true Web applications.

Over these seven years, Fusebox has become the overwhelming favorite of ColdFusion developers, and it has been ported to JSP, PHP, and Lasso. Organizations as large as UPS, Casio, Dell Computers, the U.S. Air Force, the U.S. Army, and Rooms to Go employ Fusebox on their Web sites, intranets, and extranets.

Fusebox is built around the idea of a central controller (the Fusebox) that handles requests (fuseactions) and delegates them to smaller, focused controllers (circuits). These components, in turn, delegate work to individual code files (fuses). Fusebox comes with a set of core files (downloadable from fusebox.org) that implement the framework.

Language-Independent XML
This latest version of Fusebox was almost a year in the making, and comes with added features, bug fixes, and improved performance. The most obvious change is in the controller elements. Previously, an fbx_switch.cfm file found in each circuit contained ColdFusion code to determine which actions were to be taken for each request. For example, this code might be used for a login circuit that was meant to respond to the fuseactions, login, and validateLogin (see Listing 1).

In Fusebox 4, the fbx_switch file is replaced with a circuit.xml file. This file has no ColdFusion code; the file consists of nothing but XML (see Listing 2).

Why the move to XML? XML offers Fusebox architects the ability to state their intention without resorting to code. But what's wrong with code? Nothing, of course, but a code-independent XML grammar allows the underlying Fusebox core code to change without affecting the code written for an application. It provides an interface between the architect's intention and the code's implementation.

This means that the core code for, say, a future Fusebox 5 could be substantially different from Fusebox 4, but not break any Fusebox 4 application code. The issue of backwards compatibility must concern providers of any technology. The use of a stable interface that is later translated into implementing code is one of the best ways of dealing with this problem.

XML Grammar
The purpose of the circuit.xml file, where this grammar will be used, is to define the meaning - not the implementation - of a fuseaction. For that reason, the XML grammar set used in these files is quite small; implementation details should be handled by fuses. Even with a constrained grammar set urging them against it, Fusebox architects must be careful to avoid writing implementation code in circuit files. Table 1 lays out the XML elements that can be used in the circuit.xml file.

 

As with all XML, the circuit.xml file must be well-formed - that is, it must conform to the rules for proper XML usage, such as the use of a closing slash in elements that have no closing tag.

While the XML file initially looks very different from Fusebox 3's fbx_switch file, experience among the beta group has shown that adapting to the new format is fast and easy for existing Fuseboxers.

Performance Through Parsing
One of the largest changes to Fusebox is largely invisible to Fusebox programmers. In previous versions of Fusebox, the core files were read on each request and all processing was handled dynamically - that is, at runtime. This created an overhead common to all dynamic processing models.

Fusebox 4 handles things very differently. Much of what had been dynamically determined is now handled in a separate parsing cycle that executes prior to runtime. The Fusebox 4 XML files are parsed and a single file is produced for each fuseaction, using the syntax: parsed.circuitname.fuseactionname.cfm. All such files are automatically placed in a parsed directory.

At runtime, index.cfm (or whatever the default file is) calls the Fusebox 4 runtime file, fusebox40.runtime file. The first job of the runtime file is to ensure that the parsing cycle has been run - and that no changes to XML files have been introduced since the time last parsed. If the runtime file code determines that the parsed files are not up to date (or are missing altogether), it calls fusebox40.loader, fusebox40.parser, and fusebox40.transformer, all of which work together to produce the parsed files located in the parsed directory.

By preparsing the code, the runtime logic needs only to include the appropriate parsed file. That is, if a request is made of the application to execute the fuseaction, home.main, for example, the runtime code (once it has assured itself that the existing state of parsed files is current) includes the file, parsed/parsed.home.main.cfm. By resolving as many dynamic issues as possible before runtime, performance is greatly improved.

Extending Fusebox with Plug-ins
Fusebox 4 also introduces the idea of plug-ins. Plug-ins provide developers a way of extending Fusebox's core functionality without having to tinker with the core Fusebox code. If the Fusebox core file is written to accommodate virtually any developer working on any project, and the application code is written to deal with individual fuseaction requests, plug-ins inhabit the middle ground - code that should run across multiple fuseactions within an application.

What can plug-ins do? Virtually anything - from logging requests to implementing security to... well, anything. Plug-ins allow the programmer to add application-wide functionality that the Fusebox core designers did not or could not anticipate.

Once the plug-in code is written, it is placed in the plug-ins directory. The plug-in designer determines at which of six plug-in points he or she wishes the plug-in code to run. This decision is registered in another XML file, fusebox.xml, located in the root directory.

The plug-in points reflect different stages of a fuseaction life cycle, such as preprocess (before anything else happens), prefuseaction (immediately prior to a fuseaction call), postfuseaction, and postprocess. The other two plug-in points are not temporally based, but occur when exceptions occur.

Plug-ins provide great extensibility to Fusebox without compromising the integrity of the Fusebox core files. During the beta cycle, several members wrote plug-ins to deal with common issues (such as security) and we expect to see plug-ins used as commonly as custom tags.

Exceptions, Layouts, Accessibility, and Content Components
As good as Fusebox 3 was, it suffered from one unfortunate liability: its exception handling was poor, and Fuseboxers have suffered with obscure exception messages since its release. Built into Fusebox 4 is the ability for the programmer to specify a module to call when an exception is thrown. The particulars of handling exceptions can then be handled by a plug-in. This provides enormous flexibility for a wide variety of needs.

Layouts in Fusebox 3 were exceptionally helpful. In Fusebox 4, they just get better. While Fusebox 3 tied layouts to the physical directory structure, this restriction is gone in Fusebox 4. Layout files lose their special status and simply become a fuseaction, making them easier to build and to employ.

While Fusebox 3 existed uneasily with ColdFusion's tag, this is no longer the case; developers needing to use can do so with impunity. The changes made to layouts also make Fusebox 4 more accessible to users with visual impairments by supporting Section 508 accessibility standards. Especially for government agencies - often charged with "508" issues - this represents a breakthrough.

Fusebox 4 also introduces the idea of granularizing content by providing content component variables that can be combined to form a larger Web page. Content component variables (CCVs) allow fuseactions to concentrate on building pieces of content while deferring the placement and usage of these components to another fuseaction. One obvious use for this technology is the building of portal-style pages, but it can be used whenever developers want to make display code more reusable. CCVs allow for far greater reusability of these components than was available previously.

Is Fusebox 4 for You?
So, with all this "new stuff," how disruptive is the move from Fusebox 3 to Fusebox 4? Surprisingly, not very. In a typical Fusebox application, well over 90% of code written is in fuses. None of this code changes at all. Members of the Fusebox 4 beta group were pleased by how simple porting Fusebox 3 applications to Fusebox 4 was. One member related that an application that had taken over a month to build was upgraded to Fusebox 4 in less than two hours.

Is Fusebox 4 for everyone? Certainly not. Some developers have created their own frameworks that work well for them and their team. Some chafe at the idea of working within any framework. Still others want to use a true object-oriented framework, while Fusebox 4 is solidly procedural. (For more information on an object-oriented framework see the article in the August issue of CFDJ, "Mach-II: Breaking the Procedural Barrier, Vol. 5, issue 8.")

Is Fusebox for you? Of course, you're the only one who can make that judgment, but if you're looking for a powerful, robust, mature framework on which to build solid ColdFusion applications, Fusebox 4 definitely deserves your attention. For more information, including sample applications and core code, visit fusebox.org. If you're interested in attending the Fusebox conference in Las Vegas, visit www.cfconf.org/fusebox2003.

Note: Thanks to John Quarto, Brian Kotek, Sandy Clark, Perry Woodin, and Brian LeRoux for making available to me a pre-release copy of their upcoming book, Discovering Fusebox 4, available at techspedition.com.