©2003 the fusebox corporation fusebox mx hal helms

©2003 The Fusebox Corporation

Fusebox MX

Hal Helms


Fusebox MXbeta.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

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 oth

er 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

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"

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

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

beta.fusebox.org


Properties

<properties><property name="defaultFuseaction" value="login" /><property name="approot" value="/Librarian" /><property name="fuseactionVariable" value="fuseaction" /><property name="argumentsPrecedence" value="form" />

</properties>

beta.fusebox.org


Circuits

<circuits><circuit name="user" type="myApp.model.user" /><circuit name="yourCircuit"

type="myApp.model.otherCircuits.yourCircuit" />

</circuits>

beta.fusebox.org


Events

<events><event name="loginEvent" type="myApp.controller.LoginEvent" />

<controller><view name="success" path="/view/main.welcome.cfm"

action="include" />name="failure" path="view/users.login.cfm"

action="include" /></controller>

</event></events>

beta.fusebox.org


Fuseactions

<fuseactions><fuseaction name="authorizeLogin" event="loginEvent" /><invoke circuit="user" method="getUserInfo" resultKey="request.userInfo" />

</fuseaction></fuseactions>

beta.fusebox.org


Plugins

<plugins><plugin name="securer" type="myApp.plugins.Securer"> <parameters>

<parameter name="type" value="bit" />

</parameters></plugin>

</plugins>

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

<form action="index.cfm" method="post"><input type="hidden" name="fuseaction" value="welcome" />

…

beta.fusebox.org



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.xmland places any form and URL variables into that event

5. The FuseactionContext notifies each registered listener, passingthe Event to each circuit's specified method

beta.fusebox.org



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 todetermine 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

beta.fusebox.org


The Fusebox class diagram

Larger images and XML files/UML diagrammer link available at beta.fusebox.org

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

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)

beta.fusebox.org


Building a simple FBMX application

Instructions for this are available under "Getting Started" at beta.fusebox.org

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

beta.fusebox.org


Why not use Fusebox?– you're being paid by your competitor to sabotage

your company'sdevelopment 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!

©2003 the fusebox corporation fusebox mx hal helms

Documents