The Fusebox 3 specification arose from the work of many devoted individuals in the Fusebox community. They took the core ideas of the original Fusebox, examined the limitations, and fashioned an amazingly flexible and powerful framework. The fundamental concepts of Fusebox have not changed, but the implementation has been streamlined and simplified, and performance has improved. This article examines the many features of Fusebox 3.

Tap into Fusebox

See the previous article for a Fusebox introduction.

Fusebox improvements
One of the many improvements in Fusebox 3 is the removal of the “federation” of circuits; it’s been replaced with a nested model. No longer must each circuit be aware of the other circuits; all intercircuit communication is handled through a central Fusebox file.

Fusebox 3 introduces several new files that are fundamental to Fusebox functionality. Each begins with the prefix FBX_:

  • FBX_Fusebox30_cfxx.cfm: The core Fusebox file, which performs all the work under Fusebox 3. This file is considered frozen, and it should not be altered. It handles the logistics of nested circuits, layouts, moving URL and form variables into the Attributes scope, and more. There are different versions of this file depending on your ColdFusion Server version.
  • FBX_Settings.cfm: Contains all settings for an application or for each circuit, including (but not limited to) global variables, default values, or security logic. The frozen Fusebox file (FBX_Fusebox30_cfxx.cfm) searches for these files in the root circuit and any nested circuits and includes them.
  • FBX_Switch.cfm: Examines each incoming fuseaction, finds a match, and includes any individual fuse files necessary to accomplish that fuseaction. The frozen Fusebox file automatically locates the proper FBX_Switch file and includes it.
  • FBX_Layouts.cfm: Contains the layout of a circuit. This is one of the great new features of Fusebox 3 that separates the layout of a circuit from its content. Because circuits can now be nested beneath each other, a child circuit can have its own layout, which is then wrapped by the layout of its parent circuit. This process is known as nested layouts. The layout nesting is automatically handled by the frozen Fusebox file.
  • FBX_Circuits.cfm: Allows for circuit nesting by listing the directory path to any nested circuits and providing an alias for each nested circuit (see the next section on the new fuseaction syntax). The parsing and manipulation of these circuit mappings is automatically handled by the frozen core Fusebox file.

If you recall from the earlier article, under the old version of Fusebox a fuseaction might have looked like

Under Fusebox 3, this syntax changes to

The fuseaction consists of the circuit alias, a dot separator, and the action you want to match in your FBX_Switch.cfm file. The circuit alias is defined in the FBX_Circuits file. This dot notation in the fuseaction is the reason why you can nest circuits, and why developers working on different circuits don’t need to know anything about the location of other circuits. By providing the circuit alias and the fuseaction, the core frozen FBX_Fusebox file knows where to go (thanks to the mapping provided by FBX_Circuits.cfm) and handles the rest.

Consequently, “No fuse ever calls any other fuse directly; everything always points back to the Fusebox.” In addition, we can say, “No circuit ever calls any other circuit directly; everything always points back to the root Index.cfm file.” In effect, to your end users, only one file ever responds to an HTTP request: the Index.cfm file that sits at the top of your nested circuits. All URLs, forms, and redirects always point back to this one root Index.cfm file.

The flow of things
At first, all this information might sound complex. A step-by-step description will help:

  1. A user visits your site by going to
  2. Your Web server’s default page, Index.cfm, is called.
  3. Index.cfm includes the core frozen Fusebox file (FBX_Fusebox30).
  4. The core frozen Fusebox file includes the FBX_Circuits file, which provides aliases and directory paths to all the circuits nested beneath it.
  5. The core frozen Fusebox file includes the root FBX_Settings file, which contains our global application settings. One of these settings is to define a default fuseaction to use if none is specified (as in this case).
  6. The core frozen Fusebox file is given the default fuseaction of home.displayHomePage by the FBX_Settings file.
  7. The core frozen Fusebox file dissects the fuseaction. It sees that the first part (the circuit alias) is home. From previously parsing FBX_Circuits, it knows that home is the alias for the root, so it includes the FBX_Switch file in the root directory (the same directory as the core FBX_Fusebox30 file).
  8. The FBX_Switch file looks through its Cfswitch / Cfcase block for a match to the action displayHomePage (the second part of the default fuseaction).
  9. After finding the match for the action displayHomePage, the FBX_Switch file includes the fuse file Dsp_homepage.cfm. This page is a simple welcome screen—Dsp_homepage contains no site header, menu, or footer, only the simple welcome message.
  10. The core frozen Fusebox file grabs the HTML output generated by Dsp_homepage but does not output this to the user yet. Instead, it temporarily stores this output as a variable.
  11. The core frozen Fusebox file looks in the FBX_Layouts file and includes a layout file containing a header, menu, and footer, along with a placeholder for any content generated by the circuits. It inserts the variable that is holding the output from Dsp_homepage into this placeholder spot, essentially wrapping the header, menu, and footer around the content generated by Dsp_homepage.
  12. The user is shown the final page output consisting of a header, menu, welcome message, and footer, as one coherent page.

You can see the magic that the core frozen Fusebox file is capable of working. That is just the beginning. Without repeating it in as much detail, let’s look at what would happen if the user clicked on a link off the home page that contained

Again, everything always points back to the root Index.cfm file. The core file dissects the fuseaction and sees that products is the circuit alias. From looking at FBX_Circuits, it knows where in the directory structure to go to grab the FBX_Switch file of the child (nested) circuit with the alias products. The FBX_Switch file finds a match for listproducts and outputs a list of products. This output is captured and temporarily stored in a variable. So far, this process is similar to the previous example, but the request isn’t finished yet.

Here is where we have a little more fun. At this point, the core frozen file looks for an FBX_Layout file in the child circuit’s directory. It finds a layout file that includes some secondary navigation elements specific to the products area of our site and inserts the product listing here, beneath the secondary navigation. But it still doesn’t output anything; it keeps all this data stored as a variable. Then the core file grabs the FBX_Layout file from the root directory (the one that provides the global header, menu, and footer) and wraps it around the content that was generated by the products circuit. In the end, we get a final page that has a header, menu, secondary navigation elements, product listing, and footer—and this is just the beginning of what is possible with nested layouts and Fusebox 3.

These descriptions have shown that Fusebox 3 is not much different from the old Fusebox. We have dot-notated fuseactions now, and some core files take a lot of the work away from us. We gain the power of nested layouts and circuits. And, developers working on different circuits don’t need to know anything about other circuits; they just always point their links and forms back to the root Index.cfm.