Online Book Reader

AJAX In Action [76]

The inline JavaScript is greatly simplified. All we need to do is create the EventRouter, pass in the listener functions, and provide implementations for the listeners. We leave it as an exercise for the reader to include checkboxes to add and remove each listener dynamically.

This rounds out our discussion of the Controller layer in an Ajax application and the role that design patterns—Observer in particular—can play in keeping it clean and easy to work with. In the following section, we’ll look at the final part of the MVC pattern, the Model.

4.4 Models in an Ajax application

The Model is responsible for representing the business domain of our application, that is, the real-world subject that the application is all about, whether that is a garment store, a musical instrument, or a set of points in space. As we’ve noted already, the Document Object Model is not the model at the scale at which we’re looking at the application now. Rather, the model is a collection of code that we have written in JavaScript. Like most design patterns, MVC is heavily based on object-oriented thinking.

JavaScript is not designed as an OO language, although it can be persuaded into something resembling object orientation without too much struggle. It does support the definition of something very similar to object classes through its prototype mechanism, and some developers have gone as far as implementing inheritance systems for JavaScript. We discuss these issues further in appendix B. When implementing MVC in JavaScript so far, we’ve adapted it to the JavaScript style of coding, for example, passing Function objects directly as event listeners. When it comes to defining the model, however, using JavaScript objects, and as Licensed to jonathan zheng

144

CHAPTER 4

The page as an application

much of an OO approach as we’re comfortable with for the language, makes good sense. In the following section, we’ll show how that is done.

4.4.1 Using JavaScript to model the business domain

When discussing the View, we are very much tied to the DOM. When we talk about the Controller, we are constrained by the browser event models. When writing the Model, however, we are dealing almost purely with JavaScript and have very little to do with browser-specific functionality. Those who have struggled with browser incompatibilities and bugs will recognize this as a comfortable situation in which to be.

Let’s look at a simple example. In chapter 3 we discussed our garment store application, from the point of view of generating a data feed from the server. The data described a list of garment types, in terms of a unique ID, a name, and a description, along with price, color, and size information. Let’s return to that example now and consider what happens when the data arrives at the client. Over the course of its lifetime, the application will receive many such streams of data and have a need to store data in memory. Think of this as a cache if you like—data stored on the client can be redisplayed very quickly, without needing to go back to the server at the time at which the user requests the data. This benefits the user’s workflow, as discussed in chapter 1.

We can define a simple JavaScript object that corresponds to the garment object defined on the server. Listing 4.10 shows a typical example. Listing 4.10 Garment.js

var garments=new Array();

function Garment(id,title,description,price){

this.id=id;

garments[id]=this;

this.title=title;

this.description=description;

this.price=price;

this.colors=new Object();

this.sizes=new Object();

}

Garment.prototype.addColor(color){

this.colors.append(color,true);

}

Garment.prototype.addSize(size){

this.sizes.append(size,true);

}

Licensed to jonathan zheng

Models in an Ajax application

145

We define a global array first of all, to hold all our garments. (Yes, global variables are evil. In production, we’d use a namespacing object, but we’ve omitted that for clarity here.) This is an associative array, keyed by the garment