• Choose a category
• All
• Classic-Fiction

In this second approach to DOM event handling, everything is done with object references, not strings, and no global lookup array is needed. This is the approach that has been used throughout this book. Figure B.2 illustrates this approach.

This approach simplifies the event handler’s job considerably. The constructor function for the Model object needs no specialized ID manipulation, and the foo() method is defined as before. When we construct DOM nodes, we exploit JavaScript’s dynamic ability to attach arbitrary attributes to any object and clip the Model object directly onto the DOM node receiving the event:

myObj.prototype.createView=function(){

...

this.body=document.createElement("div");

this.body.modelObj=this;

...

this.titleBar=document.createElement("div");

this.titleBar.modelObj=this;

this.titleBar.onclick=fooEventHandler;

...

}

When we write the event handler, we can then get a direct reference back to the Model:

Model object

DOM element

2. Resolve

this.modelObj

1. Resolve this

Event handler

Figure B.2

Attaching a reference to the Model directly to

a DOM node makes it easier for the event

handler function to find the Model at runtime.

Licensed to jonathan zheng

614

APPENDIX B

JavaScript for object-oriented programmers

function fooEventHandler(event){

var modelObj=this.modelObj;

if (modelObj){ modelObj.foo(); }

}

}

No finders, no global lookups—it’s as simple as that.

One word of warning, however. When using this pattern, we create a cyclic reference between a DOM and a non-DOM variable, and web browser folklore has it that this is bad for garbage collection under certain popular browsers of the day. If this pattern is used correctly, memory overheads can be avoided, but I’d recommend you study chapter 7 before implementing the Attach Model To DOM

Node pattern.

Understanding how a JavaScript function has defined its context has helped us to develop an elegant reusable solution for the browser event model, then. The ability of a function to switch between contexts can be confusing at first, but understanding the model behind us helps to work with it.

The final thing that we need to understand about JavaScript functions is the language’s ability to create closures. Again, Java and C# lack the concept of closures, although some Java and .NET scripting languages, such as Groovy and Boo, support them, and C# 2.0 will support them, too. Let’s look at what they are and how to work with them.

B.3.5 Closures in JavaScript

On its own, a Function object is incomplete—to invoke it, we need to pass in a context object and a set of arguments (possibly an empty set). At its simplest, a closure can be thought of as a Function bundled with all the resources that it needs to execute.

Closures are created in JavaScript implicitly, rather than explicitly. There is no constructor function new Closure() and no way to get a handle on a closure object. Creating a closure is as simple as declaring a function within a code block (such as another function) and making that function available outside the block. Again, this sounds a bit weird conceptually but is simple enough when we look at an example. Let’s define a simple object to represent a robot and record the system clock time at which each robot is created. We can write a constructor like this:

function Robot(){

var createTime=new Date();

this.getAge=function(){

var now=new Date();

Licensed to jonathan zheng

Methods and functions

615

var age=now-createTime;

return age;

}

}

(All the robots are identical, so we haven’t bothered to assign names or anything else through constructor arguments.) Normally, we would record createTime as a member property, that is, write

this.createTime=new Date();

but here we’ve deliberately created it as a local variable, whose scope is limited to the block in which it is called, that is, the constructor. On the second line of the constructor, we define