462CHAPTER 11

The enhanced Ajax web portal

Save settings

The save settings method is equally simplistic. Recall that this method is called by our AjaxWindows.js library adaptation on the mouseup event in order to store all move and size operations:

saveWindowProperties: function(id) {

this.issuePortalCommand(		Portal.SAVE_SETTINGS_ACTION,
"ref=" +		id,
"x="	+	parseInt(elemWin.style.left),
"y="	+	parseInt(elemWin.style.top),
"w="	+	parseInt(elemWin.style.width),
"h="	+	parseInt(elemWin.style.height) );
elemWin = null;

},

Adding/deleting windows

Although we didn’t fully develop the concept out of adding and deleting windows, at least from the perspective of providing a nice UI to initiate these actions, we can certainly define the command API methods that would support these operations, as shown here:

addWindow: function(title, url, x, y, w, h) { this.issuePortalCommand( Portal.ADD_WINDOW_ACTION,

"title=" + title, "url=" + url, "x=" + x, "y=" + y, "w=" + w, "h=" + h );

},

deleteWindow: function(id) { var doDelete =

confirm("Are you sure you want to delete this window?"); if(doDelete)

this.issuePortalCommand( Portal.DELETE_WINDOW_ACTION, "ref=" + id );

},

This concludes our discussion of the APIs required to support the portal commands. Now let’s look at our portal Ajax handling.

11.6.4Performing the Ajax processing

As already noted, in this example we’re using an Ajax technique for handling responses in a script-centric way. The technique relies on the fact that the

Refactoring 463

expected response is valid JavaScript code. The thing that’s very desirable about this kind of approach is that the client doesn’t have to do any data-marshaling or parsing to grok (geek-speak for understand) the response. The response is simply evaluated via the JavaScript eval() method, and the client is absolved from all further responsibility. The negative side of this approach is that it puts the responsibility on the server to be able to understand the client-side object model and generate a syntactically correct language-specific (JavaScript) response. The second downside of this approach is partially addressed by the popular variety of this technique of using JSON to define our responses. There are some server-side libraries that aid in the generation of JSON responses (see chapter 3), although these are moving more toward what we described in chapter 5 as a data-centric approach.

For now, we’re going to stick to a script-centric system, so let’s look at our implementation and see what we can do to help it along. Let’s start with our ajaxUpdate() function and its helper runScript():

ajaxUpdate: function(request) { this.runScript(request.responseText);

},

runScript: function(scriptText) { eval(scriptText);

},

As already discussed, the response handling is simple to a fault. All we do is call the runScript() method with the responseText, and the runScript() simply eval()s the response text. So why, you might ask, don’t we just get rid of the runScript() method altogether and just call eval() from within the ajaxUpdate() method? Well, that’s certainly a valid and useful approach. It might be nice, however, to have a method that encapsulates the concept of running a script. For example, what if we added a preprocessing step or a postprocessing step to our runScript() implementation? Again, we’ve isolated a change point. Our ajaxUpdate() method is happily oblivious of the change, and we pick up the new behavior. One interesting application of this technique would be a preprocessor that does token replacement of values that reside on the client before executing.

Finishing out our Ajax discussion with the ever-important handling of errors, let’s show our handleError() method. Recall that just as the ajaxUpdate() method is an implied contract required for collaboration with the net.ContentLoader, so is the handleError(). The handleError() method is shown here: