How did Mach II come to be?

A discussion recently on cfaussie led to me offering to tell how Mach II evolved, based on what I know from my involvement in the project. In addition to posting it to the cfaussie list, someone suggested I post it to my blog for posterity.

This is the story as I remember it and I'm open to correction from Ben Edwards and Hal Helms.

The year is 2002. AD.

So wind back to the early days of Fusebox 4 being developed. The decision had been made to use XML for configuration but it was still aimed very squarely at procedural programmers - really aimed at CF5 users despite the XML issue. Hal was very interested in CFCs however and what they could offer a framework so he started working on a concept he called Fusebox MX. A concept he demo'd at DevCon 2002 in the Community Suite. A demo that got me very interested in this new framework.

Fusebox MX looked a lot like a cross between Fusebox 3 and Fusebox 4 but built with CFCs. index.cfm created a Fusebox CFC instance and asked it to 'do' a fuseaction (e.g., home.determinePlanet). Circuits mapped to CFCs - the fuseaction home.determinePlanet mapped to calling the method determinePlanet on the CFC identified by the home circuit. It also had the concept of skins - layout methods that you registered with the framework which would be called automatically in sequence before the view was displayed to the user. It had a property manager, a plugin manager (and several of the plugin points that carried over to Mach II) and a circuit manager (influenced by Fusebox).

Remember we're talking about 2002 and CFMX 6.0 with all the interesting problems that those early CFCs had.

Not surprisingly, Hal hit a wall with Fusebox MX, both in terms of performance (trying to create the whole CFC structure on every request) and in terms of usability (because of "this" scope and no local variables and a number of other issues).

Fusebox 4 continued on. Fusebox MX was effectively on hold. But Hal still wanted an OO framework using CFCs.

CFMX 6.1 made that possible in the summer of 2003. By that point he'd recruited Ben Edwards - who had done the JSP / J2EE port of Fusebox 3 - to help him develop an OO framework from the ground up. Retaining some of the key ideas behind Fusebox MX (XML configuration, CFCs accessed via aliases) but, through Ben, adopting a completely new core approach: Implicit Invocation.

Based on the same principles behind most desktop applications, implicit invocation takes an event-based approach to wiring an application together: you define handlers for events but you don't explicitly define a sequence of events.

The result: Mach II. All CFCs from the ground up, a single XML configuration file. User code extends framework code - which is a classic approach for most OO frameworks. The circuit manager was gone and in its place we have listeners and filters. The plugin manager has remained mostly intact. HTML output is now managed by the framework using regular view files and content variables (Fusebox MX used chained display methods in circuit CFCs, more reminiscent of Fusebox 3's nested layouts).

I actually have a copy of the presentation that Hal gave at DevCon 2002 in the Community Suite and the SolarSystem sample app he wrote back then. All heavily marked with "do not redistribute". It's an interesting historical artifact tho'...

I hope that gives folks some historical perspective on why Mach II is the way it is?