|Some or all of this article's listed sources may not be reliable. (March 2011)|
|Stable release||5.5.1 / March 2008|
|Written in||CFML, PHP|
|Type||Web application framework|
Fusebox is a web application framework for CFML and PHP. Originally released in 1997, the current version, 5.5.1, was released in March 2008. In January 2012 the rights to Fusebox were transferred from TeraTech to a team of five developers, who have removed the rights and placed the framework in the hands of the community.
Fusebox is intended to be easy to learn and provides benefits by helping developers structure their code through a set of simple conventions. Fusebox also allows advanced developers to build large applications, leveraging design patterns and object-oriented programming techniques if they wish.
- 1 Overview
- 2 Concepts
- 3 History
- 4 See also
- 5 References
- 6 External links
Fusebox provides web application developers with a standardized, structured way of developing their applications using a relatively straightforward and easy to learn set of core files and encouraged conventions. In addition to the framework itself, Fusebox has become closely associated with a Web application development methodology developed by its proponents known as "FLiP" (for Fusebox Lifecycle Process). (Many people refer to Fusebox as a "methodology", but in fact, as stated, it's a development framework. FLiP, however, is a methodology). Many frameworks provide comparable advantages; however, Fusebox (probably on account of both its relatively long history and the sizable and active community that supports it) seems to be the most popular one for CFML. The framework has been ported and used in ASP, JSP, Lasso, Perl/CGI and PHP as well, though the CFML and PHP versions of Fusebox are the only versions to gain momentum.
It is important to note that Fusebox deals primarily with the effort of wiring together view states (pages) with controller actions (form submits, etc.) and the front-end of the business-logic tier. The framework does not address creating and maintaining business logic such as database interaction or service layers.
Fusebox, Circuits and Fuseactions
The original concepts behind Fusebox were based on the household idiom of an electrical fusebox that controls a number of circuits, each one with its own fuse. In a Fusebox web application, all requests are routed through a single point (usually
index.cfm for CFML) and processed by the Fusebox core files. The application is divided into a number of circuits (usually in sub-directories) which are intended to contain related functionality. Each circuit in the application is further divided into small files called fuses that should perform simple tasks. As such, Fusebox is considered an implementation of the front controller, a common design pattern.
URLs within a Fusebox web application are usually of the form
index.cfm?fuseaction=cname.fname where "
cname" is the name of a circuit and "
fname" is an XML-defined "method" within that circuit known as a fuseaction. The query-string variable name "fuseaction" can vary depending on configuration parameters, so not all applications using Fusebox need to use the action variable "fuseaction".
Fusebox encourages, but does not enforce, separation of presentation logic from business logic. It uses a number of file naming conventions to encourage this separation: presentation files begin with dsp (display) or lay (layout), database access files begin with qry (query) and general business files begin with act (action). Typical file names are in the format [prefix]_[filename] like dsp_loginform.cfm. Additional naming conventions are used by some Fusebox developers but these are the most common ones.
Another concept that Fusebox encourages is to parameterize any exit points in a web page, coding them as variables that are set in the circuit control file. These exit points are known as XFAs - eXit FuseActions. The idea is that by parameterizing the exit points in a web page, the flow of control can be updated more easily, allowing more reuse of web pages or fragments thereof.
Associated with the framework, but not strictly part of it, is the concept of FuseDocs which is a semi-formalized form of documentation written in XML that specifies the inputs and outputs of each fuse file. There are third-party tools available which can use FuseDocs to do things like generate test harness code.
Fusebox has had several major revisions over the years. The most popular versions in use today are Fusebox 3, 4 (including 4.1) and 5. In Fusebox 3, the control files were all written in the underlying programming language (e.g., fbx_Switch.cfm for CFML). Fusebox 4 and later versions use XML for the control files (fusebox.xml and circuit.xml), but other framework components are written using the underlying programming language (e.g. fusebox5.cfm, again for CFML). In theory, this helps improve tool support for the framework. It also allowed for the pre-parsing and generation of a single template for processing each fuseaction, greatly increasing performance. Fusebox 5.5 allows the XML files to be omitted if certain conventions are followed.
Fusebox (version 1)
Fusebox 1 grew out of a conversation on the CF-Talk mailing list in April 1998. Steve Nelson and Gabe Roffman are credited with creating the original Fusebox though the first Fusebox program was written by Josh Cyr. The methodology was constantly evolving and beyond a whitepaper and a handful of examples, no official documentation existed. Very few developers were exposed to Fusebox during these early days.
Craig Girard and Steve Nelson (along with Hal Helms and Nat Papovich) wrote a book, Fusebox: Methodology and Techniques, which was published in 2000 by Fusion Authority. Programmers who followed the practices described in the book were said to be doing "Fusebox 2."
Hal Helms built upon Fusebox 2 and called his ideas eXtended FuseBox, or XFB.
Fusebox 3 (written primarily by Hal Helms, John Quarto-von Tivadar and Nat Papovich) was an effort by leading members of the Fusebox community to incorporate XFB and other ideas into a reusable library, known as the "core files." A simple API allowed application code to communicate with the core files. Upon release in the fall of 2001, Fusebox became a framework rather than a methodology. A subsequent 3.01 release addressed minor issues. Fusebox 3 was something of a sea-change from Fusebox 2. Only the original principles remained relatively unchanged; a Fusebox 2 and Fusebox 3 application are structured very differently.
Fusebox 4 was a complete rewrite of Fusebox 3. The license for the core files (which is open source) is held by a private company owned by Hal Helms and John Quarto-von Tivadar: The Fusebox Corporation (which appears to be a defunct corporation).
Fusebox 4.1 introduced some new XML grammar elements beyond those available in 4.0 that let you declare, instantiate and manipulate objects (COM, Java and ColdFusion Components) as well as web services. These features have provided Fusebox developers with the means of tying object-oriented models (i.e. business-logic) directly into their controllers. However, many Fusebox developers used object-oriented or highly structured models in earlier versions of Fusebox or in the current versions without use of these grammar elements.
In 2006, The Fusebox Corporation asked Sean Corfield to take the lead in developing the next iteration of Fusebox. Fusebox 5 was another complete rewrite with new features and improved performance. Fusebox 5 nearly completely maintained backwards-compatibility with Fusebox 4.1. In November 2006 The Fusebox Corporation transferred ownership of the core files and fusebox website to TeraTech under the guidance of TeraTech president and Fusebox speaker Michael Smith. TeraTech announced that Fusebox will remain open source and is seeking to increase community involvement in the project again. Fusebox 5.1 and all subsequent releases are licensed under the Apache Source License 2.0. In February 2007 the members of Team Fusebox met at the Frameworks conference in Bethesda Maryland and created a plan of action for community involvement using volunteers in nine different areas of Fusebox.
This release focused primarily on adding a set of conventions that allow the creation of Fusebox applications without XML configuration files. The use of these new features instead of XML is called "implicit Fusebox".
- Alpha testing began in June 2007
- A Public Beta became available at Adobe MAX in October 2007
- The official release of Fusebox 5.5 became available at the beginning of December 2007
Fusebox 5.5.1 and FuseNG
The release of Fusebox 5.5.1 in March 2008 was the last release by Sean Corfield. In August 2008, Adam Haskell took over development, but became frustrated with the Fusebox organization, and attempted to branch a new framework called FuseNG (NG for Next Generation, a Star Trek reference). FuseNG quickly lost steam and ended without a release.
In January, 2012, a team of five community developers led by John Blayter announced on the Fusebox mailing list that they had obtained the rights and copyright of Fusebox from TeraTech. The framework code has had the copyright removed and is available at GitHub to encourage community participation. Experienced Fusebox developers vetting any changes which are submitted. Fusebox 5.6 goals have been announced, but there is currently no target date.
- Contributors - Fusebox
- Yahoo! Groups
- Open Letter to Custodians of Fusebox
- Final FuseNG Update
- Fusebox 5.6 - Fusebox
- Official Website, Fusebox.org
- Official Fusebox mailing list, at Yahoo Groups
- An Introduction to ColdFusion frameworks, at Adobe DevNet
- Fusebox 4 Review (sys-con.com, September 2003)
- Fusebox 3 Feature (sys-con.com, November 2001)
- Fusebox mailing list at House of Fusion