©2003 the fusebox corporation fusebox mx hal helms
Post on 31-Dec-2015
239 Views
Preview:
TRANSCRIPT
©2003 The Fusebox Corporation
Fusebox MX
Hal Helms
©2003 The Fusebox Corporation
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
©2003 The Fusebox Corporation
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
©2003 The Fusebox Corporation
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
©2003 The Fusebox Corporation
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
©2003 The Fusebox Corporation
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
©2003 The Fusebox Corporation
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
©2003 The Fusebox Corporation
Circuits
<circuits><circuit name="user" type="myApp.model.user" /><circuit name="yourCircuit"
type="myApp.model.otherCircuits.yourCircuit" />
</circuits>
beta.fusebox.org
©2003 The Fusebox Corporation
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
©2003 The Fusebox Corporation
Fuseactions
<fuseactions><fuseaction name="authorizeLogin" event="loginEvent" /><invoke circuit="user" method="getUserInfo" resultKey="request.userInfo" />
</fuseaction></fuseactions>
beta.fusebox.org
©2003 The Fusebox Corporation
Plugins
<plugins><plugin name="securer" type="myApp.plugins.Securer"> <parameters>
<parameter name="type" value="bit" />
</parameters></plugin>
</plugins>
beta.fusebox.org
©2003 The Fusebox Corporation
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
©2003 The Fusebox Corporation
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.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
©2003 The Fusebox Corporation
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 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
©2003 The Fusebox Corporation
The Fusebox class diagram
Larger images and XML files/UML diagrammer link available at beta.fusebox.org
beta.fusebox.org
©2003 The Fusebox Corporation
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
©2003 The Fusebox Corporation
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
©2003 The Fusebox Corporation
Building a simple FBMX application
Instructions for this are available under "Getting Started" at beta.fusebox.org
beta.fusebox.org
©2003 The Fusebox Corporation
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
©2003 The Fusebox Corporation
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!
top related