Tap into Fusebox to manage program flow

Modern Web-based applications can be as complex and powerful as any "traditional" application. They are constantly changing, evolving, and incorporating new technologies and business processes. Given this complexity, the question arises: "How can I, or even a whole team of developers, manage all this?" The answer may be Fusebox methodology.

What is Fusebox?
At its heart, Fusebox is a way to manage the complexity of building a Web application by breaking it up into small, modular pieces. Page-based scripting languages such as ColdFusion, ASP, JSP, and PHP offer few obvious ways to separate application logic from presentation because the scripting and the HTML output are often on the same page. Furthermore, there are no standards for handling program flow during execution; pages tend to interact in a haphazard manner through links, forms, or HTTP redirects. This problem escalates as the number of pages grows because the number of possible interactions increases exponentially.

Building a large application is extremely difficult without a standard way of handling program flow and separating processing logic from presentation. Fusebox provides this standard. It is a free and open source solution to architecting large, complex Web applications. Using Fusebox provides the following benefits:

Better planning and prototyping Rapid development More modularity More code reuse Fewer errors Better testing Easier maintenance More productive team development Large developer community

Fusebox was originally created for use with the ColdFusion application server but is being "ported" to ASP, JSP, and PHP. This article will deal specifically with the ColdFusion version, but if you aren't using ColdFusion, the general ideas and concepts should be useful regardless of the application server you use.

A new version of Fusebox was released in October 2001, dubbed “Fusebox 3.” I’ll cover the basic concepts of the original Fusebox methodology in this article. We will look at the improvements inside Fusebox 3 in a future article.

The concept behind Fusebox
Web developers face a major challenge when managing program flow. Without some structure, any page in an application can call any other page, and we end up with a tangled mess that might look like Figure A.

Figure A

An example of program flow without Fusebox

The concept of “fusebox file” is the most important concept behind the original Fusebox. “Fusebox file” is a central file that manages the interactions between pages. It acts like a traffic cop, directing the flow of the application, depending on the action that needs to be performed. The fusebox file uses CFINCLUDE to include individual files, or "fuses," that are needed to carry out a specific action. No fuses call any other fuses directly to initiate a new request; everything always points back to the central fusebox file. Once in place, we see something like Figure B.

Figure B

The Fusebox file structure

Figures A and B show the massive improvement in manageability. Your next question might be, "Well, how does Fusebox know what fuses to include?" The answer involves some conditional logic and the idea of the "fuseaction."

Every time the fusebox file is called, a variable called "fuseaction" is passed to it as a URL variable or form field. The fusebox file contains a CFSWITCH/CFCASE statement that determines which set of fuses to include to fulfill the specified fuseaction.

Given the URL format, http://www.mysite.com/index.cfm?fuseaction=displaynews, the fusebox file (index.cfm) takes the value of fuseaction (displaynews) and looks through its CFSWITCH/CFCASE statement for a match. When it finds a match, it includes the individual fuse file(s) necessary to fulfill the request. Listing A includes a very simple fusebox file to show how this might work:

Looking at this, you might notice a few things. First, there are two fuseactions that this fusebox file has handlers for (displayHomePage and displayNews), and then we have a default case, so that the fusebox file has something to do if it gets a fuseaction it doesn't recognize. In our example, we passed in the fuseaction "displayNews," so this code would include two files: "qry_GetNewsItems.cfm" and "dsp_NewsItems.cfm."
This might be a good time to mention file-naming conventions. Most Fusebox developers use the following naming conventions for different types of files:

dsp_FileName—Files used to display output to the user, usually as HTML

act_FileName—Files used to perform processing, such as credit card transactions or validating form input

qry_FileName—Files that interact with a database, usually as SQL queries or stored procedures

url_FileName—Files that perform an HTTP redirect, usually with CFLOCATION

You don't have to use this naming convention, but I would highly recommend that you use some kind of naming system. This provides two big benefits. First, if a file has a descriptive name, you can instantly get a good idea of what the file does. Second, and maybe more importantly, is that the fusebox file becomes a sort of "map" of an application. You can look through the list of fuseactions, and at the fuse files that each fuseaction includes, you can quickly understand what the application does and how it does it.

The concept of variable scoping
Another concept behind creating a basic Fusebox application is one of variable scoping. The ColdFusion version of the original Fusebox used a CFML custom tag called FormURL2Attributes. This tag copies any variables in the FORM or URL variable scopes into the ATTRIBUTES scope. There are several reasons for doing this, but the primary one is so that all passed variables are in the same scope. This way, if you receive variables from another page through form or URL values, you know that they can always be referenced in the ATTRIBUTES scope regardless of how they were passed.

Before moving on, let me address one last concept. I have spoken with some new Fusebox users who immediately code their entire application in one giant fusebox file, a monster with 1,400 lines of code that handles 84 fuseactions. This is not what Fusebox is meant to be. If you look at a Web application, it is most likely made up of several "mini applications": a shopping cart, a product search-and-display section, a login area, or a news section. Each of these areas is a logically discreet part of the site, and each one should become its own Fusebox application. Individually, these discreet "mini applications" are called "circuit applications." When combined, they become your "home application." As a general rule, if your fusebox is handling more than 10 or 15 fuseactions, you should consider breaking it up into smaller, more modular components.

The concepts of the original Fusebox methodology are summarized in Figure C.

Figure C

The original Fusebox methodology

Your home application is made up of multiple circuit applications, each circuit application contains a fusebox file for managing program flow, the fusebox file contains handlers for one or more fuseactions, and each fuseaction includes one or more individual fuse files to accomplish the desired action.

In the next article, we’ll discuss Fusebox 3, a new version that includes numerous improvements to the architecture, such as nested circuits, improved performance, a basic form of inheritance, and a shorter learning curve.