I’ve been a ColdFusion developer for over five years now. While ColdFusion is incredibly easy to learn and use, it has always been firmly grounded in the procedural programming world. True object-oriented development has not really been an option. Application frameworks like Fusebox 4 incorporate many of the great ideas of OO (like encapsulation and inheritance), but are still grounded in the procedural world. Fusebox 4 requires discipline on the part of the developer to fully leverage its OO-like advantages.

With the advent of ColdFusion MX, Macromedia introduced the ColdFusion Component (CFC). This is the first step toward true objects for ColdFusion. CFCs provide most of the functionality of objects. Methods, built-in support for inheritance, introspection, and the ability to create abstract CFCs and composite objects are just a few of the features that CFCs bring to the table.

Mach-II is the first “from the ground up” object-oriented application framework for ColdFusion. And since Mach-II is built on top of generic object-oriented design principles, the framework is being ported to Java, .NET, and PHP. But what is Mach-II? And while there are reasons that ColdFusion developers might find it interesting, why would a Java or .NET developer care about Mach-II given the other frameworks that already exist for these platforms?

Overview of Mach-II
Mach-II is the brainchild of Hal Helms and Ben Edwards, both accomplished programmers and advocates of the Fusebox framework. When CFC’s were announced, they realized that they could now create a fully OO framework for ColdFusion. Furthermore, they knew that if the framework followed general OO principles, it could be used on any platform that supports OO development.

The “II” part of Mach-II actually stands for “Implicit Invocation,” because Mach-II is an event-based, implicit-invocation architecture. As a novice OO developer, that sounded like Greek to me the first time I heard it. In case it sounds strange to you as well, I’ll explain it a bit further.

All but the most trivial software systems rely on multiple components to do their work. In many cases, components will directly call other components, a configuration that could be called explicit invocation. While this works, it isn’t the most flexible solution.

In an implicit invocation system, components do not call each other directly. Instead, they announce events. Other pieces of the system are registered (or can register themselves) to respond to specific events through event handlers. When an event is announced, the system invokes the components that are registered for that event. In other words, the system itself implicitly invokes other parts of the system in response to an event.

The result is an application that is very loosely coupled, meaning that there is very little interdependency between components. It also means that the system is very flexible, because parts of the application can dynamically register themselves to respond to events at runtime.

As an OO novice, all of this sounded a bit strange to me the first time I heard it. However, the more I experiment with the ideas, the more sense they make and the clearer the benefits become.

Mach-II is based upon the Model-View-Controller (MVC) pattern. In the case of ColdFusion, the controller is the Mach-II framework, which is configured through an XML file. The Mach-II framework is a set of CFCs that handle the creation of applications, event announcements, handler registrations, and all other aspects of the architecture. The model part of a Mach-II MVC application consists of CFCs that implement business logic and extend the Mach-II framework components. And the view is a series of standard ColdFusion templates that display data supplied by the model and provide the user interface.

A brief look at the Mach-II XML configuration file
In a manner similar to Struts and Fusebox 4, you define virtually all aspects of a Mach-II application in an XML file. The mach-ii.xml file consists of the following sections:

  • Properties–Used to set application-level properties such as the application root, the default event if one is not specified, and the event to announce in case of an error.
  • Listeners–Used to define listeners for the application. Each listener is mapped to a CFC that is built to respond to method calls. Event handlers can notify listeners to perform specific tasks.
  • Event Filters–Event filters are CFCs that are built to manipulate or filter data during an event. One example is copying an event argument into the request scope for later use in another event or view.
  • Event Handlers–This is where the real work is done. Event handlers are where individual events that have been announced to the system are processed. An event handler might notify a listener or announce another event to the system, among other things.
  • Page-Views–Views are defined here, which are ColdFusion templates that are constructed to output data supplied by the model (typically listeners and other CFCs). In a manner similar to Fusebox 4, the output of a view can be captured in a variable, which can then be output in another view. This allows for the easy creation of portals and other complex layouts.
  • Plugins–Plugins are ways to trigger specific procedures at different points in the execution of a Mach-II request. For example, you can define code that executes before or after any view is processed, or before or after any event is handled.

The Mach-II event cycle
As I’ve said, Mach-II uses events and request handlers to operate. Basically, a Mach-II application responds to a user request through an event. The system finds an event handler that is registered for that event. That event handler is invoked by the system, which can then notify listener components to manipulate application data. Then, other events can be announced, and the same process can be repeated, where event handlers are able to respond to those events in any way necessary. Finally, views are rendered and a final display is returned to the user. That, in an extremely basic outline, is how Mach-II does its thing.

Flexibility and maintenance
I hope this very brief introduction to the Mach-II framework has piqued your interest. The benefits of implicit invocation systems include greater flexibility and easier maintenance. As Web applications become more complex, it becomes increasingly difficult for developers to adapt their code in the face of constant change.

The Mach-II framework is definitely not for everyone. It’s a brand new framework, and it requires a firm grasp of object-oriented design principles, which means it will probably be more complex for those used to building more procedural applications. Also, in my early tests it seems to perform more slowly than similar procedural code, but this also may be attributed to the overhead that comes with the framework itself, as well as my novice skill level regarding the framework.

In any event, object-oriented development continues to grow by leaps and bounds, and as a ColdFusion developer I think it’s important to examine the new OO capabilities of CFMX. Mach-II appears to be a very flexible and adaptable architecture. Take a look at Mach-II yourself and see what you think. The framework code, documentation, and sample apps are available at the Mach-II site.

Additional Resources

More resources are available at Brian’s site and at Corefield.org.