Fusebox (programming)

From Wikipedia, the free encyclopedia

Fusebox is a web application framework for ColdFusion and PHP. Originally released in 1997, it is currently in its fifth major incarnation. The current version, Fusebox 5.5, was released to the world at the beginning of December 2007.

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.

Contents

[edit] Overview

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". (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 ColdFusion. Also the framework itself has been ported and used in ASP, JSP, Perl/CGI and PHP as well. (Other than ColdFusion, the PHP version of Fusebox is the only version 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.

[edit] Concepts

[edit] 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 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, 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".

[edit] Naming Conventions

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.

[edit] Exit Fuseactions

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.

[edit] FuseDocs

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.

[edit] History

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 5.5 allows the XML files to be omitted if certain conventions are followed.

[edit] Fusebox (version 1)

Fusebox 1 grew out of a conversation on the CF-Talk mailing list in April of 1998. The participants included Michael Dinowitz, Josh Cyr, Steve Nelson and Gabe Roffman. Nelson and 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.

[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 by Fusion Authority. 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 unchanged; 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.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.

[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. 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.

[edit] Fusebox 5.5

The major thrust of this release was to enshrine a set of conventions that allow Fusebox applications to be built without requiring XML files to specify configuration and behavior.

  • 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

[edit] Fusebox 5.6 and 5.7

The next two releases of Fusebox will be evolutionary with the plan to unify Fusebox 3 and Fusebox 4/5 by the time Fusebox 5.7 is released toward the end of 2008.

[edit] See also


v • d • e
List of Web Application Frameworks
ASP.NET
ColdFusion
ColdSpring · Fusebox · Mach-II · Model-Glue · onTap
Java
Client-side
Perl
PHP
Python
Ruby
Camping · Nitro · IOWA · Ramaze · Cerise · Merb · Ruby on Rails
Server-side JavaScript
Other/
Multiple languages


[edit] External links