Checkout is handled by the original application by checking the value of a variable, step, that indicates the point in the multi-step checkout process the user is currently in. If we had designed this application originally, we would have used discrete events for each step. Then, if the flow of the checkout were to change later, the change would have been much less disruptive. But we chose to keep the original mechanism intact and so have a startCheckout method.

The event, startCheckout, uses the Mach-II XML configuration element, event-arg, to set a variable,step, in the current event's eventArgs structure. It then displays the checkout display page.

The event, continueCheckout, notifies the CheckoutListener, calling its continueCheckout method. The continueCheckout method has quite a bit of conditional code that, depending on the value of step, performs different functions.

The event, checkoutStep, is a private event, meaning that it cannot be called as part of a new HTTP request - as part of a URL's query string, for example. Events that should not be user-callable (loginValidated, for example) should be marked private.

The checkoutStep event notifies the CheckoutListener, calling its getStatesList. Notice the use of the resultArg attribute, which places the results returned by CheckoutListener's getStatesList method into the current event.

This same event causes CheckoutListener to be notified again, this time calling its getShippingMethods and placing the results of that method call into the current event. Finally, a display page, registered as checkout, is rendered.

When the user wishes to retrace their steps in the checkout process, the previousCheckout event is called. This announces the private event, checkoutStep.

When checkout is completed, the event, completeCheckout, notifies the CheckoutListener, calling its completeCheckout method. (Note that the cases shown where the event name and the listener's method name are the same is not a requirement; it simply made sense to use the same name.)

Within the CheckoutListener's completeCheckout method, another method, checkoutComplete is announced. Again, we use the Mach-II redirect XML element so that a "refresh" button press will not cause the completeCheckout to be called again.

The checkoutReceipt event sets the step variable within the current event to 7 and displays the multi-purpose checkout page.

Our final event, exceptionEvent, will be used whenever the Mach-II framework encounters an untrapped error. Mach-II creates a new event (with the cfcatch information inside of it) and automatically announces exceptionEvent. Application developers will usually want to change how exceptionEvents process exceptions, as the default event handler just displays exception information.

Finally, we arrive at our final section, page-views. In this section, individual display pages are registered. Views are registered so that a change to the path of a view page only needs to be updated once rather than each time the page is used. Page views are given a name (used in the event-handler's view-page element) and a page (the physical location of the file).

<page-views>
    <page-view name="index" page="/views/index.cfm" />
    <page-view name="preferences" page="/views/preferences.cfm" />
    <page-view name="about" page="/views/about.cfm" />
    <page-view name="legal" page="/views/legal.cfm" />
    <page-view name="affiliate" page="/views/affiliate.cfm" />
    <page-view name="category" page="/views/category.cfm" />
    <page-view name="searchResults" page="/views/searchResults.cfm" />
    <page-view name="cart" page="/views/cart.cfm" />
    <page-view name="checkout" page="/views/checkout.cfm" />
    <page-view name="exception" page="/views/exception.cfm" />
</page-views>

Conclusion Recently, one of us received an e-mail that stated, "I'd really like to use Mach-II, but it seems like it's meant strictly for OO gurus and that's not me, at least not yet." While we hope we've given you a sense of how to retrofit an existing application, we really hope we've given you a sense that Mach-II is not just for "OO gurus" or gurus of any kind, for that matter.

Mach-II was created to help working programmers with the problems of maintaining applications as they evolve to increasing complexity. As this issue shows, the growing sophistication of the ColdFusion community has made a number of frameworks available. That's a very encouraging sign and - all kidding aside - we salute Simon for bringing together all framework writers to "lay out their case" for each developer to judge for themselves.

And so, ladies and gentlemen of the only jury that matters, we present (in no particular order) our "Top 15 Benefits of Using Mach-II".

1. No more spaghetti code. This makes your applications much easier to write, debug, and maintain. Mach-II by design strongly encourages developers to do things "the right way."
2. Elimination of scope issues. Because all elements in a Mach-II application are geared to get their information from the event, there is no need to worry about whether a particular variable came from the form, URL, request, variables, etc., scope. This makes writing applications clear and simple since all the variables are always in the same place.
3. Team development. The use of any standardized framework helps teams of developers work together to build software. Mach-II, with its emphasis on separation of concerns among elements, a declarative programming framework, and the use of public APIs, goes the next step in empowering teams.
4. End to page-centric development. Mach-II's use of the design pattern known as "Front Controller" relieves developers of the fragility of page-to-page application flow. Announce the event and Mach-II handles the rest.
5. Code organization. Mach-II encourages excellent code organization but doesn't force developers to adopt any particular conventions or standards. A Mach-II application skeleton (available from www.mach-ii.com) shows clear model and view directories, but other organizational schemes can easily be used.
6. Low-impact maintenance. Mach-II is designed to use the tried-and-true MVC design pattern. MVC separates presentation from logic in the code, thereby making the application flexible and very easy to maintain since changes in one area are localized without breaking the rest of your application.
7. Encourages object-oriented programming. We think that a mastery of OOP is an absolute necessity for career survival. With the OO tools available in ColdFusion, Mach-II is a perfect way to begin mastering object-orientation in a language you're already familiar with.
8. Ease of installation. Mach-II is just a CF application. Just drop a single copy of the Mach-II code in a Mach-II directory under your Web root and you're ready to go.
9. Built on proven principles. Mach-II is based on solid software engineering principles (event-driven, implicit invocation) that have long proved effective in software development. Mach-II brings this power, flexibility, and simplicity to ColdFusion developers.
10. Code reuse. Mach-II's separation of concerns allows the same model components to be reused across many applications within an organization.
11. Portal development. Powerful view capabilities allow for simple development of templates or portal-style applications. Multiple views can be built up within a single event and presented to the user at the end of the event.
12. Framework extensibility. Plugins and filters are extremely powerful, flexible, easy-to-use application components that can handle application concerns such as logging, debugging, security, etc., at the event level without concerning listeners or, worse, business objects. If you need system-wide functionality, you can extend the framework without touching the core files.
13. Mature and stable. Mach-II is the most mature, stable OO framework for ColdFusion, and has been proven in both small and very large applications in organizations as diverse as the Federal Reserve Board, Dow Jones, and ColdFusion's parent, Macromedia.
14. Separation of concerns. Underpinning many of the benefits listed above, this fundamental software engineering principle is the foundation on which Mach-II is built. Page view elements are unaware of listener and model elements. Model components know nothing of either listeners or page views - or even of Mach-II. By adherence to the twin principles of loose coupling and tight cohesion, Mach-II applications are built to withstand the changes over time inherent in successful software deployments.
15. Integration with other frameworks. If you've looked at frameworks like ColdSpring and Tartan, you've probably been impressed with them. We are too. Mach-II's plugin architecture makes it a perfect partner with both current frameworks and others that may appear.