©2003 The Fusebox Corporation Fusebox MX Hal Helms

©2003 The Fusebox Corporation Fusebox MX beta.fusebox.org An apprentice carpenter may want only a hammer and saw, but a master craftsman employs many precision tools. Computer programming likewise requires sophisticated tools to cope with the complexity of real applications, and only practice with these tools will build skill in their use. — Robert L. Kruse

©2003 The Fusebox Corporation beta.fusebox.org Fusebox 3 Core Concepts  Fusebox 3 core concepts –all actions of the software occur as a response to a request made of the fusebox –code is encapsulated in circuits –circuits are made to be as independent of each other as possible (new requests return to the fusebox rather than being routed directly to another circuit) –fuses are based on "pipes and filters" where the output of one file becomes the input of the other, allowing for ease of reuse

©2003 The Fusebox Corporation beta.fusebox.org Fusebox MX  Fusebox MX is radically different from Fusebox 3 or 4  Has a new event-based, implicit invocation architecture  The entire framework is built in CFCs  Fusebox is built on the Model-View-Controller design pattern  Knowledge of object orientation is needed  Think of Fusebox MX as a "concept car"

©2003 The Fusebox Corporation beta.fusebox.org A new architecture  Fusebox has traditionally used a "pipes and filters" architecture  Fusebox MX uses an event-based, implicit invocation architecture –fuseactions cause events to be created –circuits are registered as "listeners" of events –when an event occurs, it notifies all registered listeners –all registration/configuration occurs in a Fusebox.xml file

©2003 The Fusebox Corporation beta.fusebox.org The Fusebox.xml file  Fusebox.xml made up of five sections –properties: application-wide variables –circuits: listeners of events –events: bound to views –fuseactions: bound to events –plugins: ways of extending core functionality

©2003 The Fusebox Corporation beta.fusebox.org Properties

©2003 The Fusebox Corporation beta.fusebox.org Circuits

©2003 The Fusebox Corporation beta.fusebox.org Events name="failure" path="view/users.login.cfm" action="include" />

©2003 The Fusebox Corporation beta.fusebox.org Fuseactions

©2003 The Fusebox Corporation beta.fusebox.org Plugins

©2003 The Fusebox Corporation beta.fusebox.org Fusebox MX lifecycle  The Fusebox MX lifecycle (ignoring plugins)  1. A fuseaction request is typically received by the framework by means of a URL or form variable …

©2003 The Fusebox Corporation beta.fusebox.org Fusebox MX lifecycle  2. Index.cfm calls the Application.fusebox object's handleRequest method  3. A new FuseactionContext object is created, binding that fuseaction to any registered circuits  4. The FuseactionContext creates the Event mapped in Fusebox.xml and places any form and URL variables into that event  5. The FuseactionContext notifies each registered listener, passing the Event to each circuit's specified method

©2003 The Fusebox Corporation beta.fusebox.org Fusebox MX lifecycle  6. The Event has a method, selectView, that returns a string corresponding to the name of a view specified in Fusebox.xml  7. A special, built-in listener, ViewContext, has its display method called after all circuits have been notified  8. ViewContext uses the view element specified in Fusebox.xml to determine which view to use and how to call that view  9. A view may display a page, invoke a CFC, or cause a new event to occur by calling a new fuseaction  More details available at beta.fusebox.org

©2003 The Fusebox Corporation beta.fusebox.org The Fusebox class diagram Larger images and XML files/UML diagrammer link available at beta.fusebox.org

©2003 The Fusebox Corporation beta.fusebox.org Plugins  Plugins provide the ability to expand the core framework in a controlled and modular fashion  There are six plugin points within the execution of the Fusebox MX lifecycle –preProcess –preFuseaction –postFuseaction –preView –postView –postProcess

©2003 The Fusebox Corporation beta.fusebox.org Plugins  Plugin developers write a CFC that extends the abstract CFC, FuseboxMXII.framework.Plugin  The base Plugin class has do-nothing methods for each plugin point  If you want to introduce some functionality at a plugin point, override that method (e.g. postProcess)

©2003 The Fusebox Corporation beta.fusebox.org Building a simple FBMX application  Instructions for this are available under "Getting Started" at beta.fusebox.org

©2003 The Fusebox Corporation beta.fusebox.org Final thoughts  Why use Fusebox? –easier to develop applications –easier to maintain existing code –aids in code repurposing –standard for web application development –supports teams of diverse talents and skills –provides a standardized documentation –exceptionally helpful community of developers –cross-language –helps ordinary developers achieve extraordinary results

©2003 The Fusebox Corporation beta.fusebox.org  Why not use Fusebox? –you're being paid by your competitor to sabotage your company's development efforts –framework? you don't need no stinkin' framework –you have a strong masochistic streak that enjoys the pain of your current software development process –you made a decision against Fusebox early on and haven't bothered to reevaluate it –call you crazy, but you just like to code by the seat of your pants!