Object-Oriented ColdFusion?
You can hardly catch your breath without hearing about object orientation. Everything, it seems, has "gone OO" - even venerable COBOL. So it's natural to ask: Is Fusebox object orientation applied to ColdFusion? It's not. Objects are instantiations of classes - a notion foreign to Fusebox (and ColdFusion). Fusebox uses a different model than OO for building applications. Both approaches strive to reduce the complexity associated with software projects.

Look at an electrical fusebox (see Figure 1). You'll see the main electrical line that comes into the box and then splits out among different fuses. This is exactly what you do when writing a Fusebox application.

A single application will be split among various "fuses." Each fuse is quite modular in design, which makes it small and allows it to be reused. As we'll see, this modularity is a great boon to development teams, promoting a division of labor among the divergent skills needed to create successful Web applications. Finally, this modularity makes maintaining code much easier than before.

Hub-and-Spoke Architecture
If you were to draw out the architecture of Fusebox, it would resemble a hub-and-spoke system (see Figure 2).

The fusebox is the index.cfm file. Its structure is remarkably simple, making understanding the overall application design quite easy. The job of the fusebox is to "manage the action." The actions, as we'll see, are the sum total of what the application needs to do.

Like a good manager, the Fusebox delegates (fuse)actions to others. These others we call fuses. Fuses may be single, consisting of only one file, or compound, where multiple files are joined to make up the fuse. In either case, the fuse-files are d into the fusebox. This allows them to inherit all the variables of the fusebox itself. Whether single or compound, fuses handle a fuseaction and then return the action to the Fusebox. This constant "returning to the Fusebox" eliminates the problem of the "spaghettification" of code.

The Secret Life of Fuses
Just like its electrical counterpart, Fusebox contains different kinds of fuses. They can be as simple as a single line, or they may contain complex forms or sophisticated algorithms. We find it helpful to prefix fuses so as to convey information about what sort of action the fuse handles.

Fuses that involve the display of information on the screen and gathering user input are given a "dsp_" prefix. Other fuses are used for heavier lifting, such as working with databases. These fuses are called action fuses and have an "act_" prefix. If you find yourself using a query repeatedly in your application, you might want to make a fuse out of it and give it a "qry_" prefix. We find that by using these prefixes we can scan a fusebox (index.cfm page) quickly and have a good sense of what the application is about within minutes.

We mentioned earlier that Fusebox is not OO programming applied to ColdFusion. (OOP requires that a language support polymorphism, inheritance and encapsulation - the so-called OO "pie.") However, since both methodologies have the idea of reducing complexity as a key part of the process, it doesn't surprise us to find that creating fuses is quite similar to building objects in OO languages. Like objects, fuses work best when they have limited functionality and remain small in size.

By breaking a complex program into smaller "chunks," we can now better use the skills of any team members working on the project. Graphic artists and layout workers can create display pages while programmers simultaneously create the action pages.

As we'll see, the interface is attached to the actual workings of the system by a few well-defined methods. This provides a loose coupling between interface and code that allows us to build prototypes rapidly. We find that nothing provides as much valuable feedback as getting the actual application in front of users early and often. Fusebox's modularity encourages us not to delay this process, allowing us to place stubs in place of code and graphics when needed.

Every application has one - and only one - fusebox, but may have many fuses. Since fuses can be built to do virtually anything, their structure is less defined than the fusebox. Still, fuses have some elements in common. Here our simplistic fuse, dsp_ShowAll.cfm, handles the "ShowAll" fuseaction by querying a database for members and displaying them as a hyperlinked list.

As was said earlier, a single fuse is designed to have limited functionality. This tends to make fuses more generic and helps developers write code for reuse. Since this code is d into the fusebox code (index.cfm), you can concern yourselves with only the functionality this fuse needs to provide.

Use of Attributes Variables
Keen-eyed readers may have noticed a call to a custom tag in the fusebox itself. This tag, "FormURL2Attributes," converts form and URL-style variables to attributes variables. It's important to understand why this is done, as the use of attributes variables is essential in allowing Fusebox to encapsulate an entire application so that it can be called as if it were a custom tag, using either the <cf_tagname> or <cfmodule> syntax.

A custom tag takes variables passed to it and turns them into an "attributes"-style variable. Within the custom tag, you must refer to any variables with the "attributes." prefix. If an entire Fusebox application is to act like a custom tag, it too must subscribe to this naming scheme.

