FuseBox now has its own Wiki at http://www.meta-magic.com/cgi-bin/fusewiki
* ''This is a "dead" - actually a placeholder search engine squatter page link as of 5/2005''

FuseBox is a WebApplication programming methodology currently being developed primarily for use with AllaireColdFusion. There are also developers applying FuseBox principles to ActiveServerPages and JavaServerPages as well as PHP. Version 4 of the FuseBox architecture is already released.

----
For an excellent description of Fusebox and its advantages, see:
 Extreme Programming and Fusebox
  http://halhelms.com/writings/XPandFusebox.pdf
  ''Skip down to the section titled: '''Fusebox: An Overview'''''
----

The Fusebox is a script which acts as a controller (typically called index.cfm). In previous versions it contained a Switch/Case statement. Every request to a FuseBox application calls the index.cfm and passes a FuseAction attribute to the switch. The index file selects the proper case statement (called a fuse) and includes the files needed to fulfill the request. When the files in the switch have been processed the result is typically passed to display wrappers.

Example FuseBox fbx_Switch.cfm

  <cfswitch expression="#fusebox.fuseaction#">

	<cfcase value="display">
		<cfinclude template="sql/act_wiki.cfm"> 
		<cfinclude template="dsp_wiki.cfm">	
	</cfcase>

	<cfcase value="edit">
		<cfinclude template="sql/qry_text.cfm">
		<cfinclude template="frm_wiki.cfm">
	</cfcase>

	<cfcase value="update">	
		<cfinclude template="sql/act_updateblurb.cfm">
		<cfinclude template="url_display.cfm">
	</cfcase>

	<cfcase value="results">
		<cfinclude template="sql/qry_wikiresults.cfm">
		<cfinclude template="frm_search.cfm">	
		<cfinclude template="dsp_results.cfm">	
	</cfcase>
	
	<cfdefaultcase>		
		#fusebox.fuseaction# is not a valid task in this circuit.
	</cfdefaultcase>

  </cfswitch>
Each included file has a prefix such as:
  qry_ (a select query)
  act_ (an action query)
  dsp_ (a display file mostly HTML)

  (See below for more)
Fusebox resources:
  http://www.fusebox.org be sure to see the Powerpoint presentations
  http://www.halhelms.com
How common is FuseBox?
  Go to http://www.google.com and search for "fuseaction".
  This is the most common name for the fuse attribute passed in the URL.
-----------------

'''Fuse-Box Criticism'''

It seems FuseBox marries one to a hierarchy (LimitsOfHierarchies) such that going outside the hierarchy can get messy. For example, if your header and footer variation patterns fit the hierarchy, you are fine. However, if not then you have to have a bunch of flags and IF statements to pick the proper headers and footers. It has the assumption that "everything in group X will always have such and such", which often turns out not the be the case. 
* ''This is caused by a misunderstanding of hierarchies. Everything in group X *will* have such and such, because having such and such is a defining characteristic of group X. If you don't have such and such, you aren't in group X, by definition. Note that one of the things you could have would be a header file''
* Even many OOP designers have found that hierarchies often don't scale well, preferring composition instead of hierarchical polymorphism. I tend to dismiss the idea that hierarchies can capture variations well. They are often subject to the EightyTwentyRule. Now you may argue that some of us are "Tree Blind", just not skilled enough to "see" the real hierarchies in the domain, but until I find some good training material that helps one to identify and isolate pure, clean hierarchies in the real world, I have to reject them from my perspective. At this point, I have to agree with LimitsOfHierarchies that such purity is only a pipe dream.

Also, the switch statement seems more about finding files than it is about managing complexity. Seeing every single INCLUDE file needed to carry something out is not always good information hiding in many cases. Implementation details (special include files) hog just as much attention as the key files. If you want to find include files, then use a code indexer tool rather than be the code indexer.

Here is a specific example. I have a report page with a graph on the bottom. The chart uses an include file for the obvious reasons. However, the report needs an optional foot-note at the bottom below the chart. Thus, a sample page may look like:

    ---------------------
    Page Title
    ---------------------
    Report Details
    ...
    graph
    ...
    foot-note (optional)
    ---------------------
Using the Fuse-box approach requires that the foot-note be a separate include file. That is a lot of coding and unnecessary files for a simple, and optional feature. If I just include the graph file in the middle of the page, the foot-note remains a simple item:

   report start stuff...
  
   report detail stuff...

   includefile("myGraph.prog")

   if Not blank(footNote) then
     show_footNote(footNote)
   end if
Another thing, later Fuse-box frameworks seem to expect two "path systems", one for files and one for an internal "circuit" classification. I have not encountered very many situations where one wants to have and maintain two separate hierarchies. One is difficult enough (and hierarchies themselves are suspect per above), two is a mess. But, if you don't want to maintain two separate hierarchies (circuit paths match file paths), the indirection in the frame-work is overkill. 

-- AnonymousDonor
----

I don't like the FuseBox methodology, because it uses a fragile and non-explicit mechanism (magic variables and include files) to implement behaviors. I prefer to modularize (in ColdFusion) using custom tags and custom function libraries to implement miniature declarative languages. These are far more powerful than using include files, because you can nest them in interesting ways, pass in arguments (that can be any type of variable), and provide separate namespaces (include files are like C/C++ macros, they're expanded before execution so they can and will step on the namespace of the caller, custom tags are like functions). -- ChrisMellon

I agree. The Fuse-box framework seems to have the '''sandwich philosophy''' that you easily can build and manage applications by controlling behavior as slices of bread, meat, and condiments (include files). Fuse-box allegedly makes it easy to control, or at least see, how these layers are put together. The big case statements show the bread layers in one or few spots. For simple stuff this may be fine, but for more complicated stuff it does not work well. Hierarchical "circuits" are not powerful enough to control non-hierarchical feature management, and parameters that fine-tune stuff are often needed. Parameters are a cleaner way to control such variations than global or semi-global variables. Nor does it hide implementation details well when low-level include files (libraries) bloat up the sandwich lists, as described above. It can be hard to find the meat. 

However, part of the Fuse-box philosophy comes from managing teams that focus on specific things. It may be easier for graphics designers to relate to files than to parameters and function libraries. 

-- AnonymousDonor

---------------

Here are some general FuseBox file categories and abbreviations I have found useful:

* '''act''' - Actions
* '''fmt''' - Formatting, templates, and page headings
* '''frm''' - Forms - Data entry
* '''dsp''' - Display - Reports and output
* '''qry''' - Sql queries
* '''hlp''' - Help and document files (alternative: "doc")
* '''msc''' - Miscellanious - Those not fitting other categories, such as constants
* '''sys''' - System settings or utilities
* '''dev''' - Development tools and utilities

Traditionally, too much is stuffed under "Display", so this attempts to split some of those into Forms and Formatting.

----
See also: FuseBoxLite, WebScriptFileStructure