Fusebox: An Overview, Part I
Welcome to the first part of a series we are doing on the Fusebox methodology. We hope this article is helpful in answering some of the questions we've been seeing about just what Fusebox is and why it's so useful.
What is Fusebox?
Fusebox is a "wave" that is sweeping the ColdFusion community. A coding standard and program methodology, it is quickly becoming popular among ColdFusion coders. In fact, it has even been ripped off?err?adapted for use with other web programming languages! The reason it is so popular is that it does an excellent job of filling the standards void in the ColdFusion development community.
Steve Nelson and Gabe Roffman developed Fusebox in 1998 because they needed a way to collaborate efficiently on projects. They had to solve problems like finding a way to write object-oriented code and to make scalable applications, while at the same time making it easier to read and document their code. In the end, they delivered an idea that was much more than they expected. Fusebox began to spread as quickly as ColdFusion's phenomenal popularity.
|
Fusebox is a ColdFusion programming methodology. Using Fusebox for building applications has the following benefits:
|
|
To understand a Fusebox application, you need to know: |
The Physical Design of a Fusebox Application
At first Fusebox can be a bit difficult to understand, especially if you?ve never worked with modular code or in an object-oriented environment. Perhaps the hardest thing to get about Fusebox is that it?s really quite simple! Once you wrap your mind around a few concepts, it becomes very easy to grasp. First, let?s have a look at the physical setup of the Fusebox architecture.The main idea behind Fusebox is to break down your application into modules, or small pieces that do simple, specific tasks. These tasks are called fuses -- I?ll explain why in part II of this article. Each individual "fuse" module is made up of smaller sections of code that serve specific purposes, which are broken down into five categories: Actions, Display Blocks, Queries, Application Files and ColdFusion Custom Tags. These are actually implemented by files that contain ColdFusion and HTML code. The reason for breaking down the files in this way is that it makes it very easy to reuse them. You?ll end up with a smorgasbord of files that comprise your application. Later, I will explain how to use the CFINCLUDE statement to throw these files together on the fly to make your files work together.
For example, if you had a small application that queried your database and then displayed the results, you would separate the query itself from the code that displays the results. Each of the two pieces would go into its own separate file, which would be named in specific way to make it easy to identify its function.
- The file containing the SQL query, for instance, would be placed in your QUERIES directory and named qry_what_this_query_does.CFM.
- The file that contains the code to display the results of your query would begin with the dsp_ prefix and be placed in the BLOCKS directory. The file might be called dsp_what_this_code_displays.cfm.
|
Missing Includes In older versions of CF, a missing include file could be hard to track down, as the error message didn?t say the name of the file that couldn?t be found. CF version 4.01 solved this problem. Error messages now refer to the page and line from which the include file is missing. |
<CFINCLUDE TEMPLATE="path\template_name"> |
A bit earlier, we gave the file that contains our query a simple prefix and placed it in a specially named directory. To keep your Fusebox applications standard, you always use the Fusebox prefixes for the different types of files and put them into the proscribed directories. To make this easier, I suggest that the first thing you do when you start a Fusebox application is to set up your directory tree. The basic tree structure looks like this:
This physical organization is very important to standard Fusebox coding. With this directory structure in place, the CFINCLUDEs necessary to do the job of querying the database and then displaying the results would look something like:
<CFINCLUDE template="../queries/qry_what_this_query_does.CFM"> <CFINCLUDE template="../blocks/dsp_what_this_code_displays.cfm."> |
Notice that we are using relative paths in the example above. Although it is possible to do your CFINCLUDEs this way, the preferred method is to create CF mapping to the root directory of each application. The CF mapping can only be used with the CFINCLUDE and CFMODULE tags. This way you can call a file from anywhere in your site, without having to worry about relative references to the file. For example:
<CFINCLUDE template="/ROOTMAPPING /queries/ qry_what_this_query_does.CFM " > <CFINCLUDE template="/ROOTMAPPING/blocks/ dsp_what_this_code_displays.cfm "> |
As illustrated below, CF mappings are set in CF Administrator.
Figure 1: Creating a mapping in the Cold Fusion Administrator
So now you have an idea of how to physically set up your application. You have also seen how your code must be broken down into small modular pieces. Stay Tuned for Part II of this article, where we'll get down to the nitty gritty of coding in Fusebox.