Fusebox (programming)

From Wikipedia, the free encyclopedia

Fusebox is a popular web development framework for ColdFusion and other web development languages. Fusebox provides Web application developers with a standardised, 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". (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 sizeable and active community that supports it) seems to be the most popular one for ColdFusion. Also the framework itself has been ported and used in ASP, JSP and PHP as well. (Other than ColdFusion, the PHP version of Fusebox is the only version to gain momentum.)

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 ColdFusion) 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 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 paramters, 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.

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 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 ColdFusion). 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 ColdFusion). 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 4.1 introduces 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.

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.

1 History
2 External links

[edit] History

[edit] Fusebox (version 1)

Steve Nelson and Gabe Roffman are credited with creating the original Fusebox, a programming methodology, in 1998. 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.

[edit] Fusebox 2

Craig Girard and Steve Nelson (along with Hal Helms and Nat Papovich) wrote a book, Fusebox: Methodology and Techniques, which was published in 2000. Programmers who followed the practices described in the book were said to be doing "Fusebox 2."

[edit] XFB

Hal Helms built upon Fusebox 2 and called his ideas eXtended FuseBox, or XFB.

[edit] Fusebox 3

Fusebox 3 (written primarily by 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 unmolested; a Fusebox 2 and Fusebox 3 application are structured very differently.

[edit] Fusebox 4

Fusebox 4 was a complete rewrite of Fusebox 3. The core files license (which is open source) are 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

[edit] Fusebox 5

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.