Fusebox MX

1. Fusebox MX Hal Helms

2. 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

3. Fusebox 3 Core Concepts beta.fusebox.org • 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

4. Fusebox MX beta.fusebox.org • 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"

5. A new architecture beta.fusebox.org • 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

6. The Fusebox.xml file beta.fusebox.org • 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

7. Properties beta.fusebox.org <properties> <property name="defaultFuseaction" value="login" /> <property name="approot" value="/Librarian" /> <property name="fuseactionVariable" value="fuseaction" /> <property name="argumentsPrecedence" value="form" /> </properties>

8. Circuits beta.fusebox.org <circuits> <circuit name="user" type="myApp.model.user" /> <circuit name="yourCircuit" type="myApp.model.otherCircuits.yourCircuit" /> </circuits>

9. Events beta.fusebox.org <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>

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

11. Plugins beta.fusebox.org <plugins> <plugin name="securer" type="myApp.plugins.Securer"> <parameters> <parameter name="type" value="bit" /> </parameters> </plugin> </plugins>

12. Fusebox MX lifecycle beta.fusebox.org • 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" /> …

13. Fusebox MX lifecycle 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

14. Fusebox MX lifecycle 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

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

16. Plugins beta.fusebox.org • 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

17. Plugins beta.fusebox.org • 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)

18. Building a simple FBMX application beta.fusebox.org • Instructions for this are available under "Getting Started" at beta.fusebox.org

19. Final thoughts beta.fusebox.org • 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

20. 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!