ver heard this story? Developer meets company, company meets developer, they fall in love. Together, they develop a ColdFusion application of great beauty, bound to last forever. But soon developer and company begin to drift apart, feel the need for “more space.” Eventually, they part ways.

A touching story, but the problem is that it doesn’t end there: A new developer enters the picture, but can’t figure out how to modify the application of great beauty. Developer spends lots of time digging through code files, but every time developer tinkers with something, something else breaks. Company falls in love with consultants, out of love with developer, and spends lots of resources doing the same work again.

What Went Wrong?
While we can’t ensure that companies and their software developers will live in harmony forever and ever, we can ensure that the work developers do gets passed from one development team to another team responsibly. An important step in this is application architecture?sets of rules and regulations about how code components within an application interoperate. A clear architecture eases application maintenance.

Application maintenance has long been a problem for the ColdFusion community, as many ColdFusion applications lack clearly defined rules for how code components interoperate. Until recently, ColdFusion lacked object-oriented features, which means strategies to address this lack of rules have been slower in coming to ColdFusion than to other scripting languages. Mach-II is a tool?and a philosophy?to address these issues.

Model-View-Controller Frameworks
The term Model-View-Controller (MVC) has become a mantra of application development in the past few years. Using the MVC design pattern essentially means decoupling the application (or business) logic (the Model) from the user interface (the View) and having the interaction of these two carefully coordinated by a third set of code (the Controller). Mach-II brings the advantages of MVC to ColdFusion for the first time.

The most common problem MVC solves is the tight coupling between application logic and user interfaces. That is, MVC addresses the tendency to introduce data processing code in CF scripts themselves and to hard-code relationships between particular ColdFusion scripts and ColdFusion Components in idiosyncratic?and difficult to understand?ways. Nothing will make a Web application tougher to modify in the future than tight coupling.

The best part of using MVC is that MVC solutions generally come wrapped-up and pre-packaged for us as a set of code?or framework?to which we add the code for our application.

Intro to Mach-II
Mach-II is an object-oriented redesign of the Fusebox 4/MX framework the preceded it. The Fusebox framework is a giant parsing machine that intelligently compiles smaller application scripts (and functionality) into larger scripts (and business logic). Mach-II introduces ColdFusion Components (CFCs) into the Fusebox equation: Mach-II’s object model is built from CFCs, and Mach-II asks application builders to encapsulate their logic in CFCs as well. The results are wonderful: No more spaghetti ColdFusion applications with long scripts everywhere and tightly coupled application and interface code.

How does Mach-II work? Let’s walk through the development of a sample application, a Web-based application to randomly generate band names. To start with, we’ll need to download the Mach-II framework and place it in the ColdFusion wwwroot (see the Resources section, left column). Next, create a directory structure as follows:

/wwwroot/MachII/    <-- MachII framework installation        /bandnamegenerator/config/                          /model/                          /plugin/                          /view/                          /index.cfm

The index.cfm file should contain these lines, which basically just point to the Mach-II framework and set a few global values:

(The downloadable Mach-II sample application framework contains all this for you, but you can use the code distributed with this article as well. See left column.)

Just to get it out of the way, let's write the actual business logic of the application here, which consists of a single CFC, BandNameGenerator, with a single method, generateName(), that returns a CF List of band names based on the type of music the band plays. The first and last lines of the method are as follows:

I left out a few lines from the middle, but the idea behind this application should be clear: Based on the music type, return a list of randomly generated band names.

So much for an application with a back end. The front end consists of two pages (or "views"), one page consisting of an HTML form where the user selects the music type, and one page where the user gets the results. That's all there is to it.

Here's the HTML from the selection page:

What type of music does your band play? 
            Folk music        Pop        Heavy metal        

And here's the HTML from the results page, which iterates through an array of band names stored in the request scope at request.names:

Suggested band names are: 
	
 #request.names[i]#  

Two pages, one method call, all straightforward ColdFusion code.

Enter Mach-II
Now for the Mach-II part. No matter how small your Mach-II application, you will need to use at least four elements of the Mach-II architecture: "events," "event-handlers," "listeners," and "page-views."

A Mach-II "event" is something that happens in the application, and by default that event is announced in the URL using a parameter named event, as in:

index.cfm?event=doSomething

For our application, the big event is selectMusicType, which you can see in the code from the HTML

    
Band Name Generator
#request.content#