M. Cloney
CASAS — Comprehensive Adult Student Assessment Systems
Introduction
I've been writing Web and database applications for about eight years. I've learned everything I know about coding for the Web on the job, and I've had several epiphanies in that time. By far, the greatest of them all was when I discovered Fusebox about four years ago.
I don't have formal training in computer science. Like many of you, I had the opportunity to work my way up an organization that believed in me. When I first started writing code, I was much more focused on getting things to work than I was on thinking about things like extensibility and flexibility. Working in this way is all right if you're developing simple, small applications that don't require a lot of changes.
If you're reading this, you probably know that the very nature of software development is change. Developers are often graded on how quickly and easily they can add new features and remove unwanted features (read: bugs) from existing applications. Whether you're writing new applications or refactoring existing ones, Fusebox can make your life a lot easier.
If you've been writing Web code for less than a few years, you may still be writing "spaghetti code," a coding style so named because everything connects to everything else. At least that's the way it's supposed to work. This style of coding seems like a good idea to the novice developer, largely because:
- It works
- It seems flexible
- You don't know about advantages or existence of application frameworks
I look back on the applications I wrote when I was learning to program ColdFusion and shudder. Typically, they existed of a few gigantic files (200+ lines long) that each served several functions. A single ColdFusion page might have served as a shopping cart, for example, including all the necessary database queries, ColdFusion functions, and HTML code to display the cart to the user.
Then I discovered Fusebox 3.
I had heard about Fusebox, but no one could really tell me what it was all about. I finally decided to give it a try after a conversation I had with a consultant who said, "You've heard people talk about Fusebox, but if you actually see someone talking about it, they've got this gleam in their eye, like they've seen the light."
So what is Fusebox? It's essentially a set of open-source files you can download free for ColdFusion or PHP (at the time of this writing). It's also a style of coding and documentation that will revolutionize the way you code and will help you to solve problems more quickly and easily than you have before. There's also FLiP, the Fusebox Lifecycle Process, which is a way to manage projects, but that's outside the scope of this article (I have found it to be highly effective, and I recommend you look into it as well).
What does Fusebox bring to the table? There are at least three key things for anyone wanting to start using an application framework:
- A common vernacular
- Special features inherent in the framework to help you write better code
- The Fusebox community
Common Vernacular
One of the biggest problems I encountered as a spaghetti coder was a lack of rules for coding. Developers all had their own naming conventions, preferred names for things, and method of writing code. With Fusebox, these problems are solved with a set of best practices and good coding standards. To understand these concepts, it's important to understand the central underlying concept.
Fusebox is meant to work like, well, a fuse box in your home. Each piece of code is called a "fuse," each grouping of code is called a "circuit." A grouping of fuses is known as a "fuseaction." One of the tenets of Fusebox development is that each fuse be extremely short and that each fuse serve only one purpose. This helps make your code much more reusable. Action fuses perform tasks like form validation and data massaging, and always start with "act". Query fuses talk to your database, usually return a record set, and always start with "qry." Display fuses are just what they sound like, displays, and always start with "dsp."
Also, Fusebox lends itself well to the Model-View-Controller, or MVC style. The MVC style also helps with the common vernacular. Briefly, the model contains the business logic (query and action fuses) and the view contains the visual elements (display fuses). All requests are sent through the controller, and the controller talks directly to the model and the view. A full discussion of MVC is outside the scope of this article, but you'll find a good primer at fusebox.org.
Special Features
Fusebox is written by a consortium of developers who all believe in the project. Needless to say, they make every effort to create the best product they can, because everyone in the community is depending on them to deliver a robust, scalable framework on which to build applications. Each release of Fusebox has produced a better, more stable and more extensible platform on which to develop.
One of the oldest features in Fusebox is that the form and URL scopes are copied to the attributes scope. This was especially useful in earlier versions of Fusebox, but is still a great concept. In this way, developers may simply refer to attributes.id without worrying whether the id is coming from a URL query string, a form submission, or a cf_module/custom tag call.
Another feature in Fusebox version 4+ is the extensive use of XML. The fusebox.xml file is present in all Fusebox applications and holds information about circuits and the general application. Circuits are really just directories that consist of code to perform a similar function. For instance, an application might have a circuit called "model_security" that held all the business logic related to the security of that application, or a circuit called "view_cart" that held code to show a shopping cart to a user.
Circuits also contain XML files called "circuit.xml" that contain information about the different functions, or "fuseactions" they perform. Using XML in this manner helps developers and managers to organize their thoughts as well as their code. If a problem arises, it can easily be tracked from the circuit to the fuseaction, and finally to the fuse itself, extremely quickly. Developers can also use ColdFusion's XML tags and functions to extend the fusebox.xml and circuit.xml files to do other things — to produce mind maps, site maps, and other documentation.
Fusedocs are another example of XML in Fusebox. Fusedocs are a way to very clearly document Fusebox code. As one developer put it, "You're not documenting your code, you're coding your documentation." Each Fusedoc contains a section, stating what the fuse is supposed to do. It also contains an and an section that lists any variables or record sets expected or produced by a fuse. Like circuit.xml files and fusebox.xml files, Fusedocs can be manipulated with ColdFusion's XML tags and functions.
The Fusebox Community
Perhaps the greatest thing about Fusebox is the Fusebox community. The project's Web site, www.fusebox.org, contains downloads including the core files, tutorials and sample code, as well as forums monitored by the heavy-hitters while welcoming newbies with open arms.
While Mach-II and Model-Glue are gaining popularity as application frameworks using ColdFusion, Fusebox remains the most popular and best-supported of them all. It also has the flattest learning curve. However, it's not for everyone. If you're just essentially writing Hello World, Fusebox may be overkill. But if you're looking for a way to get out of the spaghetti world and start developing real, flexible, extensible, and scalable ColdFusion applications, Fusebox may just change your life.