Fusebox isn’t a programming language. It’s a methodology that can be used whether your preferred language is ColdFusion, PHP, or ASP. You’re likely visiting a site designed with Fusebox when every page of the site is located at index.php. (Depending on the language you use, this may be index.cfm or index.asp. For the rest of this article I will use the php file extension, but Fusebox is not tied to the PHP language.) The arguments in the query string are the only thing that changes in the URL as you go from page to page. Unless you’re looking at the URL, you won’t even know that a site uses Fusebox.

You may be asking yourself, “If I invest the time to learn this methodology, what’s in it for me?” I can only speak from my own experience, but I’ve noticed a few perks that compel me to write with Fusebox whenever I have the option.

Code is much easier to reuse. With Fusebox you break your code down into very small chunks, which are then used like building blocks to assemble a complete page. A single block (for example a chunk of code displaying your site’s search box) can be used across multiple pages. Reusable code is nothing novel, but the architecture of Fusebox makes it very easy to organize and reference each individual piece. When I’m writing new code that is similar to a previous project, Fusebox’s organizational structure makes it simple to copy the appropriate chunks of code into the new project and start modifying them.

The consistent framework also makes it much easier for multiple programmers to work on a single project. Each person understands how Fusebox works, and knows exactly how the different pieces of code are going to be formatted to interact. This benefit is present when multiple programmers are working on a project at the same time, but it also holds true if they are working years apart. If I look at Fusebox code that someone wrote years ago, I can quickly and easily read it and understand the logic. Maybe you’re so fortunate as to seldom need to look at code someone else wrote. Maybe you only need to maintain your own code, but if you’re anything like me some of the code you wrote a few years ago looks like another person wrote it! Fusebox let’s you jump right back in and recall what you were thinking way back when.

I’ll be honest, I don’t always use as much inline documentation as is probably recommended. One of the reasons I can get away with it is the very structure of Fusebox is nearly a pseudo-documentation structure. You’re breaking code into very small pieces, and you have to give each piece a unique name. I can’t help giving them names that sum up exactly what each piece of code does. If you come across a file named DisplayBooksByAuthor.php, you’ve got a pretty good idea what to expect.

If you take your documentation a little more seriously, Fusebox has a formalized system called Fusedocs in which you use an XML format at the top of each chunk of code with information such as author, revision history, input parameters, and intended output. Why use a structured XML setup? Because there are many third party Fusebox-based software packages that can parse your documentation. Click a button, and all of the documentation in your code is written into a single report. (Incidentally this type of report makes for a great deliverable to customers who don’t value the behind-the-scenes work that goes on in creating a website. Put a thick stack of paper in their hands, and they “get” it.)

With all these advantages, you might expect that Fusebox is a complicated system that will take lots of study. That’s not the case at all. Remember that Fusebox isn’t a language. Your native programming language still does the heavy lifting. Fusebox is just the straw boss that wrangles all the work together, and it has a pleasantly low barrier to entry. Read more about getting started with Fusebox at www.fusebox.org.

filed under: Web Development