• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL

Part II: Fusebox Coding > Handling a Fuseaction

Chapter 4. Handling a Fuseaction

“But since why is difficult to handle, one must take refuge in how.”

——Toni Morrison

In Chapter 3, “The Fusebox Framework,” we got all the way to section 6 of the core file by discussing how it processes a request and how the Fusebox framework is created. We are tracking the URL request:



We walked through ColdFusion’s processing of Application.cfm, the default page (index.cfm in our case), fbx_fusebox30_CF50.cfm, and fbx_circuits.cfm. We also covered some of the “overhead” that the Fusebox framework sets up, including the circuits structure and the formURL2attributes section.

This chapter continues the discussion from sections 7–11. We recommend that you open up a copy of the core file and follow along with us. Remember that an understanding of how the core files work is not necessary to effectively use Fusebox, but it can allow you to make use of many of the features built into the core file.

Most of the elements of Fusebox that were covered in the previous chapter are not things that you need to visit frequently. In fact, of the four files discussed, two should be considered read-only (fbx_fusebox30_CF50.cfm and index.cfm), and the other two (Application.cfm and fbx_circuits.cfm) are usually built once and only infrequently reviewed. You modify fbx_circuits.cfm when adding, removing, or relocating circuits in the application, and you modify Application.cfm even more infrequently when you’re creating code to be run for the entire application.

Now we are five files into the Fusebox framework. ColdFusion is working its way down the core file, processing logic and including files. Where does the actual work get done? Where do we write code?

In this chapter, we will discuss the four framework files that Fusebox developers spend most of their time working with. These framework files are the place to write inheritable code, manage circuits, identify the steps to be taken for a fuseaction, encapsulate fuses, and control the layouts used. These four files are spelled out in Table 4.1.

Table 4.1. The Final Four Framework Files
File Description
fbx_settings.cfm Required in the root circuit, this file is optional in children circuits. Write circuit-wide settings here, including security and inheritance.
fbx_switch.cfm Required in all circuits, this file is the hub of the circuit, running code for each fuseaction. It consists of a <cfswitch> and one <cfcase> for each fuseaction.
fbx_layouts.cfm Optional in all circuits, this file provides the nested layouts functionality by allowing a layout file to be chosen, thus facilitating reusability of fuseactions.
Layout fuses Optional in all circuits, this file contains the “wrapper” layout—including headers and footers—and serves as the assembly file for layout.

Let’s discuss each of these files in the order that the Fusebox framework processes them. One thing to keep in mind is that fbx_settings.cfm, fbx_layouts.cfm, and the layout fuse each get called once in each circuit. If a fuseaction is being run in a child circuit, then those three files will be run from the child circuit and from the parent circuit.

If some of that sounds confusing, don’t worry; the explanation in this chapter will clear any confusion.

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint