As the Fusebox standard grows in popularity, our attention turns to ways we can leverage the standard to work in our favor. As an application architect, you need to use every means you can to help "blueprint" the project and improve the end product.

I was recently introduced to a piece of software that leverages design thinking and consequently created a ColdFusion tool that, hopefully, will apply even more force to the lever.

Fusebox Framework
If you've followed the Fusebox concept at all, you're familiar with the general hierarchy of files used by a typical application: a home app directory with the application's fusebox file (index.cfm), along with a subdirectory for each circuit application. Each circuit app contains its own fusebox file as well as the fuse files for its own responsibilities.

This standardized framework makes it possible to create applications from simple to complex in a well-planned, easy-to-manage environment. Have you ever revisited an app you wrote three months ago? Was it easy to find your way around, add features, and change behaviors? Unless you're using a framework like Fusebox, odds are it was a lot harder than you expected. That's why frameworks are so useful - the up-front planning makes it far easier to debug, maintain, and upgrade your application. Maybe I'm preaching to the choir here, but I can't stress this point enough. The more you analyze and plan, the fewer headaches you'll have down the road.

One of the great headache prevention prescriptions I can recommend is to use Fusedocs in your fuse files. Through the use of well-designed Fusedocs, you can literally plan the complete functionality of your application before you write the first line of code. If you're not familiar with Fusedoc, now's the time to visit or revisit Hal Helms's articles in CFDJ and at www.fusebox.org.

Fusedocs: Blueprints for Towering Applications
Here's a statement many folks may not believe at first: the Responsibilities and Attributes sections of an application's Fusedocs can completely and accurately describe the application's function such that a developer who has no familiarity with the overall application can write the required code. This means you can focus the talents of your development team where they belong. Great designers should be designing apps, and great coders should be writing great code. Fusedoc gives designers and coders a way to communicate effectively, efficiently, and accurately. If you haven't guessed yet, I'm a true believer in the powerful benefits of Fusedoc.

This article isn't a tutorial on Fusedoc. However, if you're familiar with Fusedoc and make use of it, the rest of the article will have greater benefits. Hold on to that thought; I'll get back to it.

Seeking Blueprints
The real-life story behind this article began at the Fusebox FUN 2000 conference in Charlottesville, Virginia, last September. I'd been thinking about Fusedoc-related concepts when I'd an opportunity to chat with Hal for a few minutes. He mentioned that he had been considering using Visio to create diagrams of application architectures written with Fusedocs. The idea intrigued me, and I began to think about writing a VBA-based Visio solution.

