Page 1 of 3   next page »

It's all Simon's fault.

We say this to all framework writers who, even now, are trying to recover from the task assigned them by CFDJ's editor-in-chief: provide an article and an implementation of the Macromedia Pet Market application in their chosen framework.

Realizing that our first sentence might not serve as sufficient explanation for those weary framework authors, allow us to provide further clarification...

It began with an innocent-seeming dinner for speakers at the recent "Fusebox and Frameworks" conference. When we found ourselves seated next to Simon Horwith, we had a great deal to talk about. During our conversation, Simon suggested that it would be very helpful to ColdFusion programmers if a reference application existed that was implemented in several different frameworks. "We could have a cfpetmarket.com," he said, "and have different framework authors write a reference application and provide an article to go along with it. For the next issue of CFDJ."

This was the point where we went wrong - badly wrong - and the reason for which an apology is due: we agreed with Simon. Given the short time frame, our indiscretion meant that we were guaranteeing that our fellow framework authors (and ourselves) were in for some late nights. For our hasty improvidence, we offer a corporate mea culpa.

Coming Up with a Plan
The three of us put our heads together. It seemed the first thing to do was to review the existing application. This presented us with a problem: frankly, we didn't like what we saw. Installation of this simple application was anything but simple. The application almost seemed to be illustrating "worst practices" including such miscues as:

• Having CFCs reference variables set in the request scope, thereby breaking encapsulation
• Poor organization of files (e.g., including detailview.cfm in a subdirectory of extensions/components/petmarket)
• Poor separation of concerns in CFCs (e.g., including login and placeOrder methods within the User.cfc.)
• Rampant use of the this scope in CFCs, disregarding information hiding
• Queries used in display pages (e.g., shoppingcart.cfm)
• Jumble of mixed scopes used in display pages
• Even the database schema was - unusual

Our decisions also led us not to integrate any of the helper frameworks such as ColdSpring or Tartan, something we surely would have done had we written the code from the ground up. In short, the code in the Mach-II version of the Pet Market should not be viewed as exemplary, but rather as the result of retrofitting an existing application - warts and all - to make use of Mach-II.

Mach-II Components
Specifically, we wanted to show how nicely Mach-II can fit into applications in its role in the Model-View-Controller (MVC) architecture. MVC is a well-accepted architectural design pattern in which the components of an application are separated by functionality.

Model components represent the business logic of the application as well as a software simulation of the inventory of the business domain (and are often called domain model components). Model components might include representations of orders, customers, products, etc.

View components form the user interface, allowing users to receive information from the application and make requests of the application. HTML pages, Flash movies, and Java applets are all examples of view components.

Mediating between model and view are controller components, receiving requests and calling on model and/or view components as needed to fulfill a request. For example, a user request to edit application preferences would entail a call to the model to determine the existing preferences and a call to the view to display a form for changing these preferences.

Many applications use some form of controller, even if nothing more than a switch statement. Frameworks such as Mach-II, Fusebox, and Model-Glue provide a more extensive controller and often include prebuilt functionality as well as "hooks" for developers who want to extend the capabilities of the framework.

Within the Mach-II world, various controller functions are assigned to different Mach-II elements. The central element in a Mach-II application is an event. An event is an all-purpose mechanism for encapsulating a request and the results (if any) of fulfilling that request. In our "edit preferences" example, Mach-II creates an event object (an instance of Mach-II's Event class) that comes with prebuilt functionality.

Among other things, events can store information related to a request. In the "edit preferences" example, Mach-II stores the results of asking the model for the user's current preferences (possibly a query) in the event. (Event objects have arguments that can be accessed with prebuilt get/setArg methods.)

When the view page - in this case a user preference form - is called, it gets any information it needs from the event (shown in the illustration as a cube). In a Mach-II application, as in any well-designed MVC application, the model and the view components exist completely separate and independent of each other. Such loose coupling, as it is called, aids in both code reuse and maintainability.

The rest of Mach-II's machinery exists to support the Event. A Listener element is a CFC that extends Mach-II's Listener class and "listens" for events, taking appropriate action for the individual event. Using our example of a user editing their preferences again, we might have a UserListener that is notified of an "editPreferences" event. It is the UserListener that actually calls the model for the user's existing preferences.

Listeners do not, though, call view pages. Doing so would decrease the listener's ability to be reused and make application maintenance more difficult. Instead, Mach-II uses a declarative programming mechanism in which the instructions for responding to a particular event are written not in code (programatically) but in some sort of simple configuration file (declaratively).

For this configuration file, Mach-II uses the file, mach-ii.xml. Different sections of the configuration file allow the developer to customize how Mach-II works for any particular application. (Rather than forcing the developer to adapt to Mach-II, Mach-II adapts to the developer.)

Mach-II's Configuration File
If you haven't done so, download the M2PetMarket application from www.mach-II.com. A subdirectory, controller, holds the mach-ii.xml file. The file has six sections:

1. properties: Used to set general application settings including such properties as applicationRoot (the directory the application files are to be found in) and defaultEvent (the event to be used when none is specified).
2. listeners: Used to register any listeners used in the application. Mach-II allows you to use a single, general purpose listener or to specify separate listeners dedicated to specific areas of interest (e.g., UserListener, ShoppingCartListener, etc.).
3. event-filters: Used to preprocess events before any listeners respond to them. Typical functionality found in event-filters would include granular security ("Can this user call this event?") and server-side form validation.
4. plugins: Used to register components that are called at various "plugin points" throughout the life cycle of an event. The Mach-II Pet Market application uses a plug-in to ensure, among other things, that a user is logged into the application.
5. event-handlers: Used to indicate how this Mach-II application should respond to a specific event. In our "edit preferences" example, the code for the editPreferences event-handler would look like this:

   <event-handler name="editPreferences">
       <notify listener="UserListener" method="getCurrentPreferences"
       resultArg="userPreferences" />
       <view-page name="userPreferenceForm" />
   </event-handler>

6. page-views: Used to register the view pages used within this application. Pages that are registered here (providing their physical location) can then be referenced within an event-handler by (as shown in our example).

Page 1 of 3   next page »