If you make this call (see below), ColdFusion designates the variables "authors" and "subject" with the "attributes." prefix.

<cf_MyCustomTag
authors = "Hal Helms, Steve Nelson, and Gabe Roffman"
subject = "Fusebox Methodology">

If you want to refer to the variables from within a custom tag, you must use this "attributes." notation. If you don't, ColdFusion will stall, failing to understand what you're referring to. The code within your custom tag must look like this:

<cfoutput>
#attributes.authors# are the experts on #attributes.subject#
</cfoutput>

We said that we want to be able to use entire applications as custom tags, but they must also function as standalone applications, capable of receiving and handling variables of all stripes: URLs, forms, cookies, etc. We must find some way of accommodating all kinds of variables within a single code file.

This is just what the custom tag "FormURL2Attributes" does. It transforms form and URL-style variables into attributes-style variables. When the fuse is operating in the context of a standalone application, FormURL2Attributes ensures that it needs to deal with attributes-type variables. Now our code can refer to all variables passed to it as "attributes." variables.

You may wonder why we need to call entire applications as custom tags. We said at the outset that one of the benefits of the Fusebox methodology was to allow developers to piggyback onto the functionality of other applications. If, for example, we already had an application called "Members" that took care of adding, editing and deleting members, we wouldn't want to duplicate these actions in our application. Ideally, we'd like to ask this "secondary" application to handle it for us.

We can do this by treating the Members application as a custom tag. The fusebox tells us that it accepts a fuseaction called "addMember" by calling the "dsp_AddMember" fuse. The fuse "dsp_AddMember.cfm" expects to receive both a "userName" and a "password" variable when it's called.

We can do that with this call:

<cfmodule
template="../Members/index.cfm"
fuseaction="addMember"
userName="hsimpson"
password="doh">

This will work identically to running the Members application and selecting the "New Member" button.

If you're still unsure about this, relax. Most users struggle with it initially. The good news is that just a little practice writing to the Fusebox specifications will make this clear.

Back to the Fusebox
In the example "dsp_ShowAll.cfm" fuse, we let the user drill down on an individual member to see more information. But notice the target of the hyperlink: it's the file "index.cfm" - the fusebox itself. Since the fusebox never relinquished control, the call to index.cfm is recursive; the page is calling itself.

This notion is key to Fusebox. We said that the architecture is like a hub and spoke. All action returns to the hub - that is, the fusebox. This is always accomplished by calling the fusebox and providing it with a new fuseaction and any other parameters it needs. Adding functionality to existing Fusebox applications is as simple as adding new fuseactions and the fuses to handle them (see Figure 3).

Now the circle is complete - the fusebox has passed the action off to a member fuse to take some action. Having completed its task, the fuse returns the action to the fusebox and a new cycle begins.

A Break from the Action
If you've followed along this far, stop and congratulate yourself. Learning anything new is difficult: you're asked to enter a place with few, if any, recognizable landmarks, and it often seems impossible that you'll ever grasp the layout of the new land.

Yet for those who persevere, the landscape gradually becomes less foreign and strange concepts become familiar territory. The secret to acquiring this knowledge is similar to learning any new territory: exploration. At the end of this article I'm going to ask you to strike out on your own by trying to create a simple Fusebox application.

For now, let's cover the remaining "rules of the road" you'll need to safely navigate your way through this new world of Fusebox.

No more application.cfm files: Application.cfm files are executed prior to any .cfm file. This makes them useful for holding "global" variables and any code common to all application files. However, application.cfm files present a problem for the Fusebox developer. We saw above how one application could "borrow" functionality from another by treating the entire application as a custom tag. But in the case of custom tags the application.cfm file isn't called prior to code execution. This means that the application won't have access to code that it typically depends on to function correctly. If we want to make sure that our application is Fusebox compliant - and can therefore be called as a custom tag - we must approach the matter differently.

Fusebox applications will have an app_Globals.cfm file that's <cfinclude>d as part of the fusebox's initialization and setup. This gives us a place to put variables that will need to be used by many fuses. This includes common code and the <cfapplication> tag that lets us enable client and session management for an application. The app_Globals file provides for the functionality of application.cfm files while allowing the app to be processed as a custom tag.

