Prelude to Fusebox
Prerequisite Understanding:
<cfinclude>
<cflocation>
<cfswitch> / <cfcase>
<cfapplication>
Variable scopes:
session/client/application/request/attributes/caller
Custom tags
URLToken
If you don’t understand any of these, please tell me!
An Introduction to Fusebox
Methodology and Techniques
Finally – A True Standard for
ColdFusion’s Most Proven and
Popular Application Architecture
Presented by Nat Papovich – Webthugs Consulting
Developed by the Fusebox Community including Hal
Helms, Jordan Clark, Steve Nelson, Fred Sanders, Jeff
Peters, Russ Johnson, Ken Beard, and Stan Cox
Why Fusebox? What Is Fusebox?
Structured architecture - scalability, maintainability,
modularity
Facilitates team development
Self-documents your application
Allows repeatability
Large community
Proven but evolving
Community-driven
Extensible - Fusebox for PHP, JSP, ASP
Quick to learn
Free
General Fusebox Theory
Index.cfm is controller - all interaction goes through the
Fusebox via Fuseactions
Multiple index.cfms for sections of the site, called circuits
Root index.cfm handles global variables, root requests
Index.cfm acts via cfcase, including files (fuses) and logic
If a circuit blows up, the entire site is not blacked out
Electrical fuse box metaphor
Circuits are modular, thus reusable
New Extended Fusebox (Hal-style) standard calls for no
home application:
 All circuits standalone with individual cfapplication tags
and no global variable dependencies – cfparam all vars
 All circuit index.cfms are cfincluded, not cflocationed
First Steps (Pre-Coding)
1. Produce a quality specification


Nothing Fusebox specific here
Be on the lookout for Secretagents.com spec tool
2. Use fUseML or another modeling tool to make the
design including directory structure


fUseML is derived from the UML
Build design taking index.cfm interaction (Fuseactions)
into account
3. Create stringent Fusedocs for all fuses


Fuses should not be dependant on any variables not
explicitly stated
Make assertions if necessary
Creating A Fusebox Application
1.
2.
3.
4.
5.
Create the index.cfm files
Create Fuseactions in index.cfm
Create Fusedocs for fuses
Write fuses
Stand back and marvel
Create the Index.cfm Files
Every directory (circuit application) has one index.cfm
file
Index.cfm controls all the Fuseactions of that circuit
application
It is the Fusebox
All links and form submissions go to the index.cfm
It is a single cfswitch statement with multiple cfcase
statements
Each cfcase is a different Fuseaction
The Fusebox Code
<!--index.cfm-->
<cf_formURL2attributes>
<cfinclude template=“app_globals.cfm”>
<cfparam name=“attributes.fuseaction” default=“login”>
<cfswitch expression=“#attributes.fuseaction#”>
<cfcase value=“login”>
<cfif blah>
<cf_do_logic>
</cfif>
<cfinclude template=“dsp_UserLogin.cfm”>
</cfcase>
....
</cfswitch>
More on the custom tag later…
Model-View-Controller Approach
Request
<a href=“index.cfm?fuseaction=login”>
This is
Meant to
Be Just text
That isn’t
Clear. I hope
It works the
Way I want
It to.
cf_do_logic
(model)
Fusebox
(controller)
This is
Meant to
Be Just text
That isn’t
Clear. I hope
It works the
Way I want
It to.
dsp_UserLogin.cfm
<!--- dsp_UserLogin.cfm --->
<td>Name: Stan Cox</td>
<td>Intelligence: Monumental</td>
<td>Bravery: Stunning</td>
HTML Returned
(view)
Create the Fuseactions
A Fuseaction may cfinclude
.htm/.cfm; cfmodule;
cflocation; contain limited cfml
A Fuseaction may NOT display
anything to the browser or
contain “open” SQL
Determine what steps are
needed to complete each
Fuseaction
Add those steps inside each
cfcase statement
<cfcase value=“MainPage”>
<cfif client.IsLoggedIn>
<cflocation url=“index.cfm?fuseaction=login”>
<cfelse>
<cfinclude template=“dsp_HomePage.cfm”></cfif>
</cfcase>
<cfcase value=“InsertRecord”>
<cfinclude template=“act_InsertNewEmployee.cfm”>
<cfmodule template=“conf/index.cfm?fuseaction=main&ID=7”>
</cfcase>
File Naming Conventions (Fuses)
app_globals.cfm – File defines variables, instantiates application
request.mainDSN, request.webroot, request.mypath
<cfif not IsDefined(“application.applicationname”)>
<cfapplication name=“blah”></cfif>

dsp_filename.cfm - Display file

Only file that contains HTML or any output to browser
act_filename.cfm - Action file

Only file allowed to perform actions on the database – updates,
inserts, deletes, selects allowed, but only in conjunction with action
qry_filename.cfm - Query file

