Best Practices

Digg This!

Simon says, "Build the Pet Market app in Fusebox." Simon says, "Write an article about it."

 So I'm sitting on a plane at 35,000 feet, somewhere over the heartlands, writing an article. Having been the driving force behind the creation of the Wegot Widgets reference application project for Fusebox, I think the idea of an "All Pet Market" issue of CFDJ is a great idea.

I'm sure each of the application authors are taking a slightly different approach, even with the various frameworks taken out of the picture. Here are the ground rules by which I played when building Pet MarketFB:

1. No changes to the database
2. Use the existing application's HTML
3. Follow the whole Fusebox Lifecycle Process (FLiP)

Consequently, there are a lot of things you won't see in the Pet MarketFB code. You won't see any attempt to modernize the HTML, use CSS, build accessibility, etc. While these are all laudable goals, they are beyond the scope of this project and article. In my opinion, the point of the project is to show you how the same application's code would look if arranged in Fusebox.

Prototype/Front End
Fortunately, FLiP is well-suited for an effort like this. We can pick up the project at the end of the Prototype/Frontend phase--the point called "Prototype Freeze". We just use the HTML generated by the existing application as the frozen frontend. Based on that assumption, I started by printing out the screen shots of the application and marking up the printouts as I would for any Fusebox application. The printouts are marked in various colors representing dynamic data, exit points, exit data points, and fuse file names (for the display fuses implied by each printed page). An example of a marked up page is shown in Figure 1.

Mind Mapping
Once the markup was completed, I fired up Mind Mapper Pro and started building out the architecture of the application. For each page in the markup, I chose a circuit to contain the logic represented by the markup. Each circuit is assigned fuseactions implied by the pages and the actions they require, and each fuseaction is in turn assigned one or more fuses. I also defined Exit Fuseactions and Component Content Variables. At this stage of the game, we're not concerned about code at all. It's all about the application architecture. A shot of one circuit in the finished mind map is shown in Figure 2. The complete mind map is available in the companion zip file for this article, which can be downloaded from www.cfpetmarket.com.

Fusedocs
With the mind map's nodes all built out, I turned my attention to the Fusedocs. Fusedocs define the responsibilities, properties, and IO for each fuse in a standardized XML vocabulary. Still, we're not working in code. The project might be completed in ColdFusion, but it could also be coded in PHP, Lasso, or any other language for which the Fusebox 4 core files have been created. An example of one of the Fusedocs is shown in Figure 3.

The purpose in a Fusedoc is to provide everything the coder needs to write the fuse, and nothing more. The responsibilities section describes the fuse's job, and the properties and io sections provide specific data about the fuse, its inputs, and its outputs.

Fusedocs to Fuse Stubs
In addition to the XML-based Fusedocs, I also added some extra stuff for some of the fuses. In particular, I copied relevant chunks of HTML from the front end into each display fuse, and I created a QuerySim for each query fuse. QuerySims are an easy way to provide recordsets with test data before the database is available. During the architecture phase, I'm not concerned about the database, even if one already exists - I'm concerned about satisfying the data requirements represented by the front end. The front end is the customer's expectation and it must be met. I'll worry about the database's demands when the time comes - in the coding stage.

These "Fusedocs with stuff added to them" are known as fuse stubs. I typically write the Fusedoc in HomeSite+, using the available VTMs for Fusedoc. Then I copy and paste the Fusedoc into the Notes pane for its node in the mind map. I do this so that I have the entire architecture for the application contained in one place - the mind map. A sample fuse stub is shown in Listing 1.

Generate the Framework
With the mind map completed, it was time to start working some time-saving magic. I saved the mind map in text format, which results in an outline with all the data in the mind map. A few years back, I wrote a custom tag called Fuseminder that uses just such a file to generate the entire Fusebox framework. With feedback and new code provided by several other Fuseboxers over the years, the latest being Jamie Thomas, Fuseminder was kept up-to-date as new versions of Fusebox came out. So I ran the latest, FuseminderFB4, passing the outline file to it. The calling form for FuseminderFB4 is shown in Figure 4.

FuseminderFB4 cruises the outline file, creating directories, writing data to fuse stub files, creating circuit configuration files (circuit.xml) and an application configuration file (fusebox.xml), and placing the Fusebox 4 core files in the application's root directory. Figure 5 shows a portion of the output from FuseminderFB4 running in Verbose mode.

