December 3, 2007
You can now download the
Fusebox 5.5 core files, extensions and skeleton applications from the Fusebox website.
The scaffolder functionality within the extensions package is currently in beta and we will be releasing updates to the extensions package throughout the coming months but the other aspects of the extensions package are final for this release, as are the core files and skeleton applications.
The skeleton has changed substantially since the Fusebox 5.1 release. The skeleton directory now contains two minimal applications: one is a reworking of the traditional Fusebox 5.x skeleton that uses XML configuration files, the other is an equivalent application that uses no XML. The circuit names are the same in both versions but in the no-XML version, the controller circuit is a CFC.
Comments
That's great news, going to take a look at it ...
Are you going to provide an sample OO application for Fusebox 5.5?
Marco
Posted By Marco Di Folco / Posted At
12/4/07 12:49 PM
@Marco, beyond the new skeleton apps, probably not. All the existing FB4/FB5 apps should run unchanged tho'. I will be writing up quite a few blog posts on the new no-XML approach.
Posted By Sean Corfield / Posted At
12/4/07 1:32 PM
Going forward, is the recommendation to use the none XML approach, or the XML approach.
I know that lots of effort was put into the none xml approach, to make things simplier, etc. I personally don't mind the XML approach, but am just wondering which way the community is headed.
Posted By Andrew Kamphuis / Posted At
12/4/07 2:19 PM
@Andrew, my recommendation is to use whichever approach you're most comfortable with. Some people are loving the no-XML approach, some people are sticking with XML.
The roadmap includes adding support for Fusebox 3 applications so that we can unify the community and provide more options for all Fuseboxers.
Posted By Sean Corfield / Posted At
12/4/07 3:23 PM
I see various references in your blog that you were working on the error templates, was there much done to somehow done to standardize the flow to better fit into the MVC model?
Basically what I was hoping is that I could define a global fuseaction to call upon trapping an unhandled exception, something like "controller.exception" which would in turn call the associated modal & view actions.
(I know, I'm probably bastardizing the fb terminology! ;)
Posted By Steve / Posted At
12/4/07 9:02 PM
@Steve, that's not possible in general because some errors may cause Fusebox to be unable to process additional fuseactions in that request.
However, what you can do is have Application.cfc extend fusebox5.Application and define onError() and then call myFusebox.do( action="controller.exception" ) and *if* Fusebox is able to process fuseactions, it will execute that fuseaction. You can put a try/catch round it to deal with the case that the error being handled is too severe to recover from.
Posted By Sean Corfield / Posted At
12/4/07 9:13 PM
Hmmm, ok, how about this approach. (Please direct me to a better place for these ideas if there is one)
Add an optional unhandledExceptionSafe="yes/no" parameter that defaults to "no" to fuses and plug-in's. When an unhandled exception is trapped, a copy of cfcatch is copied to the myFusebox scope, flow falls through normally except that only actions and plug-in's with unhandledExceptionSafe="yes" are executed.
To be safe, this would also need a global setting to turn this on or off in the fusebox.xml file: useUnhandledExceptionSafeProcessing="yes/no" - defaulted to "no".
Posted By Steve / Posted At
12/5/07 11:57 AM
@Steve, I think you're missing the point: whether or not Fusebox can process an exception depends on when that exception occurs in the request lifecycle. That's not anything a developer has any control over. In fact, by the time a fuseaction is actually executing, Fusebox is always in a state where it can execute other fuseactions in the error handler (so I think for most of the situations you are imagining, you will be able to do exactly what you want). I'm just pointing out that you cannot process *all* exceptions by using fuseactions because if an exception occurs early in the request lifecycle, Fusebox may not be able to process a fuseaction for that request. Do you understand what I'm saying?
Posted By Sean Corfield / Posted At
12/5/07 1:11 PM
You are correct, I understand that not all exception can be caught in this manner. What I'm trying to catch are exceptions that my fuses trigger, not exceptions that may be generated in the fusebox core like improperly formatted XML files or a missing parsed directory or permissions, etc. (I think this is an example of what you're referring to).
I think I might be able to accomplish what I described using a couple plug-in's -- I'm analyzing the parsed output. So you can put on hold the idea of adding it to the core code for now...
Posted By Steve / Posted At
12/5/07 1:46 PM
@Steve, you do know that Fusebox has plugin points for both fuseactionException and processError? There's no need for any core file changes here - but I think you need to get more familiar with Fusebox's plugin points.
Posted By Sean Corfield / Posted At
12/5/07 6:22 PM
Thanks. I am able to get it very close to what I need using the preFuseaction and fuseactionException plugin's combined with some mods to my view fuses. While I think some of what I'm doing here would be cleaner if it was included in the core, I can't argue with you that I need to get more familiar fb plugin points (and this task is doing just this!).
Posted By Steve / Posted At
12/5/07 8:38 PM
Post Your Comments
Hosting provided by