Extremely modular file can be called “willy-nilly” throughout
application, performs selects on database
Fusedoc Documentation Standard
A Fusedoc outlines responsibilities, customizations, and
expectations of fuses, and is unique to each fuse
No fuse can assume the existence of any variable unless it is
noted in the Fusedoc for that fuse
Once completed, a Fusedoc should provide all the information
needed to code the fuse – no interaction with application
architects or previous specifications should be needed
A Fusecard contains the following elements:
 Name of the file
 Responsibilities (non-technical, plain English, derived from
the application design/fUseML)
 Author / coder
 Variables list (incoming, outgoing, and persistent)
Fusedoc Legend
-->
<-<->
++>
explicitly passed incoming parameter
explicitly passed outgoing parameter
pass-thru parameter (unchanged)
existing persistent parameter
(session, client, etc.)
<++ created persistent parameter
+++ included file
[parameter] brackets indicates optional
Examples:
--> CurrentUser: a WDDX STRUCTURE
<-- [badLogin]: optional, a STRING
<++ Session.ColorChoice: a STRING (Red|Blue)
<-> UserID: an INTEGER
+++ myGlobals.cfm
Create the Necessary Fuses
Because the Fusedocs are so carefully built, and the design so
thoroughly thought out, individual fuses can be “farmed out” for coding
Remember – all links and form actions go to index.cfm, specifying
which Fuseaction to perform; never to the specific dsp or act files.
<a href=“index.cfm?fuseaction=startCheckout”>
Javascript:window.location=‘index.cfm?fuseaction=Buy’
<form action=“index.cfm?fuseaction=NewProduct”>
or
<input type=“hidden” name=“fuseaction” value=“NewProduct”>
<cfmodule template=“index.cfm” fuseaction=“AuthorizeCard”>
<frame src=“index.cfm?fuseaction=BuildLeftFrame”>
Version 2: Putting It All Together
One entire application is made up of many smaller
circuit applications
One circuit application is made up of a directory of
files
Each circuit must contain an app_locals.cfm and
index.cfm file plus other display/action/query files as
Fuses
One index.cfm file is made up of one or more
Fuseactions
One Fuseaction includes one or more
display/action/query files plus any necessary CFML
logic
Extended Fusebox: Putting It All Together
Version 2 calls for multiple Fuseboxes to be tied together with
cflocation or cfmodule
Version 3 ties Fuseboxes together with cfincludes ONLY
There are no longer “circuit” and “home” apps – all index.cfms
function standalone – loosely coupled
Any Fusebox can cfinclude any other Fusebox without knowing or
caring what variables are used or what the Fusebox’s architecture is
When the Fuseboxes are collected, they are called from the highest
Fusebox only using “dot-notation” href and form action
All hrefs and form actions call the current index.cfm which, when
Fuseboxes are cfincluded, means the highest Fusebox in the chain,
without having to recode links
<a href=“index.cfm?fuseaction=catalog.view&ID=3&cat=2”>
<a href=“catalog/index.cfm?fuseaction=view&ID=3&cat=2”>

But this Fusebox can in turn, be called by a higher Fusebox…
Extended Fusebox Code
<cfswitch expression=“#listfirst(attribs.fuseaction,“.”)#”>
<cfcase value=“cat”>
<cfset attribs.fuseaction=listRest(attribs.fuseaction,“.”)>
<cfinclude template=“../dir/cat/index.cfm>
</cfcase>
<cfcase value=“members”>
<cfset attribs.fuseaction=listRest(attribs.fuseaction,“.”)>
<cfinclude template=“/apps/index.cfm”>
</cfcase>
<cfcase value=“Info”>
<cfinclude template=“qry_ExCheck.cfm”>
<cfinclude template=“dsp_FormPage.cfm”>
</cfcase>
</cfswitch>
Fusebox Glue
<cf_bodycontent> / app_layout.cfm
<cf_formURL2attributes>
Application.cfm security
<cfif ListLast(GetTemplatePath(),'\') is not
“index.cfm”>
<cflocation url="/index.cfm?fuseaction=logoff2">
</cfif>
<cf_returnfuseaction>
app_server.cfm
Search-engine safe URLs via modified cf_formurl2attributes
<a href=“index.cfm/fuseaction/main/ID/8/cat/9.cfm”>
Verity friendly Fusebox in the works (store content in database)
Exit Fuseactions (XFA)
Fusebox: The Final Word
Fusebox is nothing radical – sophisticated, large
applications use the MVC approach, whether CGI,
Java/J2EE, C++, PHP, ASP, etc
No one owns Fusebox – it will evolve and grow to meet
any need or new technology
Plug-n-Play saves you tons of time (time=money)
Other choices exist – but Fusebox is the proven solution
Purchase completed applications or cut-n-paste old code
Fusebox Resources
www.fusebox.org - home, sites using Fusebox
www.boxofuses.com - version 3 application sales repository
www.houseoffusion.com - mailing list
www.halhelms.com - primers and Fusedocs
www.webthugs.com/consulting - frames
www.fuseml.org - home of fUseML
www.secretagents.com - tutorials and tools
www.grokfusebox.com - IRC info and archives
www.fusionauthority.com - purchase Fusebox book