Fusebox first appeared on the scene in 1998 as little more than some bits of code and some good coding practices for ColdFusion developers. It has since arguably become the most popular framework for building ColdFusion applications. Why? Because it's free, it's easy to learn and use, and it works very well. This article will review some of the great new features of the latest version, Fusebox 4.
Fusebox on Builder:
If you're unfamiliar with Fusebox, here are some articles previously published on the subject:
For the purpose of this overview, I'll assume that you have a basic understanding of the way Fusebox works. Users call request handlers called fuseactions, which include individual code files called fuses. Fuseactions are grouped and encapsulated into circuits, and all of your circuits working together are what drive your application. A set of core files handles the task of implementing the Framework for you, so you are free to focus on planning and building an application that meets user needs.
Fusebox 4 brings some very useful features and some big improvements over Fusebox 3. Let's take a closer look at some of them.
The XML files
The first big change is that the fbx_switch, fbx_settings, and fbx_circuits files are gone. They've been replaced by XML files: fusebox.xml and circuit.xml.
The fusebox.xml file uses a standard XML syntax to define the circuits and parameters of the application. It also lets you register plugins and create global fuseactions. There is one fusebox.xml file per Fusebox 4 application.
The circuit.xml defines the fuseactions inside a circuit. Each circuit has its own circuit.xml file. There's a standard XML grammar used to define each fuseaction, as well as perform operations like basic loops, conditional logic, file includes, etc.
Using XML has some nice advantages. First, it's language neutral. The same set of XML files could be used within a ColdFusion application or a PHP one (when the PHP version is released). Perhaps more interestingly, the XML can be read and parsed by tools, perhaps for testing, generating documentation, or navigating the application structure.
Finally, as XML files, they will be much more stable going forward. When Fusebox 5 comes out someday, it will be able to read the same XML files.
Plugins and global fuseactions
Nestled within the fusebox.xml file are definitions for plugins and global fuseactions. Let's look at each of these.
Plugins allow developers to extend the functionality of the core files. It works like this: There are a series of "plugin points" that occur during a Fusebox 4 request, and at of these points you can execute a plugin. The plugin points are preProcess, preFuseaction, postFuseaction, fuseactionException, postProcess, and processError. Plugins make great places to add things like security or exception handling, and several such plugins are already available or in development.
Global fuseactions are a bit different. These are places where you can define entire fuseactions that you want to execute either at the start of the request or at the end of it. For example, you could set a global fuseaction at the beginning of the request that creates a header, and set a global fuseaction at the end of the request to create a footer. It's a simple example but you get the idea.
Calling all fuseactions
Fusebox 4 vastly expands the power of fuseactions. In Fusebox 3, the user passed one fuseaction into the application, and the application handled that one action. There were ways to call the application recursively to get the system to handle more than one fuseaction, but it had some drawbacks. In Fusebox 4, your application can process the user's request by calling any number of other, internal fuseactions it needs to. This lets you build much more flexible and loosely-coupled circuits.
For example, in your circuit.xml file you can call multiple fuseactions from within a fuseaction like this:
<do action="menu.buildMenu" contentvariable="menu" />
<do action="view.homePage" contentvariable="pageContent" />
<do action="view.buildPage" />
When the user requests the home fuseaction in the circuit main, the application responds by executing other fuseactions internally. First it goes to the data manager and gets the user's preferences. Then it builds a menu and captures the output for the menu within a variable. Then it renders the home page and captures that output in another variable. Finally, these separate content variables are assembled in the buildPage fuseaction, which outputs a final page to the user.
The ability for one fuseaction to call another really opens up the door for you to construct applications with the Model-View-Controller (MVC) pattern. You end up with one set of circuits (the controller) that responds to user requests, and then invokes fuseactions in the model to process data, and the view to output the data. It results in a really adaptable application.
How, you might wonder, does Fusebox 4 manage to let you call multiple fuseactions without the problems that came with doing it in Fusebox 3? It cheats! The first time your application is called by a user, a lot happens. The core files are read in the fusebox.xml and circuit.xml files. The framework is then established and a series of memory structures are created. Finally, the core file processes the XML and generates a single parsed file that does everything necessary to fulfill that user request. In short, the calls you define in your XML are translated into the full set of code necessary to perform those calls.
After this initial XML processing and parsed file generation, things are lightning fast. This is because all the application data read in from the XML files is stored in memory, so all subsequent requests read all this right from memory. Even better, once the parsed file is generated, it stays there, so all future requests go straight to the parsed file. Because of all this, Fusebox 4 is significantly faster than Fusebox 3. I personally saw an application that took about 400 ms to run on Fusebox 3 drop to 40 ms on Fusebox 4.
There are numerous other cool features in Fusebox 4. I'll quickly outline a few of them:
- Content component variables (CCVs) are a handy way to capture small pieces of content for use later in the page processing. You saw a simple example of this earlier when I demonstrated how to call multiple fuseactions with the <do> element. CCVs make it extremely easy to create and capture modular pieces of content that you can assemble into a final page.
- Prefuseactions can be defined within a circuit's circuit.xml file. When a call is made to a circuit, the framework checks to see if any prefuseaction elements are defined. If they are, the prefuseaction is executed before the rest of the call to the circuit is handled. It's like a very basic constructor.
- Postfuseactions work like prefuseactions, except they run after a circuit is called.
- Callsuper is an attribute that you can use within a prefuseaction or postfuseaction element. When callsuper="true", you're telling the framework to execute actions in a parent circuit of the current circuit. This creates a simple form of inheritance within your circuit hierarchy, which is very useful.
Fusebox 4 brings a slew of new features and improvements over earlier versions. If you are a ColdFusion developer who has not considered Fusebox before, for whatever reason, I would urge you to give Fusebox 4 a try. You can find the most current core files and documentation on the Fusebox 4 beta Web site.