Вы находитесь на странице: 1из 20

Prelude to Fusebox

Prerequisite Understanding:
<cfinclude>
<cflocation>
<cfswitch> / <cfcase>
<cfapplication>
Variable scopes:
session/client/application/request/attributes/ca
ller
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
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
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
 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
<a href=“index.cfm?fuseaction=login”> Request

This is
Meant to
Be Just text
That isn’t
Clear. I hope
It works the cf_do_logic
(model)
Way I want
It to.

Fusebox
(controller)
This is
Meant to
Be Just text
That isn’t
Clear. I hope
It works the
dsp_UserLogin.cfm
(view)
Way I want
It to.

<!--- dsp_UserLogin.cfm --->


<td>Name: Stan Cox</td>
<td>Intelligence: Monumental</td>
<td>Bravery: Stunning</td>

HTML Returned
Create the Fuseactions
A Fuseaction may cfinclude Determine what steps are
.htm/.cfm; cfmodule; needed to complete each
cflocation; contain limited Fuseaction
cfml
Add those steps inside each
A Fuseaction may NOT
display anything to the cfcase statement
browser or contain “open”
<cfcase value=“MainPage”>
SQL
<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
<a href=“index.cfm?fuseaction=startCheckout”>
dsp or act files.
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

Вам также может понравиться