Introduction to the Fusebox Framework
If you are evaluating or learning Fusebox 4, have a Fusebox 3 or older style Fusebox application to maintain, or are just curious about Fusebox, this article is for you. This article explains what Fusebox is, and explains some of the concepts and terminology you can use to talk about it.
Some of you may be asking, what is Fusebox? At its simplest, Fusebox is a framework—code and a set of common practices for building web applications. Fusebox is not a methodology, although it's often mistakenly called one. A methodology doesn't include code—it's an approach, steps you follow to produce an application. There's a methodology for managing the application lifecycle called FliP, which is associated with Fusebox, but you don't have to use one to use the other.
Requirements
To complete this tutorial you will need to install the following software and files:
ColdFusion MX
Try
BuySample Fusebox application
fusebox_sample.zip
(35K)
History of Fusebox
Fusebox was originally the brainchild of Steve Nelson and Gabe Roffman, in 1997. Hal Helms added some enhancements to the concept, and the resulting version became known as Extended Fusebox. Around this time, the framework was translated into PHP and ASP.
Development on the framework up to this point was rather haphazard. A team of developers: Steve Nelson, Hal Helms, Jeff Peters, Nat Papovich, John Quarto vonTivadar, and Erik Voldengen—came together and created Fusebox 3, a clearly-defined and documented “standard” version, incorporating many of the enhancements that developers commonly used. In October 2001, they released Fusebox 3, which moved away from custom tags and instead introduced a core file, which executes for each request. There was a different core file for each released ColdFusion version; later, there were core file versions for J2EE, Lasso, PHP, and ASP.
Developers were discouraged from modifying the core files in Fusebox 3. With previous versions, they were free to create their own core files, as long as it was clear that they were nonstandard. With Fusebox 3, keeping the default core files constant made learning and supporting Fusebox 3 much easier than it had previously been, and many new developers began using it. Although it's difficult to know the exact number of developers that adopted the Fusebox 3 framework, approximately 20,000 have registered on the Fusebox site to download the core files.
Fusebox 4 was released in July 2003, developed by John Quarto-vonTivadar and Hal Helms. Fusebox 4 takes advantage of the new XML features of Macromedia ColdFusion MX, and includes many feature and performance enhancements. A Fusebox version for ColdFusion 5 (and earlier) is currently in beta.
While developing Fusebox 4, Tividar and Helms made an effort to use ColdFusion MX ColdFusion components (CFCs). The result was so different from the Fusebox concept that a new framework was born, called Mach-II. Although they share similar roots, Mach-II is completely separate from Fusebox.
Advantages of Fusebox
If there is one truth about Fusebox, it's that there are nearly as many opinions on it as developers who have tried it. Some of the commonly touted benefits for developers include the support of a large, active community, easier code reusability, faster maintenance, and simplified team development.
It's often said that “any methodology is better than no methodology,” and the same adage applies to frameworks. Although you could attribute these advantages to any formal framework, Fusebox has by far the largest ColdFusion developer community of any framework available—which means more online and offline resources and community support.
Fusebox Principles
As the complexity of an application increases, the number of potential failure points grows exponentially. The Fusebox framework limits these points of failure, by specifying that all requests go through one central point, known as the Fusebox. This Fusebox determines which code to execute based on the parameters passed to it. The only way to execute code in a Fusebox application is to channel the request through the central fusebox.
The Fusebox framework encourages separation of logic and presentation layers. You keep database interaction, functionality, display, and program in separate files; you design each of these files to be as modular as possible.
Fusebox takes its name from the concept of an electrical fuse box in a house—each circuit works independently of the others. You can plug fuses in and out of circuits without affecting the functionality of other fuses. As you'll see, the electrical analogy extends to other central concepts: the circuit, fuseaction and fuse.
Circuits, Fuseactions, and Fuses
The easiest way to conceptualize circuits, fuseactions, and fuses is to start from the bottom, with a fuse. A fuse is the smallest unit of code, a single file that performs a single, atomic, low-level task. This task might be querying a database, or displaying some code, or sending an e-mail, but it should not be more than one of these.
Application functionality usually requires more than one simple atomic task for each higher level task. After querying a database, you might display the results. After sending an e-mail, you might log the date, time, and message. A fuseaction is a high-level task or method that the application must perform. It calls multiple fuses—or low-level tasks—to perform this high-level task.
Moving up the hierarchy, a circuit is a self-contained group of related high-level tasks, or related fuseactions. Many circuits comprise a Fusebox application; for example, a typical application might include a products circuit, which contains all product-related functionality and an admin circuit which contains all administration-related functionality. Normally, each circuit equates to a directory within the application that contains all fuse and core files for that circuit.
A typical Fusebox request has the following format:
index.cfm?fuseaction=circuit.action
The file, index.cfm is the Fusebox itself; the central channel through which
all requests pass. The fuseaction has two parts: a circuit that
tells the Fusebox which directory to look in and action that indicates
which fuses the application should execute to complete the request.
Setting Up the Sample Application
Although the latest version of Fusebox is version 4, the easiest version for a newcomer to understand is still version 3. New developers may benefit from trying Fusebox 3 sample applications before diving into Fusebox 4 sample applications. This tutorial includes a simple Fusebox 3 application for ColdFusion. The instructions assume that you are running the standalone developer edition of ColdFusion MX on your local computer. If not, you'll need to replace http://localhost:8500 with your server and/or path to your webroot.
To install the sample application, use the following steps:
- Download the ZIP file and extract the files in your webroot. The ZIP file will create a directory called FuseboxSample .
- Verify that the application installed correctly by pointing your browser to http://localhost:8500/FuseboxSample/. A welcome message appears. Refer to the ColdFusion documentation if an error appears.
Fuses, Fuseactions, Circuits, and Fusebox in the Real World
In the root directory of the sample application, there is an index.cfm file
that your app calls on every request, and which represents the Fusebox,
the central channel through which your app passes all requests.
Open the file and see the code that determines which version of ColdFusion
is running by examining server scoped variables. A cfswitch
tag includes the appropriate core file: fbx_fusebox30_CFxx.cfm,
where xx is the version – 40, 45,
or 50. Linux/Unix versions have a _nix suffix on the filename.
There is only one core file and one index.cfm
for each Fusebox application.
In the real world, you'll know ahead of time which version of ColdFusion
you are running, so it's much more efficient to delete the unnecessary
core files and simply use the cfinclude tag to include
the appropriate core file directly. Note that while separate core files
are required for ColdFusion 4.01, ColdFusion 4.5 and ColdFusion 5, the
ColdFusion 5 core file works perfectly with ColdFusion MX, so a separate
core file is not required. Open up any of the core files. Each is more
than 30 per cent comments, but you don't need to understand what's going
on under the hood to successfully write Fusebox applications.
Each Fusebox application will also contain one fbx_circuits.cfm file in
the root directory, which defines which directory each circuit equates to.
In the sample application, there are two circuits, home, which
maps to the root directory, and work, which maps to the subdirectory
/work.
Find several other files in each circuit:
fbx_settings.cfmsets variables for use in the circuit.fbx_layouts.cfm(optional) determines which layout template to wrap each fuseaction's output in.fbx_switch.cfmdefines each fuseaction in the circuit and tells the core files which fuses to execute for each request.
Although not mandatory, it is common to prefix fuses containing database
operations with qry_, application functionality with act_, and display
functionality with dsp_. Each of the standard Fusebox files has a prefix
of fbx_.
Anatomy of a Fusebox Request
When you make the Fusebox request, such as: index.cfm?fuseaction=home.welcome
the following sequence occurs. First, the application executes the default
document, index.cfm. It includes the appropriate core file and includes
fbx_circuits.cfm and fbx_settings.cfm to set variables.
Then your application calls fbx_switch.cfm, which evaluates
the fuseaction variable(s) and includes the appropriate fuse files. Your
application saves the output from the entire fuseaction into a variable fusebox.layout,
and runs fbx_layouts.cfm to determine
which layout template should output the layout variable. In this case, it's
lay_default.cfm, which contains some simple HTML and outputs
from #fusebox.fuseaction#.
An interesting note about Fusebox for ColdFusion is that the core files
copy all form and URL-scoped variables to the attributes scope. The benefit?
Fuseactions and fuses don't care whether the parameters they require are
passed from a form, URL, or through the cfmodule tag—making modular, easily
reusable code much easier to write.
Taking the Next Step
An important point to note is that Fusebox contains guidelines and best practices, not hard and fast rules. The guidelines are, however, tried and well-tested by a large community and generally work quite well in most situations.
Many interesting features were not covered in this tutorial. Fusebox 3 uses a nested layout model, while Fusebox 4 uses a more flexible content variables method of layout generation. Fusebox 4 allows you to execute multiple fuseactions from multiple circuits within one request and has an interesting plug-in architecture which opens up possibilities for third-party code integration.
If the basic overview presented here has caught your interest, there is a wealth of resources available. There are several books about Fusebox, such as Discovering Fusebox 3 and Discovering Fusebox 4, from http://www.techspedition.com, and Fusebox: Developing ColdFusion Applications, by Jeff Peters and Nat Papovich (New Riders). Or, if you prefer a more hands-on approach, Hal Helms presents training classes; details are available at http://www.halhelms.com. Most importantly, the official Fusebox site, http://www.fusebox.org, includes an excellent FAQ, core file downloads, and links to many other Fusebox resource sites.
Perhaps the most useful resource on www.fusebox.org, however, are the forums, frequented by the Fusebox creators and other enthusiastic developers. This community makes Fusebox appealing to a large number of developers—the community members are open, friendly, and very willing to help. If you have more questions, and I'm sure that after this brief overview that you do, this is the place to ask.
