Introduction to Fusebox 5, by Adam Lehman
So readers of this blog know that I've never been a huge fan of Fusebox. But I've decided that this is the year that I'll give it a shot. I'm going to be attending a few Fusebox classes here at the conference and I'm going to go through the process of developing a simple Fusebox application sometime later this month. So with that in mind I'm attending the Intro to Fusebox class being taught by Adam Lehman. Please pardon the scattered nature of this report as I'll be taking notes during the presentation.
Fusebox is CF's oldest (released in 97) and most popular framework. Originally designed by Steve Nelson and Gabe Roffman (both here at the conference). Maintained by TeraTech. Uses a MVC (Model-View-Controller) design pattern. XML based configuration since version 4. Latest release is version 5 (June 2006). And it is open source and free.
Lots of benefits I won't repeat here as I think they apply to most frameworks.
Application Structure based on a circuit. Login could be a circuit. Circuits has Fuseactions. Fuseactions have fuses. Kinda confused now so I hope he describes this a bit more.
FuseDocs: Documentation/structure comment system. Its XML used in the file that describe what the file does. (This sounds sexy.)
FLiP: Fusebox Lifecycle Process. Its a methodology. From requirements out to deployment. Not required for Fusebox, and you can use it w/o using Fusebox.
Whats new in FuseBox 5: Mostly CFC based. Backwards compatible with earlier version. Multiple application can work under one Fusebox app. And other stuff I don't get since maybe I don't know Fusebox.
Now he is showing the Fusebox.xml file (I think that is the name). Fusebox has a set of configuration files. (Like Model-Glue.) This is the core XML file for the application. The top portion of the file is a circuits block. This to me feels like the Controllers portion of Model-Glue.
There is a classes box for CFC declarations. Not sure how that compares to circuits.
Parameters is your configuration stuff. That makes sense - Model-Glue has this as well.
Lovely - one of the staff members is actually talking on his cell phone. He left after 5 minutes on the phone. Gee, thanks.
Apparently Fusebox generates code. (Model-Glue can do this with Reactor/Scaffolds.)
Next section is globalfuseactions. Looks like high level events (application init, pre and post process). Model-Glue has this as well, but on first glance I think I like how Fusebox does this better. In Model-Glue it is defined in the onRequestStart/Stop methods for various controllers, which is good, but I like how in Fusebox it feels a bit more evident.
He is talking a bit now about XFA (didn't quite get it) and layout. Seems like Fusebox is using request.content in his layout template instead of a viewState like Model-Glue. Not sure I like that - but it is a bit simpler.
He is showing the Entry circuit. Fusebox has standard filenames. act_, qry_, dsp_. Fuseaction in URL defines the circuit and action to run. XML defines what to do with that. You can define some fuseactions as private. I like that. You can't define events in Model-Glue as private. Showing how his action needs to get recent blog entries and this runs a CFM. This is odd. I'm not seeing yet how files communicate with each other. It seems like it could be request variables. Ok so I just asked Adam. There -is- a way to make it abstract, but the simpler method is to have this view file directly access the name of the query generated in the query file. That really bugs me - but I'm keeping an open mind.
He is now talking about add/edit forms. It kinds of ties in to what I brought up before, but the XML can pass to the fuseaction attributes. Interesting - the XML language allows for conditions.
Showing an example of a lexicon. Seems like a custom tag defined for the XML. This seems kinda cool. You can extend the XML grammar to add new behavior.
Showing how to initialize applcation files. There is an init file (missed the name) that is run on every request. This is a lot like Application.cfm. There is also an appinit.cfm file only run once.
Now talking about plugins. Lexicons extend the grammar - but plugins extend the functionality. Plugins are event based. (You add a plugin to an event, like processError).
Summary: I'm interested. I'm now looking forward to building my sample application later in the month. I definitely see things I don't think I like, but I definitely also see things I really do think is cool.
Archived Comments
Ray - are you going to attend Steve's Fusebox presentation? He's supposed to have a 'new' version of Fusebox that only uses CFC's - no XML.
Jim (who's sitting in a cold office watching it snow)
I wasn't. I _am_ attending his "CFCs are the framework" presentation. (I'm sitting in it right now.)
Ray,
<shamelessplug>
You can look at CFDefect which uses Fusebox 5.1 as a learning tool.
</shamelessplug>
Thanks
Ray,
I would like to hear more of what you don't like about fusebox, and the reasons behind them.
The reason being, that I think my CF skills evolved parallel to the Fusebox methodology, and I have been incorporating it, one way or another into the CF code I have written for the past 9+ years.
I have, however had quite a struggle introducing the current XML-based flavors of Fusebox in my current job. I think, that my colleagues may have some of the same apprehensions about it as you do. But if I knew your stance, and the pros and cons and your reasoning behind them, I may be able to plead my case better.
One thing for sure is that they tend to like having everything in one CFM, rather than having one CFM page per query (query fuses). And in other situations, I may have a separate act file which has the business logic, or looping through the query set to generate variables, then subsequently a separate display page that just outputs the display variables. The tend to think that this is more overhead, and that now you have 3 or 4 pages to worry about or hunt down, when troubleshooting, rather than one CFM page (which could be upwards of 1100 lines long).
Thanks for your notes.
Since I rarely ever get to go to conferences, I appreciate respected people such as yourself jotting down your experiences at some of the sessions.
Thanks,
Ali
Sorry for the doublepost.
The biggest hurdle I have implementing Fusebox 4 and higher at my current job, is the XML syntax.
The argument against it is that, the XML syntax is something else to learn. So for people on the team who aren't advanced developers, it may be difficult for them to understand how the application works. Or if we get new hires with a lower level of CF experience, it will be one more hurdle for them.
Or for the non-CF developers, it may be difficult for them to understand which part they need to work on.
I disagree with all of the above, but it would be nice to know what other people who are not pre-disposed to Fusebox think.
Thanks,
Ali
Ray - I'm glad to see your keeping an open mind on Fusebox. I enjoyed your presentation on Model-Glue this afternoon. I've been using Fusebox since the 2.0 version. I can't tell you how many times I read and re-read Steve and Craig's book Fusebox: Methodology and Techniques. Once v3.0 was out, I had the concepts down and was beginning to understand. We had a major site in Fusebox 3.0 for several years. We just updated to 4.1 which was another leap of faith for several developers. The hardest part was switching from a CFM based controller/switch file to an XML based one.
Once you start to understand the concepts of Fusebox it begins to make a lot of sense. However, after your presentation, I'm being swayed to try a few things in Model-Glue.
Ray, Given your background w/ Model-Glue you probably would have gotten more out of the ColdSpring Powered Fusebox presentation Adam did later in the day. He demonstrated how to use a custom lexicon to load a value object (a.k.a. bean) from a service (which calls a DAO to load the bean w/ data). The bean is then passed to the view for display.
Like Model-Glue, the view knows it is going to get a bean to work on. In the example Adam gave it essentially used the attributes or request (can't remember which one) struct to stuff values into variables and the view got what it needed out of the stucts instead of the bean.
I'll be very interested to read your experiences learning Fusebox. For one thing, it will give Team Fusebox some great feedback about how we can make the learning process easier. And, of course, I have a vested interest in people learning - and liking - Fusebox 5.x.
Fusebox 5.1 will be released this Saturday (I have it on a memory stick at the conference if you want a copy one day early ;)
Ali, One of the main advantages I found moving from v3 to 4/5 using the XML syntax to replace the fbx_switch file is that the things you can do are strictly limited. Sounds a strange reason maybe, but let me expand. In the fbx_switch it was possible for -any- cf code to be added and so for less experienced developers it was temping to start straying from the fusebox concepts and coding business logic in a file which should be concerned solely with the flow of control. Using the XML you can -only- use the valid XML statements and while we do have if and loops these can still only relate to controlling which files are included in the next request. The way I try and code now is that you should be able to -only- look in the xml files to understand the flow of a system, and then once you can see what goes where you know which .cfm file to open to make changes or fix bugs. The xml should be a nice simple map to the system. I would take one of your 1000 plus .cfm files and split it down to some nice small fuse files in fusebox 5 and then let an independant developer try and amend both and see which is easier.
A few notes for Ali:
Dislike of Fusebox: I may have overstated it. I don't dislike FB. I did kinda dislike it years and years ago, but to be clear, I haven't looked at it in a long time (well, except for yesterday). Anyway - point is - I'm trying to be open minded now. :)
You mentioned that it is difficult to get the newbie CF folks understanding the XML configuration. It seems to be that frameworks like FB, MG, etc, allow you to more easily divvy up tasks between experienced and not-so-experienced CF folks. So I wouldn't even let my newbie CF guy worry about that. I'd handle the high leel XML setup and let the newbie implement what it makes sense for him to implement. So for example, views are typically petty simple and a great place to assign a fresh developer.
Multiple files: Well, one file may be convenient, but w/o proper abstraction you are going to end up duplicating a lot of code. I'd rather have 2 files (as a simple example) setup in such a way so that when I need a new page, I can reuse one file (the query fuse for example), instead of just cutting and pasting.
Thanks to Michael and Ray.
Your comments will really help me make my case.
I agree completely with your comments, Ray, in that I would rather reuse one query fuse, rather than cut and paste it or versions of it all over the place.
And to Michael, I too think it makes sense to have a display page, be just a display page. That way if we get a graphics designer or a strictly-HTML person, they can work on the display and understand how it looks without having step over or around CF code.
I have started a project at work that looks like Fusebox 2. To get people used to that layout, and the fuses and stuff.
I think what would be good to do is convert it to Fusebox 5-5.1, and then have them compare the two and see if they agree that the XML syntax and stuff are a better way to do things.
Thanks again,
Ali
Ray said: "Lovely - one of the staff members is actually talking on his cell phone. He left after 5 minutes on the phone. Gee, thanks."
This sort of behavior is unnacceptable. Have people no tact?
Daniel - I see this at every conference at least once. People just suck. :)
that phone call was the least of the disturbances. what really got to me was the fact that during most of the sessions there were a steady stream of people entering for about 15 minutes into the session with constant sounds of the door opening/shutting... making it extremely difficult to give the speaker full attention.
Just so folks know, one of the things under discussion for Fusebox 6 is a way to adopt a set of conventions that will let you create a Fusebox application with no XML at all. If you want more control or you want to move away from those conventions, you'll need some XML of course, but the idea is to make Fusebox easier and easier to use. Keep an eye on my blog for more information...
Sean, are you seeing a lot of your users (FB users) saying they want to avoid XML because it is too difficult? I know Steve brought that up as well. I find that so odd to me since the XML config nature of MG seems so natural to me now. I find it a nice, higher level description of the application, and not complex at all.
Ray, yes, there has been a steady stream of complaints since Fusebox 4 introduced XML in the Summer of 2003. Because Fusebox has a very broad audience - encompassing a large number of procedural programmers and outright newbies - there are always calls to simplify things, to make it easier to learn.
By introducing a number of simple conventions that allow the XML files to be effectively ignored at first, it would definitely lower the bar to entry.
Indeed Fusebox 4 XML syntax is not that easy to get in the first place. But with the ability to inherit from parents, the ability to restructure the files easily and the ability to put the plugins, this is really a superb glue for building apps.
I used struts, JSF, ASP, ASP.NET and Fusebox 4.1 (the PHP version) and it is with the fusebox version that I have the most pleasure to work. All the others do feel so unsexy.
Tried my hand at model glue and now back FBX.