Casting my mind back to when I first started using ColdFusion, two things struck me that I'd forgotten. Firstly, just how quickly I went from zero server-side programming experience to having built a multi-featured database-driven web application which people were using to get real work done. A matter of about 6-8 weeks if I recall correctly.

The other was how unstructured my code was: each page called a single .cfm template which did everything needed for that request. I'd never heard of "frameworks" and they weren't mentioned in any of the CF books I was reading.

Separation of Concerns

Things stayed that way for about 4 years until Jeremy persuaded me to try Fusebox, then at version 2. I was resistant at first, but the thrill soon hit me of "everything being in its place". Different types of code (queries, general logic, display) were separated out into smaller re-usable templates which you assembled as needed for a particular page request using a single index.cfm "hub" template containing a switch statement.

Again I'm struck by how simple early Fusebox was. But as we know, simplicity is in the mind, and to the minds of many of the (much cleverer than me) developers using the framework, it needed more power and flexibility. These were duly delivered in versions 3 and 4, but at the cost of greater complexity. Instead of just a set of conventions, you now also needed to configure a "core" - a special package of pre-built code which allowed you to wire things together in more complex hierarchies, while doing a lot of the grunt work for you and providing a range of features for managing and customising various aspects of your app.

For the best part of a decade almost all our apps were built with Fusebox which by version 5.1 under Sean Corfield's stewardship had become a robust framework capable of supporting the OO, component-based style we'd gradually adopted.

Slimming down the "bloat"

I'm always on the lookout for simpler ways of doing things, though, and when Sean announced his new stripped-down, single file, convention driven MVC framework FW/1, I felt instinctively drawn.

The experience of converting an existing FB4 app left me in no doubt that FW/1 would henceforth be our framework of choice, which it has been now for the past year and a half.

Fusebox taught me a lot and served us well for several years, but among the benefits FW/1 has brought are:

• The simplicity of a single framework cfc, as opposed to a complex set of core files.
• Simpler set-up: instead of multiple locations where application and request initialisation takes place, it's all in Application.cfc, the natural place for it in CF.
• No more xml for controllers or config. (I know that was possible in FB5 but I never got round to it). Writing controllers in CFML again has been a joy.
• Simplicity through convention: not having to register controllers or specify view paths.
• Fast, in-memory, easily reloadable controller objects, instead of disk-read "parsed" files which need re-generating carefully whenever changes are applied to production.
• The simplicity of CFC inheritance in controllers rather than circuit based hierarchies which could get quite complicated.
• Easy bean factory integration.
• Faster and smoother app initialisation (our bloated FB apps always seem to grind and belch out inexplicable errors whenever the server is restarted - a problem which disappears on conversion to FW/1).

One, and only one thing did I miss from Fusebox, and that was the concept of content variables, an abstraction of cfsavecontent which allowed you to capture, in the controller, the output of view/display files into a variable which could be passed to services or other views (or indeed any "fuse" since FB didn't impose MVC). Fortunately the simplicity of FW/1 meant it was trivial to extend with my own custom saveView() method without needing to touch the original code.

As of this week, though, I'm pleased to say that the development branch of FW/1 (to be released in due course as 2.0) addresses that gap by allowing the framework View() method to be called from controllers (with certain restrictions).

John Whish has posted a nice example of how to make use of this when sending email, and I've posted on using it as an alternative way of managing page fragments.