Fusebox 'do' Action

The do verb represents the most fundamentally new addition to Fusebox as a whole, since it is the mechanism for executing more than one more fuseaction in a given page request. It has one required attribute, action, that specifies another fuseaction within the application. Here's an example:

In Fusebox 3, the only way to have a fuseaction call another fuseaction was to call the Fusebox recursively, using cfmodule. It's likely that do will completely replace the need for recursive Fusebox calls. The difference is that do operates in the same memory space as the currently executing fuseaction and that dos can invoke multiple other dos, all of which can likewise cascade this effect.

Because the execution of a do is in the same memory space, it is also leads to vastly faster execution. Those familiar with the MVC design pattern and how it works within Fusebox will note that the controller fuseactions will consist almost exclusively of dos whereas the model and view fuseactions will more typically be made up of includes, sets, and xfas (although an occasional do will sneak in there as well).

Just as in the case of xfa, Fusebox is smart enough to know what the current circuit of the currently executing fuseaction is, and will use this value if you provide a simple fuseaction rather than a fully-qualified fuseaction. So in the circuit, cart, one might see:

Here, Fusebox already knows that the addItem fuseaction is in the cart circuit, and will correctly deduce that the reference to updateCart is in the same circuit. In this example, Fusebox will interpret the fuseaction specified in the do element as cart.updateCart.

This is important functionality for several reasons. First, it removes any hard-coded references to the alias name of a circuit when referring to fuseactions inside itself. That makes your circuits more generic and more re-usable. Second, when thinking about dos, keep in mind how they are used in Fusebox. The core files will at some point need to parse the requested fuseaction and to do so, it must transform what each command means in terms that can be translated by the parser into the underlying script language code.

So every do encountered during this transformation process will be broken down into its component pieces of code from other fuseactions and inserted into the parsed file's queue of Fusebox commands. That is, all dos eventually get broken into some combination of includes, sets, xfas, and relocates.

The most important optional attribute of do is contentvariable, another new feature in Fusebox 4. The contentvariable attribute allows Fusebox to save all of the generated output from that do (including any output from additional dos that are called) into a variable rather than outputting it at the moment of its generation. This is covered in a dedicated chapter on Content Component Variables later in this book. It's a powerful way to create modular pieces of output that can be easily assembled into much larger pieces, while keeping fuseactions as small and focused as possible.

Here's an example of a fuseaction using a component variable:

Here, Fusebox will save any content generated by the fuseaction, newsletter.signUp. The results of this fuseaction might be a sign up form that also has some formatting to make it consistent with the design of the site. Other fuseactions might be called as well, perhaps each of them likewise saving their generated content to variables. At the end of the page request, a final fuseaction is called to assemble all the pieces together for output to the browser.

If you are using the contentvariable attribute, you also have available two more optional attributes. The first, append, is a Boolean variable that determines if the content from the fuseaction specified by the action attribute should be appended to any content that might already be in the variable specified by the contentvariable. The value of append is false by default so that use of a content variable replaces any existing content being held by that variable.

The second optional attribute when using content variables with do is the Boolean variable, overwrite. This determines whether the fuseaction specified by the action attribute should even place its content into the content variable. In effect, it operates like a content variable version of ColdFusion's cfparam tag.

As with include you can use parameter tags to avoid problems with the flat file structure of fusebox. For example:

In this example, the variable title is given the value "Parameterized Layout" only for the duration of the v.layout fuseaction. If there was variable called title defined before this was executed, it is saved and then restored after the is complete. Any changes made to the variable title inside v.layout will not affect the original variable title.

NOTE: The Parameter Tag does not convert your variables into the attributes. scope.

Fusebox 'do' Action

FuseboxWiki

New Sections