Attributes.Fuseaction is required at all times: This means that all URL links, forms and <cfmodule> tags will pass an attribute called fuseaction. Notice that we set a default value for this in our fusebox file so that any call to the fusebox without a fuseaction will not break our code. This rule is simply a repeat of what I already said. If you find your code doesn't do what you want, check to make sure that you have a current fuseaction - and that it's the one you expect.

Here are different ways of calling the fusebox with a "deleteMember" Fuseaction and a parameter of "memberID".

Form Method 2
<form action="index?fuseaction=deleteMember&memberID=7" method="post">

An application is always called through the index.cfm file: This is simply another way of saying that the fusebox itself defines the application. If your Web server doesn't serve index.cfm as the default page, change the server properties or rename the fusebox to support your Web server.

More on Learning
So far we've covered the bare bones of creating a Fusebox application. For a few, this will be sufficient. Most of us, though, need more than rules; we need to model behavior. We begin by imitating others who have mastered some art or skill - often without understanding the reasons behind their actions. Gradually, some of what we have imitated rubs off. We can now take what we've learned and arrange it in new ways to solve new problems.

Anyone who's been fortunate enough to watch children learn to speak must marvel at how inborn and natural this ability is. It's a miracle that occurs so frequently we take it for granted. That is, until it's our turn to learn something new - like Fusebox.

In the Beginning...
Give a young programmer a task and watch how earnestly and with what energy he or she begins producing code. This is appropriate for novices: their main attention is on the mastery of coding basics. Only after this challenge is mastered can we reflect on what we're building instead of how we're building it. Give the same task to a battle-scarred veteran and the activity is quite different, as the programmer first takes on the task of designing the application to be coded.

But how to approach this task of designing? In this section I'll introduce you to a methodology for determining application requirements and for building a functional design. If you've had much exposure to OO design techniques, you'll notice we borrow some of the excellent methods this technology has produced. Our goal here is to do more than present a new set of rules. Instead, think of this as a guided introduction to Fusebox. Use it to spur your own creativity and apply your own judgment to learning these powerful techniques.

To help you in this, I'll introduce your homework assignment - creating a simple Fusebox application. I'll also introduce your client, Tom. He's asked for your help in creating an application to help manage the "action items" that he and his staff are responsible for.

The first step in our methodology is to talk to the client and find out what he needs.

You: Tom, what problem do you want to solve with this application?

Tom: Well, I spend most of my day in meetings, and at these meetings we make decisions about what we need to do next. These "action items" get assigned to various people to handle. The problem we have now is that they're written down on paper and handed to people. By the next meeting, nobody can remember exactly what action items were assigned, who they were assigned to and what their status is. We've got to find a better way to handle this. That's what I'm hoping you can help us with.

You: Okay. Imagine that I've just delivered your new "Action Item Manager" application to you. Tell me, what sort of things does it handle?

Tom: Handle?

You: Right. For instance, does it let you create a new action item? Can you get rid of an old one? That sort of thing.

Tom: Well, yes, I need to be able to create a new action item and assign it to myself or to one of my staff. Let's see....I want to assign a priority to it, and have a due date for it.

You: Will you be the only one creating action items - or can others do this too?

Tom: Oh, definitely - let others do it too.

You: Okay, so we'll want to know who created the action item?

Tom: Yes. Good point.

You: Okay, what else?

Tom: Well, it needs to tell me what action items I have, and let me sort them by date, priority or whatever. Then I'd want to be able to mark it completed, but keep a record of it. I'd also like to let others update the item's status so we can see where they were in finishing it, what problems they were having, what resources they needed - that sort of thing.

You: And you want to keep this private so only authorized people can view the action items, right?

Tom: Yes. And I'd like to be able to ask for the status of a particular item - maybe have it e-mail the person with a request. Also, if we assigned it to the wrong person, he or she should be able to alert the person doing the assigning, or when an item is finished, be able to let the person who assigned it know about it.

You: We can do that. Anything else?

Tom: I think that's it. How long will it take you to finish this? I'd like to start using it!

You: Well, we do things a little differently now. Instead of coming back to you in a few months with a finished application, I'm going to involve you and your staff early and often in the prototype phase.

Tom: Really?

You: Absolutely. We find it's really the only way to make sure that your needs get translated into software.

Tom: Great. What's the next step?

You: I'm going to do some design work and produce something we call "use case scenario tests." This will help determine if we've identified all your requirements. I'd like to come back to you in a few days to go over them. And it would be great if you invited anyone who will be using the system to join us.

