200 likes | 375 Views
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!.
E N D
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) • Produce a quality specification • Nothing Fusebox specific here • Be on the lookout for Secretagents.com spec tool • 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 • 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 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 (view) <!--- dsp_UserLogin.cfm ---> <td>Name: Stan Cox</td> <td>Intelligence: Monumental</td> <td>Bravery: Stunning</td> HTML Returned
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 Create the Fuseactions <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