(Portions of the following are taken from the Fusebox Conference whitepaper written by John Quarto-vonTivadar and me.)
When we discuss nesting a fusebox, we refer to the integration of multiple fuseboxes into a singular application--or the partition of a fusebox application into a multiple fuseboxes. In either case, the result will be a series of one or more physical file directories that are so integrated that the end user would find his experience to be indistinguishable from a singular (and very large) fusebox.
In Fusebox 2, there was some small measure of integration between separate fuseboxes but it consisted largely of sending a browser from one insular fusebox to another. But the true goal is a "drag-and-drop" type of functionality, wherein a fusebox consists of one of more circuits (a file directory), all of which can access each other without direct dependence on the underlying directory structure, and that, when done, can be drag-and-dropped to another fusebox, requiring only a few small settings changed to the definition of the circuits.
In Fusebox, we typically had a home circuit with several child circuits. In Fusebox 3.0, this idea has been extended to allow for parent/child relationships among circuits. I have built a small example application to show a four-level nested application, available at www.halhelms.com under the CODE section. Here is its circuit structure
If this type of nesting is combined with a some sort of a standard with respect to how a fusebox operates within its own framework, we gain the ability to write large amounts of reusable code. If we further adhere strictly to a standard for doing that, like Fusebox3.0, then people can write entire applications that can be stamped as "Fusebox 3.0 compliant" and which can then be dropped into our own code, saving time and money.
When thinking about nesting in Fusebox 3.0, it will be helpful to keep a few ideas in mind. The first is that even though Fusebox is not an object-orientated methodology (nor is ColdFusion an OO language), it is helpful to retain some of the best ideas from OO. One of these is that a the idea of encapsulation--that a given object (or circuit, in our case)--should be as independent as possible of other objects. Fusebox 3.0 has its own concept of inheritance that, while very different from OO languages, still allows children to inherit properties from their parent, grandparent, etc.
The second idea to keep in mind is a visual one: as each of these circuits gets drag-and-dropped into a parent circuit, we are reminded of wooden Russian dolls thatto reveal another doll. This pattern continues for as long as the artistry of the maker can sustain itself. In Fusebox 3.0, the grandparent circuit may contain one or more parent circuits, that, themselves, may contain one or more child circuits-and so on.
Nesting/inheritance in Fusebox 3.0 is done for you automatically by the core fusebox file, FBX_Fusebox_CFxx.cfm. One of its functions is to handle nesting, which it does in the following manner: each circuit from the top "home" circuit down each intervening circuit to the target circuit, has a settings file, called FBX_Settings.cfm. The more global an item in a settings file is, the "higher up" the circuits tree that item would be loaded. So if your application accesses a datasource called customers, you may want to set Request.DSN in the home circuit.
But suppose you dropped in a shopping cart circuit, which itself needs a products datasource. It might set one as part of its own settings file since that DSN may only be needed by that circuit or one of its child circuits. Of course, you, as the architect of your program, can determine whether you want to force it to have a certain value by using cfset or whether you want it to inherit a value from a higher level circuit-if such a value has already been set-by using a cfparam. In earlier versions of Fusebox, you included the app_globals.cfm once, and then used app_locals.cfm for all second-tier circuits. In Fusebox 3.0, there is no hard meaning to "global" or "local"--anything set in a circuit is available to all circuits nested beneath that circuit. Again, remember the Russian Doll; this is where we've taken it apart and gotten into smaller and smaller pieces. Further, circuits initially written as parents may find themselves incorporated into larger applications, where they become child circuits.
Once all the settings (via the FBX_Settings.cfm files) have been inherited-in order-from the home circuit to the target circuit, we then "reach" into the target circuit to examine its FBX_Switch.cfm in order to execute the target fuseaction within that circuit. This central switch concept has not changed from Fusebox 1.0.
That fuseaction may fire off one or more fuses. This is where you will also set any XFAs required by the fuses(s). You will find that breaking your fuses up into smaller component fuses will leave you with more re-usable code for your next application. Many times people will break out the query fuses this way, to separate them from the display or action fuses that use them or to use their XFAs (exit fuseactions) to set values for an URL fuse to further distinguish between performing an action for the application versus performing a relocation for the user.
In Fusebox 1.0 and 2.0 this is where the Fusebox would have finished, having completed its mission of executing a fuseaction. It's the Russian doll again: now we've gotten to the very heart of the toy, and weup that final itsy-bitsy doll and find a piece of candy, the fuse.
Next, the fusebox will now walk "up" the tree from the bottom "target" circuit where the fuseaction was found, up through each parent circuit up to the home circuit. Each of those circuits, in order, will have the opportunity to apply its own layout as determined by the FBX_Layouts file. If you've followed the Russian doll analogy, we're beginning to put back together each of the larger and larger dolls take what they got from the smaller doll and wrap their own wrapper around it, all the way up until the largest doll, the home circuit, that encompasses everything.
That's it. It's a pretty simple process if you keep the Russian doll in mind. And even so, most of the time you won't have much stuff in the deeper level FBX_Settings files, and even less often will you have multiple levels of layout to be applied from the deeper level layouts files. In subsequent newsletters, we're doing to take a deeper look at applying layout files but suffice it to say that most of your use of it will be to apply GUI design elements such as logos, meta tags, graphic interface components, primary and secondary navigational links and the like to the real target of what you what your visitor to be concentrating on: that little nugget of candy in the center of the doll, commonly referred to as "content".
Home