By the time Hal and I got together again in October (for Hal's first-ever Developing Applications with ColdFusion and Fusebox [DACF] class), I was interested in pursuing a graphical solution and brought the topic up again. However, after further discussion, I began to realize that I didn't really have a great purpose in mind for Visio - it just seemed like a cool thing to do. I thought about automatically generating pictures or maps of planned applications to help clients visualize the system. Unfortunately, the multiplication of possible variables soon made these ideas impractical. Not that having such diagrams wouldn't be helpful, but developing the solution would take more time than it was worth.

It was during this state of mind that Hal introduced me to a piece of software he'd been using to help design Fusebox projects. This software caused me to abandon plans for Visio-based solutions in favor of something far more helpful to me as a developer. Before I get to that, I need to stress that at this point, we were working with a clickable prototype of the system and had analyzed it in terms of exit points for each page, fuseactions, and possible fuses.

Exit points are places on a page that allow you to 'exit' in order to do something else. For example, a submit button on a form would be an exit point, as would a link to another part of the application. Identification of exit points is the starting point for understanding the fuseactions your system needs to be able to handle.

Armed with this information, we were ready to start constructing a blueprint for the Fusebox framework that would actually make the application work.

Now...about that Visio-busting software....

Visual Mind: A Tool for Architects
Visual Mind (www.visual-mind.com) is a Windows application that assists in creating documents known as mind maps. A mind map is a hierarchical collection of ideas, thoughts, related pieces of information, and so on. For those of you who, like me, tend to arrange things in outlines, a mind map can be thought of as an outline that works its way out from a single topmost item.

When you open the Visual Mind application, you're presented with a single node. You can give this node a title (see Figure 1). From then on, whenever you type some text and press Enter, a new node is created as a child of the selected node. This is an extremely easy method to use for creating outlines, since you don't need to worry much about mouse clicks and how-tos. Once you see how Visual Mind works, the ideas seem to flow right out of your fingertips onto the map. As you work, you can expand and collapse the hierarchy to make it easier to navigate.

To create a Fusebox map, I use Visual mind to define the home app (top node), circuit apps, fuseactions, and fuses. Figure 2 shows an application mapped to the fuse level (some branches are collapsed to clarify the concept).

Visual Mind associates a Note with each node in the map. You have the option of turning the Notes pane on and off. For my way of working, the Notes pane is a great place to put the Fusedoc for a fuse, as shown in Figure 3.

With your application mapped out in this way, you can easily work through the details of your design, collapsing and expanding segments of the map, making adjustments as necessary until you're happy with your design. At the same time, you're creating a visual representation of the system that adds a nice piece of documentation to the development history - similar to what I was seeking to do after the fact with Visio.

Here's where things start to get sweet. Back in class I was sitting there with a (mostly) completed mind map of my application, thinking about what a cool tool Visual Mind was for an outliner like me. "Hey! That's it! Outlines!" I thought to myself (or something like that...). So I checked to see what sorts of files Visual Mind could export to. Imagine my joy when I discovered that I could save my mind map as a plain ol' ASCII outline. Now I had input!

Thus an idea was born - how about a CF program that would read the input and create my application framework? I outlined the concept that afternoon (Monday), and by using spare tidbits of time between sessions (never during class, Hal, honest! <g>), I had a working program finished Wednesday afternoon. The rest of the week's spare time was spent refining behaviors, adding features, and generally kicking around ideas with the rest of the class. So now I give you "Fuseminder."

Fuseminder Builds the Foundation
Fuseminder is a custom tag that can convert the information in your mind map into a full Fusebox application framework, complete with home fusebox, circuit fuseboxes, and fuse files with Fusedocs built right in.

As I mentioned, Visual Mind has the ability to save your map in a variety of file formats. For Fuseminder I started by using the Tabbed Text format, which writes the mind map in a traditional outline style, using two spaces (even though it's called "Tabbed") as the outline indenting string. So the first level (home app) is not indented, the circuit app level is indented two spaces, the fuseactions are indented four spaces, and so on.

The only problem with the current Visual Mind text output is that it inserts a large chunk of formatting information at the top of the text file (before the outline starts), and a small tail after the end of the outline. Fortunately, there's a way to create custom export formats for Visual Mind. The Fuseminder archive file contains a Visual Mind VMX file for the Outline Text format. This is a format I designed specifically for use with Fuseminder. If you copy it into your Visual Mind program directory, the Outline Text format will appear in the Save As dialog box as an output file type.

Once you've saved the outline, you can use Fuseminder by calling it with this syntax:

<cf_fuseminder
outlineFile="SampleOutline.txt"
location="c:\myDir">

The location attribute tells Fuseminder where to start the home app build process. This is a good place to take advantage of the GetDirectoryFromPath - GetCurrentTemplatePath() - syntax if you want the application built from the same directory as the calling template. Figure 4 shows a directory tree before and after the Fuseminder process for our sample outline.

The complete structure 'automagically' appears in a blink - talk about avoiding drudge work! An additional note: Any nodes you add to the outline at levels below the fuse level will be written into their parent fuse files. For example, if you define your exit fuseactions as nodes beneath each fuse file, they'll be written to the fuse file along with the Notes section for the fuse. You can then move those lines into the Fusedoc section of the file. How you take advantage of Fuseminder is up to you.

I know there are those of you saying, "Those Fusebox people! Now they have another piece of software they want me to buy. I don't use Visual Mind and I don't want to buy it." Before you go looking for the noose, understand that Fuseminder works its magic on a plain text outline. Granted, Visual Mind is a terrific way to create that outline, but if you're a text outliner of long habit, you can create your application outline in whatever text editor you choose.

You can even choose the outline indent string; just tell Fuseminder what string you use with the "indenter" attri-bute. Here's a sample outline that uses a pipe symbol and two dots for its indenter. In keeping with the use of Visual Mind, Fuseminder uses two spaces as its default indenter:

MyApp
|..Circuit1
|..|..Fuseaction1.1
|..|..|..dspFuse1
|..|..|..dspFuse2

Nuts and Bolts for the Mechanics
Fuseminder is really a fairly simple processor. It reads an input file into an array, then loops over the array, choosing the appropriate action based on the content of each line. Listing 1 shows the complete source code; let's take a look:

The first 24 lines of the file are the Fusedoc. If you aren't familiar with Fusedoc yet, take a couple of minutes to look it over. The objective of a Fusedoc is to tell you everything you need to know to write a code module. Consequently, the Fusedoc also tells you the salient features of a module without having to read all the code.

Lines 26-77 set up parameters for expected attributes, output beginning lines (if verbose mode is on), and define constants to be used in creating files. Watch for this as you go through the rest of the code - the constants make it far easier to interpret.

Actual processing of the text file begins at line 79, where we set up an array to store the name of circuit apps we en-counter on the way through the outline. This array is used at the end of the process to create the home fusebox file.

Lines 82 and 83 read the input file and dump it into an array. Now we're ready to parse the outline and create the actual framework. This is handled by the loop between lines 86 and 214. Each line is evaluated to determine its appropriate level: Fusedoc, fuse, fuseaction, circuit, or home (CFSWITCH, lines 102-212). Any line that falls deeper in the outline structure than a Fusedoc line is treated as a Fusedoc line, so any nodes you add to the mind map below the fuse level will be written into that fuse file, as Fusedoc lines are.

If you're interested in error-trapping techniques, look at the use of CFTRY and CFCATCH in the file creation routines. When creating a new file, we first try to read from it. If we get an error (i.e., the file doesn't exist), the code within the CFCATCH block creates the file. Similarly, if we're creating a directory, we don't want the program to crash if it already exists, so we use a CFCATCH with no code to say "Don't worry; keep going."

After looping through the outline array, all that remains is to close the last circuit app's fusebox file and create the home app's fusebox file. Once again, we're looping over an array - this should be familiar territory by now. After the array has been processed, we just close the home app's fusebox file and output the end-of-process lines (again, assuming verbose mode is on).

Conclusion
Fusebox offers a wealth of opportunity for developers to create well-designed, solid web applications. The addition of Fusedoc gives us the opportunity to do so, confident that we've thought the processes through before trying to build them. In building Fuseminder, I've tried to create a tool that will give Fuseboxers a way to rapidly turn their design efforts into a framework that's ready to send to the coders and easy to manage. I hope you enjoy it.

Acknowledgments
Thanks to my fellow "guinea pigs" in the first-ever DACF class - Dr. Joe Sanger, Colin Robinson, Gary Heffern, Tom Ryan, and Ken Beard - for being part of The Mind. I couldn't have done it without you guys. And thanks in particular to Hal Helms for creating Fusedoc, introducing Visual Mind, and hosting a week of absolute mental stimulation. I'll work with you guys anytime!

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Source Code