Tom: Okay. Give me a call when you're ready.

Making Fusebox Cards
As a system designer, your main job is to take the requirements of users and translate them into an actual Fusebox design. Customers tend to think in terms of complex actions that involve several smaller, distinct actions. You need to decompose these complex actions into simple actions, which will then determine what fuseactions - and from there, what code files - your application will need.

For example, Tom has identified a need to decline an action item assigned to a user. As system designer, you understand that this is a complex action requiring three simple actions:
1. Let the user specify which item to refuse.
2. Change the database record to reflect the refusal.
3. Notify the original sender of the item that it's being declined.

There are no rules to determine how far to break down actions. Your experience and preferences as a developer will guide you in this. Will your fuse call a single "do-it-all" file, or will you decide on using several smaller, more generic files that together will define the fuse? The choice is yours. If you want to write code that can be reused, you will probably "slice" actions finely, allowing them to be made generic.

The next step in the design process is to make "Fusebox Cards." These are standard 3" x 5" cards that you'll use in developing a workable, scalable and maintainable design for your system. Each card contains the following information:
1. Name of a single fuseaction - you'll have a separate card for each fuseaction.
2. File(s) that make up the fuse - those (hopefully) reusable building blocks of code.

3. Responsibilities of the fuse - personify the fuse and have it describe what it does. For example, an "addItem" fuse might show the user a list of existing items and then present the user with a form to enter a new item.
4. Attributes required - what information does this fuse need to do its job? One advantage of this is that when you're done with your design, you can factor out common attributes and make them global in scope.
5. Return fuseaction - if present, this indicates that the fuse will by default call a specified fuseaction. For example, the "action" portion of a form would be the fuse's return fuseaction.
6. Return attributes - these are the variables that this fuse will return to the fusebox.

You want these as separate cards so you have maximum flexibility in determining a good design. Also, you'll use these cards in the next phase of Fusebox design. This idea may seem strange at first, but go through the process and see if it doesn't help you make better design decisions.

Use Case Scenarios
By now, our novice programmer has been hard at work. He has an impressive amount of code produced, and perhaps the growing realization that he's forgotten one or two minor things. As he walks by our office, he pops his head in. "Are you done playing with those little cards yet?" Not quite yet.

We told Tom we'd be back to run some "use case scenarios" with him and any other interested users. Use case scenarios are part of a process to ensure that our design is sufficient to handle likely real-world scenarios. With your Fusebox cards in hand, you're ready for your next meeting with Tom and his staff.

You: Thanks for coming, everybody. Tom has asked me to create an application that will help you all track the action items that come up in meetings. Tom and I went over some of the requirements of the application and I've come back - with these.

Tom: Little cards, a piece of paper and a Nerf ball?

You: Exactly. The little cards are what we call fuses. This paper represents the "fusebox" and the Nerf ball will indicate which fuse has the action. I'm going to ask each of you to play a part in making sure that we have the application planned to handle things that come up in the real world. Each of you gets a set of cards. Notice that each card has a name on the top?

Shelley: Yes, I've got "qry_showItems", "act_deleteItem"...

Wallace: I've got "dsp_declineItem".

Maria: I've got "act_declineItem".

You: Okay. You're all going to play the part of these fuses. Notice the next line on the card?

Bob: Responsibilities.

Susan: This is written as if the little fuse is alive.

You: It sure is. Personifying fuses really helps to make sure that we have the information we need for each fuse - and that we know what to do with it. I'm going to call out something that a user might want to do with the system - something like "the user wants to add an item." Tom's list - what we call the fusebox - has three columns. One's called "Use Cases" - that's what we call those "user wants to do" things - and another is called "Fuseaction." Fuseactions are specific tasks the system needs to respond to.

Wallace: Like decline an item?

You: Right. The user thinks, "Tom sent me an action item to redo the marketing slicks, but I can't do that. It's due in two weeks and I've got training in Boston all next week. Somebody else has to do this." But that's too hard for a machine to understand, so we'll simplify it into the fuseaction "declineItem".

Susan: So "declineItem" is in the second column?

You: Right - because it's a fuseaction. The third column tells Tom which individual fuses - that's you, folks - are set to respond to the fuseaction. Sometimes he'll only need one of you and sometimes he'll get several of you together to each do a part.

Bob: Why not just tell us what fuseactions we're responsible for?

