• Choose a category
• All
• Classic-Fiction

we’ll get to that in a minute) is initialized b with a unique ID, the URL of a serverside script, and, optionally, a flag indicating whether to poll repeatedly. If it Licensed to jonathan zheng

200

CHAPTER 5

The role of the server

doesn’t, then we’ll need to fire it manually every so often. Both modes of operation may be useful, so both are included here. When the queue fires a request to the server, it converts all commands in the queue to strings and sends them with the request c.

The queue maintains two arrays. queued is a numerically indexed array, to which new updates are appended. sent is an associative array, containing those updates that have been sent to the server but that are awaiting a reply. The objects in both queues are Command objects, obeying an interface enforced by the isCommand() function d. That is:

■

It can provide a unique ID for itself.

■

It can serialize itself for inclusion in the POST data sent to the server (see c).

■

It can parse a response from the server (see e) in order to determine whether it was successful or not, and what further action, if any, it should take.

We use a function implementsFunc() to check that this contract is being obeyed. Being a method on the base class Object, you might think it is standard JavaScript, but we actually defined it ourselves in a helper library like this: Object.prototype.implementsFunc=function(funcName){

return this[funcName] && this[funcName] instanceof Function;

}

Appendix B explains the JavaScript prototype in greater detail. Now let’s get back to our queue object. The onload method of the queue e expects the server to return with an XML document consisting of tags inside a central

tag.

Finally, the repeat() f and unrepeat() g methods are used to manage the repeating timer object that will poll the server periodically with updates. The Command object for updating the planet properties is presented in listing 5.14. Listing 5.14 UpdatePropertyCommand object

planets.commands.UpdatePropertyCommand=function(owner,field,value){

this.id=this.owner.id+"_"+field;

this.obj=owner;

this.field=field;

this.value=value;

}

planets.commands.UpdatePropertyCommand.toRequestString=function(){

Licensed to jonathan zheng

Writing to the server

201

return {

type:"updateProperty",

id:this.id,

planetId:this.owner.id,

field:this.field,

value:this.value

}.simpleXmlify("command");

}

planets.commands.UpdatePropertyCommand.parseResponse=function(docEl){

var attrs=docEl.attributes;

var status=attrs.getNamedItem("status").value;

if (status!="ok"){

var reason=attrs.getNamedItem("message").value;

alert("failed to update "

+this.field+" to "+this.value

+"\n\n"+reason);

}

}

The command simply provides a unique ID for the command and encapsulates the parameters needed on the server. The toRequestString() function writes itself as a piece of XML, using a custom function that we have attached to the Object prototype:

Object.prototype.simpleXmlify=function(tagname){

var xml="<"+tagname;

for (i in this){

if (!this[i] instanceof Function){

xml+=" "+i+"=\""+this[i]+"\"";

}

}

xml+="/>";

return xml;

}

This will create a simple XML tag like this (formatted by hand for clarity):

id='001_diameter'

planetId='mercury'

field='diameter'

value='3'/>

Note that the unique ID consists only of the planet ID and the property name. We can’t send multiple edits of the same value to the server. If we do edit a property several times before the queue fires, each later value will overwrite earlier ones. Licensed to jonathan zheng

202

CHAPTER 5

The role of the server

The POST data sent to the server will contain one or more of these tags, depending on the polling frequency and how busy the user is. The server process needs to process each command and store the results in a similar response. Our CommandQueue’s onload will match each tag in the response to the Command object in the sent queue and then invoke that Command’s parseResponse