Prelude to Fusebox Prerequisite Understanding: / 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. Create the index.cfm files 2. Create Fuseactions in index.cfm 3. Create Fusedocs for fuses 4. Write fuses 5. 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.... More on the custom tag later…

Model-View-Controller Approach This is Meant to Be Just text That isn’t Clear. I hope It works the Way I want It to. dsp_UserLogin.cfm Fusebox (controller) Request This is Meant to Be Just text That isn’t Clear. I hope It works the Way I want It to. cf_do_logic Name: Stan Cox Intelligence: Monumental Bravery: Stunning HTML Returned (model) (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

File Naming Conventions (Fuses) app_globals.cfm – File defines variables, instantiates application request.mainDSN, request.webroot, request.mypath 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. Javascript:window.location=‘index.cfm?fuseaction=Buy’ or

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 But this Fusebox can in turn, be called by a higher Fusebox…

Extended Fusebox Code

Fusebox Glue / app_layout.cfm Application.cfm security app_server.cfm Search-engine safe URLs via modified cf_formurl2attributes 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 - home, sites using Fusebox - version 3 application sales repository - mailing list - primers and Fusedocs - frames - home of fUseML - tutorials and tools - IRC info and archives - purchase Fusebox book