Test Harnesses
With the application framework generated, it was time to build some test harnesses for unit testing. Test harnesses are just little templates that set up the environment required by a fuse and allow the coder to run the fuse all by itself. This allows them to make sure the fuse works according to its Fusedoc even though the coder knows nothing about the rest of the application.

As you can imagine, writing all these test harnesses is quite a bit of drudge work. It's another perfect opportunity for the use of a utility, so I wrote one called Harness (back in old days of Fusedoc 1.0). Harness2 is the latest incarnation, updated for Fusedoc 2 by several of us, notably Kevin Roche. I ran Harness2 as a custom tag called in the root of the application, and it cranked out all the test harnesses in a few seconds. Listing 2 shows a test harness for the fuse stub we saw in Listing 1.

Coding
Test harnesses were generated for all the fuses, and the time came to write the actual code for the application. As the architect, I farmed out the coding assignments to my skilled team of coders and waited for the finished fuses to come back. To keep track of the coding assignments, I used another utility I wrote - FB4Checklister. This utility just reads through the application's circuit.xml files and renders a checklist for all the fuseactions and fuses in the each circuit. A page of output from FB4Checklister is shown in Figure 6.

With the fuse stubs, test harnesses, and checklist prepared, I called in a few favors. With Hal unable to attend the MAX conference, I enlisted his help in writing the final application code. With a few circuits in hand, Hal went to work on his fuses while I worked on the rest of them. As of this moment, the fuses need to be written. I'll finish this story after the application is done, sometime during MAX.

Sometime During Max - Integration Testing
The coders went to work on their fuses, and let me know if they had questions about any of the Fusedocs. After a few clarifications on some fuses, the work was completed and I had the code back in hand. It was time to drop everything into the application framework and watch the finished application run flawlessly.

Okay, so the "run flawlessly" part didn't quite happen. Why? Because I, as the architect, rushed through my job and didn't do a good job designing the application. Consequently, there were a few issues that I had to resolve during the final integration testing. Fortunately, these were all minor problems, such as specifying the variable "productID" instead of "breedID", and easy to resolve thanks to the granular nature of the code.

What's It Look Like?
Obviously, the application itself doesn't differ from the original in terms of the user experience. The important part of the exercise for us developers is how the code looks. One of the nicest things for Fusebox users is the "roadmap" nature of each circuit's configuration file (circuit.xml) and the application configuration file (fusebox.xml). Listing 3 shows the fusebox.xml file for PetmarketFB, and Listing 4 shows the circuit.xml file for the Catalog circuit.

The code in the fuses isn't as critical in terms of differences from other frameworks, but I will make an example of the overall application layout display fuse, shown in Listing 5. It's immediately apparent that this code, and the layout is creates, is very simple to interpret. The actual content blocks have been removed and replaced by Component Content Variables. This is one small example of how Fusebox can greatly simplify the maintenance of an application.

Similarly, the layout fuse for the checkout process is much more flexible, as shown in Listing 6. The layout doesn't depend on an arbitrary "step" variable to control segments of the display. Consequently, this layout can be easily adapted to any stepped process simply by changing the step names contained in the list at the beginning of the fuse. Displayed links in the title bands and the display of content within successive bands is controlled by the presence or absence of content instead of a control variable's value.

Finally
At the end of the FLiP process, we have a finished application that is highly documented, easy to maintain, and has powerful management features built right in. There are a few caveats about this particular project that I should mention. For example, without the original database designer available, assumptions had to be made about the intent of the database design. For example, there appears to be no place in the database to store orders - only user shopping carts. My assumption based on this observation was that the orders were being stored elsewhere in the company. There are also inconsistencies in the database, such as calling a field "firstname" in one table and "givenname" in another. By using the FLiP process, these inconsistencies don't become inconsistencies in the application, because the application's variables, field names, and so on are designed without the database at hand, and the differences in naming are resolved during the coding phase.

In addition, issues like the layout of the site, which is fairly confusing to examine and navigate in its original code, becomes much more easy to follow when organized in terms of Fusebox layout files and Component Content Variables. Fusebox provides the organization that improves the lives of maintenance programmers.

This is a simple introduction to Fusebox and FLiP in the context of the Pet Market application. All the files for the application, captured at various stages of the process, are available in a zip file on my site, www.GrokFusebox.com.