Fusebox at the crossroads (again)

August 7, 2009 · 10 Comments

Fusebox is the oldest application framework for CFML and it's gone through a number of dramatic changes over the years. Initially it was more of a methodology than a framework and it was really only with Fusebox 3 that it solidified into a full set of core files and what we traditionally think of as a "framework" these days. Fusebox 4 was a complete rewrite and not backward compatible. Fusebox 4.1 added some interesting new features and then Fusebox 4.2 (previewed in 2005) never appeared. It was a bit of a dark period for Fusebox with no progress being made and some awkward politics behind the scenes. In 2006, I was asked to take over the project and I insisted that backward compatibility be maintained, despite another full rewrite. The result was Fusebox 5, but not without yet more political drama, mostly behind the scenes. In order to move forward, Fusebox shifted out of the control of The Fusebox Corporation and under TeraTech's benevolent guidance. I almost had to fork the project to make that happen. Initially, TeraTech were very proactive and they organized a large survey of developers to find out what they wanted from the framework as well as supervising a complete overhaul of the website. The result of the survey was Fusebox 5.5 - and the no-XML option. The website was a huge improvement but support dwindled before the documentation could be fully overhauled. I made a minor point release and began planning Fusebox 5.6. I wasn't using Fusebox in any of my projects, however, which made it difficult to push ahead solo, without input and guidance from the project owner, TeraTech. The community were happy with the framework and only a few enhancement requests were coming in. Adam Haskell expressed interest in becoming more involved so I handed over the role of lead developer to him and he settled in, making small enhancements and starting to plan for the future. Like me, he found little input or guidance from TeraTech and, because of their disinterest, also found it hard to get traction on any real change. Well, just as I almost forked Fusebox three years ago to get Fusebox 5 released and the framework moving forward, Adam is now on the brink of forking Fusebox to get things moving forward again. When this issue cropped up in 2006, lots of discussions led to the previous project owners agreeing to hand off the project to a new team. Adam has made the same request of TeraTech. I hope they take the same path and allow the framework to move on. Otherwise, what we know as Fusebox today will remain stagnant and the code will resurface under a new name and development will continue anyway, leaving TeraTech with an outdated legacy. That's one of the great things about open source: you can never close it down and you can never lock people into a single vendor. If you have any opinions on the future of Fusebox, feel free to comment here or on Adam's blog post - and feel free to talk to either of us at CFUnited next week.

View count: 977

Tags: coldfusion · fusebox · oss

10 responses so far ↓

1 brian // Aug 8, 2009 at 2:03 AM

I've found 5.5 noxml the quickest and most intuitive way to get MVC organisation into my projects. Curious why you don't favour it yourself.
2 Lola LB // Aug 8, 2009 at 3:36 AM

Very good questions.

Yesterday I was cleaning out my /Webserver/Documents directory, deleting projects and applications that I didn't need anymore. I have fusebox5, and I was safe deleting it, since I never had any projects using FB. And I was wondering where's the latest news been, any projects released on Riaforge using FB lately, etc. I also don't remember seeing any blog posts or tweets specifically about FB for at least the past 6 months, maybe a year, even.
3 Sean Corfield // Aug 8, 2009 at 12:30 PM

@Brian, it's not that I don't favor it, I've just had clients that have (generally) specified a different framework. Although one client initially went with Mach-II and then asked me to rebuild their code in Fusebox 5.5 no-XML. If a client has no preference, I'll choose a framework based on their needs and what the maintenance plan for the application is...

@Lola, true, it has gone very quiet in Fuseland and I think that's a symptom of the lack of support TeraTech has been providing. The Fusebox 5 mailing list remains fairly active although it too has quietened down over the last year or so - but I attribute that to everyone just getting on with their jobs and knowing enough about how FB works that they don't need to ask many questions (the sign of a stable, mature framework).
4 Dave Anderson // Aug 10, 2009 at 9:08 PM

I've worked with Fusebox since version 2, and nearly gave up on it after 4.1. Version 5.5-noxml changed that for me and renewed my interest. I began doing all my projects in 5.5. Now, though, after taking a look at FW/1 in all its elegant simplicity, I'm thinking that might be my new Framework of choice. I've got some testing to do first (and I still don't like having to write xml to wire up the services, but that's a piffle), but the convention-based approach is very appealing and will undoubtedly result in many fewer lines of redundant code (like having to create a controller function that simply parses a display template for each and every 'static' page in a project).
So I guess what I'm saying is, Fusebox can live or die, and in the end it doesn't really matter to me, and probably not to most, because most developers (I'm guessing) will choose a framework (if they choose one) that jives with what they need, how they think, and what they're able to understand easily.
5 Sean Corfield // Aug 11, 2009 at 1:22 AM

@Dave, not sure what you mean by "I still don't like having to write xml to wire up the services" - there's no XML in FW/1. Do you mean ColdSpring? Well, you can use LiteWire with FW/1 which doesn't require XML. Anyways, glad you're liking FW/1!
6 Dave Anderson // Aug 11, 2009 at 9:52 AM

When I said that about wiring up services with XML, I was thinking of the UserManager sample app -- assets/config/beans.xml.cfm. Is that not used to tell FW/1 about the User service's DepartmentService dependency? Am I way off base here? (I suppose I could simply create the DeptService right there in the User Service's init, though, eh?)
7 Sean Corfield // Aug 11, 2009 at 10:20 AM

@Dave, that's just Javi's object factory stuff. Nothing to do with FW/1, except as an example. FW/1 works with LiteWire (no XML), Javi's object factory (XML), ColdSpring (XML).

FW/1 is all convention, no XML at all.
8 Dave Anderson // Aug 11, 2009 at 10:25 AM

Sweet. Cheers, Sean. Again -- well done.
9 Ken Miner // Jan 26, 2011 at 1:26 PM

Hi Sean

CF9 has changed the onRequestEnd in the Application.cfc, as you may know. The trouble is Fusebox 5.5 outputs myFusebox.do( 'layouts.buildPage' ) in that section.

This makes it almost impossible to use dump or abort as it immediately gets overwritten by the output in the onRequestEnd.

Is there a workaround that you are aware of ?

Any help would be appreciated greatly.

Many thanks
10 Sean Corfield // Feb 1, 2011 at 5:29 PM

@Ken, I wasn't aware of any change in onRequestEnd() and I'm not really sure I understand your question. Perhaps you should ask it on the Fusebox 5 mailing list and provide more detail?

An Architect's View

CFML, Clojure, Software Design, Frameworks and more...