Macromedia MX related news and discussion
ColdFusion Thoughts on Fusebox December 22, 2003

I gotta say, I'm a bit dissappointed in an article Kay Smoljak recently wrote for Macromedia's DevCenter talking about using the Fusebox framework to develop ColdFusion applications. While the document is short and sweet, it misses a lot of the good reasons to use Fusebox, and also leaves out some important technical details, like Exit FuseActions (XFAs). If I were a beginner considering using Fusebox, I'm not sure I'd be amped by the article.

I think what I'd like to do is pick apart Kay's article. I know, it's not entirely fair to Kay. I know the pressure of writing an article for Macromedia, and I can't ask that she write the perfect article, but I think some points of clarification could actually help support someone learning Fusebox. I'll try to go in order, quoting Kay, adding my own thoughts and probably end with some overly long summary about why I use it and like using it. Keep in mind that everything Kay talks about, as well as myself, is Fusebox 3.0 related. Fusebox 4.0 is getting off to a slow start, but Fusebox 3.0 is by far used on a much wider basis.

In regards to pushing every request through the "Fusebox", Kay said:

"The only way to execute code in a Fusebox application is to channel the request through the central fusebox."

Technically speaking, this isn't true. A Fusebox Application is a ColdFusion application, and code can be executed any way you like. Just because you're using Fusebox doesn't mean you're stuck. It's better to say that the Fusebox framework is designed to route requests through a central "Fusebox", and some of the advantages of Fusebox exist because all requests are routed through a central "Fusebox". Fusebox itself will not stop you from executing code any way you like. And the term "code execution" is pretty broad too - you can include custom tags, calls to CFCs, calls to UDFs and more, each executing in their own special way, and still have a Fusebox application. Are you better off sticking to the framework? Absolutely.

Regarding the smallest "unit" within a Fusebox application:

"A fuse is the smallest unit of code, a single file that performs a single, atomic, low-level task. This task might be querying a database, or displaying some code, or sending an e-mail, but it should not be more than one of these."

I couldn't agree more. The trouble a lot of developers get into with Fusebox is having fuses that perform too much. I've often had Fusebox applications where I have a fuse that literally has no more than a single CFIF statement, setting a flag if a certain condition is true. Simplifying fuses is of utmost importance in a Fusebox application. Don't be concerned with "too many fuses" if those fuses all perform specific and required tasks. This kind of approach isn't much different than creating a good CFC or Java class for that matter, where the methods within the CFC are as simple as possible. Simplicity opens the possibility for code reuse, and segregates instructions into managable bites.

Kay touches on the structure of a fusebox application briefly, so I'll add my own thoughts as well.

A lot of beginners to Fusebox seem to be overwhelmed by jargon, and spend more time thinking about the terms than trying to find the simplicity of it. Fusebox is indeed very simple.

