Some small refactoring case studies

83

Register

Observer

Unregister

Observable

Figure 3.2

Notify

Division of responsibility in the

Observer pattern. Objects wishing to

Maintain list

of registered

be notified of an event, the Observers,

Observers

can register and unregister themselves

with the event source, Observable,

which will notify all registered parties

Responsibility of Observer

Responsibility of Observable

when an event occurs.

Provided that every subsystem uses this approach, we can offer a much cleaner way of setting up all the subsystems without tangling them up in one another. Of course, it takes only one rogue piece of code to directly override window.onload and the system will break. But we have to take charge of our codebase at some point to prevent this from happening.

It’s worth pointing out here that the newer W3C event model also implements a multiple event handler system. We’ve chosen to build our own here on top of the old JavaScript event model because implementations of the W3C model aren’t consistent across browsers. We discuss this in greater detail in chapter 4. The design pattern into which our code here is refactored is called Observer. Observer defines an Observable object, in our case the built-in window object, and a set of Observers or Listeners that can register themselves with it (figure 3.2). With the Observer pattern, responsibility is apportioned appropriately between the event source and the event handler. Handlers take responsibility for registering and unregistering themselves. The event source takes responsibility for maintaining a list of registered parties and firing notifications when the event occurs. The pattern has a long history of use in event-driven UI programming, and we’ll return to Observer when we discuss JavaScript events in more detail in chapter 4. And, as we’ll see, it can also be used in our own code objects independently of the browser’s mouse and key event processing. For now, let’s move on to the next recurring issue that we can solve through refactoring.

3.2.3 Reusing user action handlers: Command pattern

It may be obvious to say that in most applications, the user is telling (through mouse clicks and keyboard presses) the app to do something, and the app then does it. In a simple program, we might present the user with only one way to Licensed to jonathan zheng

84

CHAPTER 3

Introducing order to Ajax

perform an action, but in more complex interfaces, we will often want the user to be able to trigger the same action from several routes.

Implementing a button widget

Let’s say that we have a DOM element styled to look like a button widget that performs a calculation when pressed and updates an HTML table with the result. We could define a mouse-click event-handler function for the button element that looks like this:

function buttonOnclickHandler(event){

var data=new Array();

data[0]=6;

data[1]=data[0]/3;

data[2]=data[0]*data[1]+7;

var newRow=createTableRow(dataTable);

for (var i=0;icreateTableCell(newRow,data[i]);

}

}

We’re assuming here that the variable dataTable is a reference to an existing table and that the functions createTableRow() and createTableCell() take care of the details of DOM manipulation for us. The interesting thing here is the calculation phase, which could, in a real-world application, run to hundreds of lines of code. We assign this event handler to the button element like so:

buttonDiv.onclick=buttonOnclickHandler;

Supporting multiple event types

Let’s say that we have now supercharged our application with Ajax. We are polling the server for updates, and we want to perform this calculation if a particular value is updated from the server, too, and update a different table with the data. We don’t need to go into the details of setting up a repeated polling of the server here. Let’s assume that we have a reference to an object called poller. Internally, it is using an XMLHttpRequest object and has set its onreadystatechange