Well it is taking me a bit longer than I would like, but I am getting more excited about Fusebox and don't want to lose too much steam in my learning of the framework. In my first entry I talked about installing Fusebox (summary: easy as pie). In the second entry I talked about what happens during the Fusebox request cycle. (In other words, what happens when you load the application.) That entry focused mainly on the application life cycle.
The documentation continues on to talk about the configuration and the Fusebox request lifecycle. A request of a Fusebox application will have the following parts:
- preProcess and postProcess: Called at the beginning and end of the request. Seems a lot like onRequestStart and onRequestEnd from Application.cfc.
- preFuseaction and postFuseaction: Called before and after the fuseaction.
So this is nice and if I read it right, a bit more fleshed out then Model-Glue. Model-Glue lets you define pre/post actions per controller. Fusebox lets you do it per event (fuseaction) and for the request as a whole. I like that. I can see benefits in both approaches though. In Model-Glue, I can run code on start up and tear down that is very specific for the controller. In Fusebox I can tie the logic closer to the event, and have a global start/end stop type action. Either way - I'm impressed with this support.
Along with configuring the above settings, you can also define code to run on exception (processError) as well as specific exception handlers for fuseactions (fuseactionException). Again, this seems to be a bit more precse than Model-Glue. I'm not sure I'd use fuseactionException. Typically at that level I'd imagine having try/catch in the code. But it is nice that it is supported.
Moving on - configuration of your Fusebox app is done via an XML file. The docs don't mention it, but the XML file is actually Fusebox.xml.cfm, at least in the skeleton. I pinged Sean on this and he said the framework can support either fusebox.xml or fusebox.xml.cfm. Why use the CFM filename when it's really an XML file? One reason is security. Your fusebox.xml.cfm file (like your ModelGlue.xml file), describe everything about your application. You probably don't want the general public reading this. By using a CFM file, you can guarantee folks won't be viewing the file. The skeleton's Application.cfm file uses this code to prevent that:
<cfif right(cgi.script_name, len("index.cfm")) neq "index.cfm" and right(cgi.script_name, 3) neq "cfc"> <cflocation url="index.cfm" addtoken="no" /> </cfif>
Nifty. The XML file consists of five main sections:
- circuits: From my talks with Sean I know these are a collection of fuseactions, or events.
- classes: From what I read in the docs - this allows you to map an object (CFC, Java Object, web service) directly a circuit. So instead of me defining my events in the XML, I can just point to the CFC. Again - I may be reading that wrong. But it is kind of cool. I don't know if I like "losing" the XML definition and not being able to see exactly what events will exist.
- parameters: The basic configuration (modes, defaults, etc)
- lobalfuseactions: This is where you define the pre and postProcess actions described above.
- plugins: I'll just steal from the docs here: "Plugins are a way to extend the functionality of the Fusebox core files." Cool, but I'll worry about that once I can actually write a simple Fusebox application!
So that is a lot of ground. I still haven't covered circuits in detail (that is next in the docs), nor have I written a lick of code yet, but I'm growing in appreciation of this framework.
Archived Comments
Hi Ray, good luck with your 'steps'. I'm adding these to the articles section on http://cfFrameworks.com if tha's okay. FYI: Sean gave a interview on Fusebox over on the cfFrameworks blog: http://www.cfframeworks.com... - this might explain a few more things.
Fine by me, Nick.
Ray, I've been using Fusebox since 1.0. It's really refreshing to see the framework through a new set of eyes. I've been so accustomed to the framework features that I've forgotten how good the little things are. Thanks for the reminder!
One of the big complaints in the Fusebox survey - as well as from old-school (pre-FB4) Fuseboxers - is the amount of XML to achieve what seems to be just stuff you can do directly in CFML (when you get to circuits, I'm sure this will become more evident).
For Fusebox 6, we are looking at implementing a set of default conventions that will allow you to build (small-to-medium) applications without XML - adding XML in where necessary to obtain more control.
Even today, most of fusebox.xml is optional. The bare minimum fusebox.xml file would pretty much be:
<fusebox>
<circuits>
<circuit alias="home" path="home/"/>
</circuits>
<parameters>
<parameter name="defaultFuseaction" value="home.welcome"/>
</parameters>
</fusebox>
So that if you specify no fuseaction, it uses home.welcome and there is a single circuit (home) declared.
Then you would have home/circuit.xml defining just the fuseaction welcome and including a display fuse (.cfm file) for that.
<circuit access="public">
<fuseaction name="welcome">
<include template="dspWelcome"/>
</fuseaction>
</circuit>
ljsf