Fusebox: Developing ColdFusion Applications

[Note: This article was written and posted July 19th, 2002 - I am leaving it up as an historical record of my thoughts at the time but it should be read in the context of my more recent articles about Fusebox]

I promised a more expansive write-up of Jeff & Nat's book "Fusebox: Developing ColdFusion Applications" and here it is. My overall impression is that Fusebox is going to be a really good start for people who have little or no previous software engineering background: it emphasizes a lot of concepts that are (or should be) second nature to most software engineers but it introduces them in an approachable manner. Separating presentation from business logic is one such concept, documenting components properly(!) is another such concept. The overall discipline of structuring an application according to the Fusebox guidelines is (mostly) just plain good ol' software engineering. Exit Fusion Actions (XFAs) are another good example of a common software engineering technique (parameterization of code, abstraction) presented in an approachable manner. Fusebox version 3.x should do a pretty good job of helping a lot of folks get 'a leg up' on their journey to becoming better programmers.

Of course, I can't be entirely full of praise for a framework that does some things I just plain don't like (and have already been publicly vocal about). Fuseboxers talk about reuse but they really mean repurpose and the authors have the honesty to admit that most 'reuse' is actually cut'n'paste. Even so, at least Fusebox encourages people to think about code reuse so I won't beat it up too much for that. My main complaint about Fusebox is that forces OO onto a non-OO language by introducing a pretty big piece of machinery and then requiring somewhat stylized coding to take advantage of that OO framework. This is a complaint I levelled against X-Windows back in the day (a complex piece of Unix C code that emulated the as-yet-unborn C++ by providing inheritance, methods and so on) because it ended up exposing too much of it's (artificial) framework. Unfortunately for Fusebox, this is compounded by accidental bad timing - Jeff & Nat's book arrived on the scene at pretty much the exact same time that ColdFusion has sprouted some genuine OO features. I'll be very interested to see what Fusebox 4.x looks like. For example, in Fusebox, everything goes through /index.cfm with fuseaction=xxx.yyy and index.cfm contains a switch to route the atomic action (yyy) to the appropriate circuit (xxx). Circuits are identified through a mapping from names to directories. Yet ColdFusion MX would make this so much simpler by using ColdFusion Components and replacing /index.cfm?fuseaction=xxx.yyy with /xxx.cfc?method=yyy which would also allow proper hierarchical nested circuits. Even if index.cfm remained but simply did a <cfinvoke component="xxx" method="yyy"> it would be simpler (and, I believe, more flexible). Or perhaps I'm just missing the point?

Perhaps the most disconcerting aspect of Fusebox for me is the way it portrays 'inheritance'. What Fusebox claims as 'inheritance' bears very little resemblance to the way that inheritance behaves in Java and C++ (or indeed in ColdFusion MX). Fusebox has 'inheritance' by construction - it has machinery that walks up and down directory trees looking for named files to execute. With 'real' inheritance, data is aggregated but code is overridden unless the programmer explicitly invokes the underlying methods - Fusebox implicitly calls the underlying methods for you. In fact, Fusebox has a lot of implicit machinery that I actually finds distracts me from the underlying design of the code. That the book spends two chapters walking you through the framework code so you can understand how Fusebox behaves is very telling, in my opinion.

Now let's look at FLiP - Fusebox Lifecycle Process: again, here is something that will provide structure for people with no process. That's a good thing. But it suggests building a complete prototype of a site in HTML before you start 'engineering' (writing CF code). Do Fuseboxers really do this? How on Earth do they ever get a large site built? I can't even imagine where we'd be rewriting macromedia.com if we waited to get complete design signoff before beginning our engineering designs and development! One thing I didn't get from the book was what sort of upper limit of complexity is Fusebox capable of handling? There was plenty of talk about scalability in the code but FLiP wouldn't seem to scale with it. Another concern I have with FLiP is that it pretty much glosses over the software design phase: it talks about building the prototype, identifying XFAs and writing Fusedocs... then writing code. Where is the data modeling done? Where is the business logic handling designed? Once again, I think this is a scalability issue for FLiP.

Overall, I'll stick by my statement that this is a well-written, interesting book that many web developers should read. I don't see it benefitting people with a software engineering background, especially those with an OO background (except in a general, broadening-the-mind kind of way) but I can see it helping people who don't have that background - it will provide structure and framework for them. Fusebox is clearly evolving and improving with each 'version' so I'll look forward to Fusebox 4.x and hope that it can really leverage the power of ColdFusion MX.

Although then I look at PHP Fusebox and J2EE Fusebox, both of which are also covered briefly in this book under "Fusebox Exotica" (which an earlier chapter promises will also talk about Web Services but I could find no mention of them). I can see more synergy between PHP and ColdFusion than with J2EE so I can perhaps see why you might want to use Fusebox when developing with PHP - as I said, I might even try it myself - but I cannot quite see why a J2EE developer would want to use Fusebox. To be fair, it's really only targeting JSP development - the weak link in J2EE, in my opinion - but with the general J2EE wisdom leaning toward heavier usage of tag libraries rather than scriptlets and the impending JST standard, J2EE Fusebox seems a strange and confused beast. Given ColdFusion MX's greatly improved Java integration and the fact that it is "J2EE Inside", I can more likely see ColdFusion Fusebox used as a front-end for a J2EE application rather than forcing Fusebox's framework onto JSP.