You: Good question. The truth is, Bob, as fuses, you have a very limited social life. You wait to get called, you make sure you have the information you need and you do your thing.

Bob: Sounds like my life at work.

You: Well, that's what the fusebox is for. It coordinates all your efforts to make sure that what the user wants gets done. When I call out a use case, Tom will translate that into a fuseaction. Then he'll read across to see which fuses need to be involved. Then Tom throws the Nerf ball to the fuse.

Maria: You said some fuseactions take several fuses?

You: Right. Tom will throw the Nerf ball to the first fuse on his list. You do your thing, and if you're connected to another fuse you throw the ball to them. If you've got a return fuseaction listed, you throw the ball back to Tom and call out that fuseaction.

Susan: The "Return Attributes" are what?

You: This is the information you're going to give Tom. Things like the name of the table to update, or the ID of the selected user.

Maria: But how do we get these use case scenarios that start everything off?

You: We make them up! I tried coming up with some on my own - but the ones you'll come up with will be a lot better because you know how you need the application to work. We start each use case scenario with "User wants to..." and then you fill in the blank to reflect all the possible things a user could want to do. We may decide that we won't have the application handle it - but at least it'll be a conscious decision based on your precise needs.

Tom: That makes sense.

You: Let's get started then.

This kind of simulation is helpful in creating a working design. Problems in design exposed here - prior to coding - are easy and inexpensive to fix. Plus, having users involved in these scenarios can be a wonderful way to test a design for completeness and correctness.

One of the surprising things we find using a use case scenario is that what we often perceive to be valuable to the user is seen as completely different by the user. And inevitably, things we had no idea about are brought up. What users want - and what they don't want - is entirely unpredictable. Often this will be the first time that users have even been consulted on what's important to them. This is the one effort that will give you, the developer, the greatest payback. You get highly targeted feedback from the ultimate judges of your program and buy-in from all.

Starting the Session
Brainstorming
Start the session with a group brainstorming session. At this point you want ideas, so take any that are given. Once we're in edit mode, the group will sort out the unimportant ones. It helps give structure to the exercise to start each scenario with "The user wants to...." Somehow filling in a sentence is easier than creating one.

Brainstorming is something akin to popping popcorn. It begins slowly, followed by a period of intense activity, and then tapers off to very little action. Just like popcorn, you stop when the frequency of activity dramatically falls off. It has its own natural flow that you'll sense.

Role-Playing
Next comes the really interesting part - role-playing. Ideally, each person takes the part of a single fuse. Depending on the complexity of your application and the number of use case testers you have, users may have to play several roles. Someone else needs to act as scribe, writing down the comments of the fusebox and fuses alike.

One user - Tom in our example - takes the job of the fusebox. Start with the first scenario and toss it to Tom. Using a small Nerf ball to define the fuseaction may break the ice. You can watch the fuseaction as it moves through the application. This is the first test of your system. Is there a default action the fusebox will initiate?

Once the person acting as fusebox determines the action to initiate, he calls the appropriate "fuse" to step forward. The fusebox throws the ball to the fuse. The fuse is responsible for (1) determining whether she has the information she needs and (2) executing her behavior. Once done, the fuse throws the ball back to the fusebox and calls out the next fuseaction. This is often a failure point: Does the fuse know what fuseaction to request from the fusebox? If the fuse handles multiple fuseactions, do they all require the same follow-up fuseaction? If not, how will your fuse know which fuseaction to request?

We find it helpful to keep the application structure very simple for the use case scenarios. Once coding begins, you may extend the hub-and-spoke analogy, letting fuses call custom tags to help carry out their assigned tasks. If necessary, a custom tag could even call another custom tag.

There's no set limit on the number of helpers each fuse may employ. Remember, however, that ultimately the action must return to the fusebox along with a fuseaction request. That said, you might well be suspicious if you have custom tags calling other custom tags: it may be an indication that your code is spaghettifying. Remember that one of the primary reasons for using the Fusebox method is to reduce complexity. Remember, too, that the more entities involved in an action, the greater the complexity. Keep it simple.

Now for the Homework...
Tom is still waiting for his Fusebox application! If you're feeling up to it, why not try building a small Action Items application that will handle the kind of use cases we've outlined above?

Don't be too hard on yourself if you don't get it at first. In my next article I'll take a look at how Fusebox was used recently to build a very complex electronic commerce application, and I'll talk with the programmers and designers to find out their reactions to using Fusebox. See you then.