I've found it easiest to think of a Fusebox application as a hierarchy, or a tree. It's nested. At your root application level/folder/directory, you have what Fusebox considers to be the "main" circuit. Subdirectories are generally considered to be sub circuits (in fact, you can't have a sub circuit unless it's within it's own directory).

In the applications I've built using Fusebox, circuits usually consist of different areas of functionality within a web application. For example, if I were developing a blog tool using Fusebox, I might seperate the application into at least three distinctive areas of functionality: blog display, blog entry management, and reporting. This would make for a simple tool, but I think you get the idea. I could create a folder within my application called "blog", one called "management", and one called "reporting" and decide that those would be Fusebox circuits. If the application itself is the biggest unit in Fusebox, circuits are the second biggest.

Within these circuits exist fuseactions. Using the blog tool as an example still, under the management circuit, I would need the ability to create a blog entry, or delete a blog entry, or add meta data to a blog entry. In any case, for each of these specific "actions", I'd create a Fuseaction to would execute my fuses. You'll remember earlier that I agreed with Kay, that fuses are the smallest units of a fusebox application, and should be as specific as possible.

So, if within our imaginary blog tool application we had a circuit within the application called "management", and a fuseaction to delete blog entries, the fuseaction itself might consist of two fuses depending on how fancy we got.

The first fuse might be a query fuse, and it might simply require a blog entry ID, and that's it. The code within the fuse would consist of just a CFQUERY tag or a CFSTOREPROC tag, and would do nothing else but delete whatever blog entry existed with an ID of whatever was passed to the fuse. You might follow that up with a second fuse that reindexed the blog's search index, or did some other kind of cleanup, or redirected you back to main blog entries list, or whatever you chose to do.

The point is, that in creating these simple fuses, then "packaging" them up in a fuseaction, a ton of useful things happen. You can reuse fuses in other circuits/fuseactions because in theory, you designed them in a pretty self sufficient/reusable manner. You can unit test individual blocks of code, creating a very robust application. It makes it very easy to work with a team of developers, because each developer can take some kind of ownership over standardized, yet specific blocks of code.

In Fusebox you tell the Fusebox framework where your circuits are within the fbx_circuits.cfm file. Within each circuit, you'll have fbx_switch.cfm, which tells the framework how you'd like to execute your fuses. The fbx_switch.cfm file is really just a single CFSWITCH statement that includes each fuse within a different CFCASE tag. I like to think of the fbx_switch.cfm file as an exact roadmap of the flow of your application. By looking at it, you should know, without a doubt, how your application will behave in the hands of a end user. If it doesn't tell you, then chances are that within your fuses you have logic that diverts application flow. If that's the case, it's best to redesign those fuses so that their purpose is obvious by looking at the fbx_switch.cfm file alone.

Kay leaves out something that I think is a big advantage of using Fusebox. Really, it's common sense, but if you're new to Fusebox you'll hang up on it. Fusebox uses something called XFAs. XFAs are a fancy way of saying "instead of hard coding links, form actions, or CFLOCATION urls, use something dynamic instead." Don't let the acronym scare you, it's truly nothing more than doing something like >a href="#xfa.myFuseaction#"<. You should set the XFAs within the fbx_switch.cfm file so that you can stick to your "roadmap" approach. XFAs make it easy to change the application flow without having to go in and edit individual fuses. It also supports the idea of making code reusable.

I know I've claimed that Fusebox 3.0 is simple, but I'll admit, I haven't covered everything here. I think it's sort of like trying to tell someone how to ride a bike who never has. You can discuss the forces of gravity, friction, transfer of energy, and bike mechanics and in the end, the best way to learn how to ride a bike is to just get on one and push on the pedals.

Continuing with the biking theme, I'll suggest that trudging through all of the documentation (especially the documentation at is sort of like me talking about drag coefficients of natural rubber bicycle tires versus tires with some composite material. It may simply be easier to find an example Fusebox application, and pick it apart.

Posted by Michael Buffington at 02:50 PM in ColdFusion | Permalink

TrackBack URL for this entry:

Listed below are links to weblogs that reference Thoughts on Fusebox:

Kay Smoljak:

Have to say, I agree with almost everything you've said! However, I *was* constrained by the length of the piece, and I don't think that things like XFA's could have been covered clearly without adding quite a bit of length, or removing something like the history section, which I felt was important. "Short and sweet" was definitely a top priority. And, the article opens the way for more Fusebox content on the Developer Center!

» by Kay Smoljak at Dec 23, 2003 4:11:11 PM
Ken Wilson:

It was an interesting article. My only real complaint with it was the same as I've seen with several other folks trying to explain FuseBox 4. They always seem to suggest learning FuseBox 3 concepts first and then move up to FuseBox 4. Or they revert back to FB3 for their examples/demos. I'd like to see articles stick to FB4 moving forward.


» by Ken Wilson at Mar 10, 2004 5:58:20 PM
This work is licensed under a Creative Commons License.