The Prototype Framework makes it very easy to deal with Ajax in a way that is both cross-browser-compliant and simple, taking the difficulty out of building applications around calls. Besides simple requests, Prototype’s Ajax module also helps developers deal with the JavaScript code (JavaScript Object Notation [JSON]) returned from a server, and provides helper classes for server polling.

Ajax functionality is contained in the global Ajax object. The transport for Ajax requests is in XMLHttpRequest, with browser differences abstracted from the user in a transparent way. Actual requests are made by creating instances of the Ajax.Request object:

new Ajax.Request('<request URL>', {
    method: 'get'
});

The first parameter is the URL of the request, and the second parameter is the options hash, a set of key/value pairs that affect the output of the object. The method option refers to the HTTP method to be used. The default method is POST.

By default, Ajax requests are asynchronous, meaning that callbacks are necessary to handle the data that will come back from a response. Callback methods are passed in the options hash when making a request:

new Ajax.Request('<request URL>', {
    method: 'get',
    onSuccess: function(p_xhrResponse) {
        var response = p_xhrResponse.responseText || 'NO RESPONSE TEXT';

        alert('Success! 

' + response);
    },
    onFailure: function( ) {
        alert('Something went wrong.'),
    }
});

Two callback methods are passed in the hash of the preceding example, alerting us of either success or failure of the Ajax request: onSuccess and onFailure are called accordingly based on the status of the response. The first parameter that is passed to both callback methods is the native XMLHttpRequest object from which you can use its responseText and responseXML properties, respectively. Note that the second callback method is not expecting the XMLHttpRequest object, and does not provide a parameter for it.

Both, one, or neither callback may be specified in the options hash; that is entirely up to the developer. Other available callbacks that may be specified are:

Each callback matches a certain state of the XMLHttpRequest transport, except for onException, which is executed when there is an exception while dispatching other callbacks.

In addition to these callbacks, there are also onXXXX callbacks, where the XXXX is the HTTP response status (things such as 200 or 404). You should be aware that if these callbacks are used, the onSuccess and onFailure callbacks will not be executed because the onXXXX callbacks always take precedence. If a developer is going to use these callbacks, he better know what he is doing, and have a specific reason for doing it.

Making simple calls to the server is fine, but Ajax is more useful when parameters can also be sent with the call. To send parameters with Prototype’s Ajax object, pass the parameters property as part of the options hash:

new Ajax.Request('<request URL>', {
    method: 'get',
    parameters: { param1: 'value1', param2: value2 }
});

Parameters can be passed with this property in two ways: as a hash (the preferred method) or as a string of key/value pairs separated by ampersands (e.g., parameter1=value1&parameter2=value2).

Parameters may be used with both GET and POST requests, but you should keep in mind that GET requests to your application should not cause data to be changed. Another thing to consider is that browsers are less likely to cache a response to a POST request, and are more likely to do so with GET.

One of the primary applications for the parameters property is sending the contents of a <form> element with an Ajax request. Instead of parsing all of the <input> elements in the <form> to build what needs to be sent, Prototype has a helper method available specifically for this, called Form.serialize( ). For example:

new Ajax.Request('<request URL>', {
    method: 'get',
    parameters: $('<form_id>').serialize(true)
});

Other parameters that are sometimes forgotten but may also be sent with the Ajax request are custom HTTP request headers. If you need to send these headers, the requestHeaders option is available. The value of this option is either a hash of name-value pairs or a flattened array of name-value pairs, such as:

['X-Custom-1', 'value', 'X-Custom-2', 'other value']

When you need a custom post body (not parameters in the parameters option) to go along with a POST request, you can use a postBody option. You would use it for content such as this:

<request>
    <parameters>
        <param1>value1</param1>
        <param2>value2</param2>
    </parameters>
</request>

When using the postBody option, parameters that are passed with the parameters option will never be posted because postBody takes precedence as a body for the POST. Using this option means the developer knows what she is doing.

Plenty of times the response from the server is returned not as plain text or XML, but rather as JSON. When the MIME type that the client receives matches the text/javascript type, Prototype will automatically eval( ) the response. There is no need for the developer to handle this case explicitly.

When the response holds an X-JSON header, however, its content will be parsed, saved as an object, and sent to the callbacks as the second argument in the method. For example:

new Ajax.Request('<request URL>', {
    method: 'get',
    parameters: $('<form_id>').serialize(true),
    onSuccess: function(p_xhrResponse, p_jsonResponse) {
        alert(((p_jsonResponse) ? Object.inspect(p_jsonResponse) :
            'NO JSON OBJECT'));
    }
});

This functionality of Prototype is handy for when you want to fetch nontrivial data using Ajax, but you do not want the overhead associated with parsing XML in the response. JSON is faster and lighter than XML.

Every Ajax request that uses Prototype tells the Ajax.Responders object when it is created. With this object, callbacks can be registered that will be executed on whatever state is specified for every Ajax.Request issued. For example:

Ajax.Responders.register({
    onCreate: function( ) {
        alert('A request has been initialized.'),
    },
    onComplete: function( ) {
        alert('A request completed.'),
    }
});

Once this code is executed, every callback matching an XMLHttpRequest transport state is allowed here, with an addition of onCreate and onComplete. Globally tracking requests in this manner may be useful in a number of ways. They can be logged for debugging purposes, or a global exception handler could be made that informs users of a possible connection problem.

Developers often want to make Ajax requests that receive XHTML fragments as the response that update parts of a document. You can accomplish this with Ajax.Request and an onComplete callback method, but Prototype provides an easier way using Ajax.Updater.

For example, let’s assume that the following XHTML is in your document:

<h2>View a list of products</h2>
<div id="productsContainer">(fetching product list...)</div>

The products container is empty (except for a display message to the user), and it needs to be filled with an XHTML fragment returned with an Ajax response. Doing so is as simple as this:

new Ajax.Updater('productsContainer', '<request URL>', {
    method: 'get'
});

That’s all there is to it with Prototype. The arguments for Ajax.Updater are the same as Ajax.Request, with the exception of an additional argument specifying the receiver element of the response. Prototype will magically update the container with the response using the Element.update( ) Prototype method.

What happens, however, if an error occurs and the response is an error message instead of an XHTML fragment? Most of the time, you do not want to insert an error message in places where users expect to see normal page content. Fortunately, Prototype provides a convenient solution to this problem. Instead of the id of the container as the first argument of Ajax.Updater, a developer may pass in a hash of two different containers in this form:

{ success: 'productsContainer', failure: 'errorContainer' }

A successful response will have its content placed in the success container, and an unsuccessful response will have the error message written to the failure container. This allows the interface to remain more user-friendly.

Other times you may choose not to overwrite the existing content of a container, instead wanting to insert new content on the top or bottom of the existing content. You can accomplish this using Insertion.Top or Insertion.Bottom passed in the insertion option of the options hash. For example:

new Ajax.Updater('productsContainer', '<request URL>', {
    method: 'get',
    insertion: Insertion.Top
});

Ajax.Updater will insert the returned XHTML fragment into the productsContainer element. Ajax.Updater is a powerful tool provided by Prototype to complete tasks often needed by developers. This simplifies the developer’s role by reducing the amount of code he needs to write and maintain.

As great as Ajax.Updater is at simplifying an Ajax request, suppose you want to run the request periodically to repeatedly get updated content from the server. Prototype provides a tool to do this, too: Ajax.PeriodicalUpdater. Ajax.PeriodicalUpdater runs Ajax.Updater at regular intervals. For example:

new Ajax.PeriodicalUpdater('productsContainer', '<request URL>', {
    method: 'get',
    insertion: Insertion.Top,
    frequency: 1,
    decay: 2
});

You will notice the two new options added to the options hash in the preceding code: frequency and decay. frequency is the interval in seconds at which the requests are to be made. It is one second in the example, meaning an Ajax request is executed every second (the default frequency is two seconds).

In this case, the frequency of calls may begin to present a burden to the server; it has to process quite a load. This is especially true if the page with the Ajax.PeriodicalUpdater is left open for some time. This is the reason for the decay option. It is the factor by which the frequency is multiplied every time the response body of the request is the same as the previous one. Requests would start at one second, then two seconds, four seconds, eight seconds, and so on. Whenever there is new content in the response body, this will reset and the decay effect will start over. This factor makes sense only for content that does not change rapidly, and your application gets the same content frequently.

The script.aculo.us Autocompleter controls allow for Google Suggest-like local and server-powered auto-completing text input fields. These two methods for auto-completion come from the following classes:

new Ajax.Autocompleter(<id of text field>, <id of DIV element to populate>, URL,
    options);

<input type="text" id="txtAutocomplete" name="txtAutocompete" value="" />
<div id="txtAutocomplete_choices" class="autocomplete"></div>

new Ajax.Autocompleter('txtAutocomplete', 'txtAutocomplete_choices',
    '<request URL>', {});

<input type="text" id="txtAutocomplete" name="txtAutocomplete" value="" />
<span id="txtAutocomplete_indicator" style="display: none;">
    <img src="<path to images>/spinner.gif" alt="Working..." title="Working..." />
</span>
<div id="txtAutocomplete_choices" class="autocomplete"></div>

new Ajax.Autocompleter('txtAutocomplete', 'txtAutocomplete_choices',
        '<request URL>', {
    paramName: 'value',
    minChars: 2,
    updateElement: addItemToList,
    indicator: 'txtAutocomplete_indicator'
});

<ul>
    <li>Ajax: The Definitive Guide</li>
    <li>Ajax Design Patterns</li>
</ul>

new Autocompleter.Local(<id of text field>, <id of DIV element to populate>,
    <array of string data>, options);

<p>
    <label for="90sRockBand">Your favorite rock band from the 90s:</label>
    <input id="90sRockBand" name="90sRockBand" type="text" size="40" value="" />
</p>
<div id="bandList"></div>

<style type="text/javascript">
    //<![CDATA[
    new Autocompleter.Local('90sRockBand', 'bandList',
        [
            'Aerosmith','Bush','Cake','Candlebox','Collective Soul','Creed',
            'Dave Matthews Band','Everclear','Faith No More','Garbage','Green Day',
            'Guns 'n Roses','Korn','Linkin Park','Live', Metallica',
            'Nine Inch Nails','Nirvana','Oasis','Pantera','Pearl Jam','Prodigy',
            'Radiohead','Rage Against the Machine','Red Hot Chili Peppers',
            'Smashing Pumpkins','Soul Asylum','Soundgarden','Stone Temple Pilots',
            'The Offspring','Tool','U2','Weezer','White Zombie'
        ], {
        minChars: 2
    });
    //]]>
</style>

new Ajax.Autocompleter('id', 'upd', '<request URL>', {
    tokens: ','
});

script.aculo.us offers Flickr-style in-place text editing with Ajax behind the scenes for on-the-fly text boxes. Two classes are available to accomplish this:

new Ajax.InPlaceEditor(element, url, [options]);

var editor = new Ajax.InPlaceEditor(element, url, [options]);
.
. // Code here...
.
editor.dispose( );

new Ajax.InPlaceEditor(element, url, { collection: [array], [options] });

Besides the Ajax functionality provided by script.aculo.us, this library also contains effects that can enhance the feel of an application. These effects can give applications more of a Web 2.0 look with their manipulation of elements on the page. More important, however, these effects can draw a user’s attention to the fact that the page is doing something when Ajax is working behind the scenes. For more information on these effects, see the script.aculo.us documentation Wiki at http://wiki.script.aculo.us/scriptaculous/.

Ajax with Rico is a little different from the Prototype Ajax objects. Two steps are involved in creating Ajax requests with this library. The first step is to register the request by giving it a logical name and a URL to request to, and registering an element that can have its innerHTML replaced by the HTML passed in the Ajax response. For example:

function Body_OnLoad( ) {
    ajaxEngine.registerRequest('<requestName>', '<requestURL>'),
    ajaxEngine.registerAjaxElement('<elementToUpdate>'),
}

This code would need to be called when the page is loaded, and it sets up the logical name of the request and tells where the request is to go. It then specifies an element that can be modified.

The second step is to send the actual request to the server. Assuming that this next example is called with a comma-delimited string of values, it parses the data out to create parameters to be passed with the request:

function RequestData(p_value) {
    var arrValue = p_value.split(','),
    var parameters = '';

    for (var i = 0, il = arrValue.length; i < il; i++)
        parameters += arrValue[0] + '=' + arrValue[1];
    ajaxEngine.sendRequest('<elementToUpdate>', parameters);
}

When the response is returned with this example, it is handled entirely by the Rico Ajax engine, and it replaces the specified element’s innerHTML with the response.

The Ajax response to a Rico request must be specifically formatted for the Ajax engine to handle it correctly. The Ajax response must have the following structure:

<ajax-response>
    <response type="[responseType]" id="[elementToUse]">
        <!-- Ajax payload -->
    </response>
</ajax-response>

Rico currently recognizes two response types: element and object. When the response type is element, it is telling the Ajax engine that there should be an element in the page with the passed id, and the payload inside the response should replace the existing innerHTML of the element.

However, when the response type of the Rico response is object, it is telling the Ajax engine that there is an object with the id that has an ajaxUpdate( ) method to call. The engine calls this method, passing the payload of the response as a parameter. This can then be processed by the page. For example:

<ajax-response>
    <response type="object" id="elementUpdater">
        <!-- Ajax payload -->
    </response>
</ajax-response>

Here, the XML within the <response> element will be processed by the method contained in the object with id elementUpdater. This is more limiting than some libraries, in that XML is expected to be sent back with every request, but it is simple.

Rico was built for effects, and not Ajax, when it was authored, and it therefore contains some very useful effects tools and behaviors for enhancing web applications. LiveGrid is, of course, Rico’s most popular widget, but it also includes many other robust and simple-to-use effects. Accordions, drag and drop, and rounded corners are just some of the other useful functionalities contained within the Rico library. For more information on the effects and their uses, see the Demos page at http://demos.openrico.org/.

The XHR class, first introduced in MooTools 1.0, is a basic wrapper for the XMLHttpRequest object. It allows for a simple server request for data with options to control the basics of Ajax requests. Here is the XHR class:

var XHR = new Class({
    Implements: [Chain, Events, Options],
    options: {
        method: 'post',
        async: true,
        data: null,
        urlEncoded: true,
        encoding: 'utf-8',
        autoCancel: false,
        headers: {},
        isSuccess: null
    },
    setTransport: function( ) {
        // setTransport code
    },
    initialize: function( ) {
        // initialize code
    },
    onStateChange: function( ) {
        // onStateChange code
    },
    isSuccess: function( ) {
        // isSuccess code
    },
    onSuccess: function( ) {
        // onSuccess code
    },
    onFailure: function( ) {
        // onFailure code
    },
    setHeader: function(name, value) {
        // setHeader code
    },
    getHeader: function(name) {
        // getHeader code
    },
    send: function(url, data) {
        // send code
    },
    request: function(data) {
        // request code
    },
    cancel: function( ) {
        // cancel code
    }
});

The XHR class is easy to use. For example:

new XHR({ method: 'get', onSuccess: NextFunction}).send('<requestURL>',
    'param1=value1'),

Here, the location of the Ajax request is <requestURL>, sending it a parameter param1 with a value of value1. With a successful request, the function NextFunction( ) is called.

Ajax is simple to use with MooTools, and it has a similar feel to Prototype’s Ajax classes. MooTools uses the Ajax class to make requests to the server. For example:

new ajax('<requestURL>', {
    postBody: 'param1=value1',
    onComplete: parseResponse,
    update: '<divContainer>'
}).request( );

In this example, an Ajax request is made to <requestURL>, sending it a parameter param1 with a value of value1. The text results are placed into the update container <divContainer>, and the function parseResponse( ) is called when the request is complete with the parameter request (the XHR response).

Looking at the Ajax class will give you a better idea of the object and what you can set with it:

var Ajax = XHR.extend({
    options: {
        data: null,
        update: null,
        onComplete: Class.empty,
        evalScripts: false,
        evalResponse: false
    },
    initialize: function(url, options) {
        // initialize code
    },
    onComplete: function( ) {
        // onComplete code
    },
    request: function(data) {
        // request code
    },
    evalScripts: function( ) {
        // evalScripts code
    },
    getHeader: function(name) {
        // getHeader code
    }
});

As you can see, the Ajax class is built as an extension of the XHR class, which holds the meat of the code for making requests to the server. As such, you can set all of the XHR options here as well. Think of the Ajax class as the robust class for making requests to the server.

The Ajax class is built with the ability to easily send a form as an Ajax request through a special extension, shown here:

Object.toQueryString = function(source) {
    var queryString = [];
    for (car property in source) queryString.push(encodeURIComponent(property)
+ '=' encodeURIComponent(source[property]));
    return queryString.join('&'),
};

Element.extend({
    send: function(options) {
        return new Ajax(this.getProperty('action'),
            $merge({data: this.toQueryString( )}, options,
            {method: 'post'})).request( );
    }
});

Now, when you have a basic form that needs to be submitted, it is as simple as:

<form id="myForm" action="submit.php method="post">
    <input type="text" id="username" name="username" value="" />
    <input type="password" id="passwd" name="passwd" value="" />
    <input type="button" value="Login" onclick="$('myForm').send( );" />
</form>

It doesn’t get much easier than that, does it?

MooTools does much more than provide a wrapper for Ajax requests to the server. It also provides a number of effects that can enhance your application and give it more of a Web 2.0 look. These effects range from drag-and-drop functionality to element effects that provide transitions and other sliding and morphing effects that can highlight Ajax responses to the user. For a full list of the latest effects and documentation on how to use them, consult the MooTools web site at http://docs.mootools.net/.

Dojo allows you to bind all Ajax requests, instead of calling the request object directly, giving a little more error handling than you would normally get. You can find this IO method in /src/io/common.js, and it looks like this:

dojo.io.bind = function (request) {
    if (!(request instanceof dojo.io.Request)) {
        try {
            request = new dojo.io.Request(request);
        }
        catch (e) {
            dojo.debug(e);
        }
    }
    // .
    // .
    // .

Sending an Ajax request is easy with dojo.io.bind( ), and it has a simple format to follow:

dojo.io.bind ({
    url: '<requestURL>',
    load: function(type, data, event) {
        // functionality
    },
    error: function(type, data, event) {
        // functionality
    },
    timeout: function(type, data, event) {
        // functionality
    },
    timeoutSeconds: <value>,
    mimetype: 'text/html'
});

Requesting data with Ajax is easy with the Dojo Toolkit, but what about the data that is sent back with a server response? Dojo has different methods for accessing elements from within JavaScript than the other libraries and frameworks we have looked at thus far in this appendix.

With Dojo, an element is accessed directly with its id attribute through the dojo.byId( ) method. Say you have an element meant to hold the data from an Ajax server response, like this:

<div id="container"></div>

It’s easy to access this element’s innerHTML with Dojo by using the following:

dojo.byId('container').innerHTML

Thinking about our Ajax example from before, we want to take the data response from the server and place that information into the innerHTML of our container <div> element. Everything needed to configure an Ajax request and handle the corresponding response can be placed in an object, and Dojo can then bind that object. For example:

var binding = {
    url: '<requestURL>',
    mimetype: 'text/html',
    load: function(type, data, event) {
        dojo.byId('container').innerHTML = data;
    }
};

dojo.io.bind(binding);

Here, the URL, MIME type, and callback functions are handled in our binding object. You will also see that the data from the response is set to the innerHTML of our container element. Handling data is pretty simple with Dojo when it is normal data coming back, but what about JSON information?

It’s easy to handle JSON with dot notation that Dojo uses when dealing with JSON objects, which makes handling data sent back from a server simple to manipulate and parse when it is sent back as JSON. Take this JSON data, for example:

{'AjaxBooks':
    [
        {'book':
            { 'id': '1' },
            'title': 'Ajax: The Definitive Guide',
            'isbn': '0-596-52838-8'
        },
        {'book':
            { 'id': '2' },
            'title': 'Ajax Hacks',
            'isbn': '0-596-10169-4'
        },
        {'book':
            { 'id': '3' },
            'title': 'Securing Ajax Applications',
            'isbn': '0-596-52931-7'
        }
    ]
}

Here, we have some simple book data that is sent back to the client from the server, formatted as JSON text. You can manipulate this data with dot notation as follows:

JSON.AjaxBooks[0].book.id;    // 1
JSON.AjaxBooks[2].title;    // Securing Ajax Applications

Using this parsing method to manipulate the contents of a page, in this next example, you can see Dojo making an Ajax request that will change the values of certain elements when the data is returned:

var binding = {
    url: '<requestURL>',
    method: 'post',
    load: function(type, data, event) {
        var json = eval('(' + data + ')'),

        dojo.byId('title').innerHTML = json.AjaxBooks[0].title;
        dojo.byId('isbn').innerHTML = json.AjaxBooks[0].isbn;
    }
};

dojo.io.bind(binding);

Dojo makes Ajax requests pretty simple, as it does with most things in its toolkit. Using dojo.io.bind( ) with an object built for the request keeps everything together and allows for easy additional Ajax requests if needed.

Dojo gives you the flexibility to encode parameters in the URL, but it also has a nice feature for sending the contents of an entire form by using the formNode parameter. For example:

var binding = {
    url: '<requestURL>',
    method: 'post',
    load: function(type, data, event) {
        // functionality
    },
    error: function(type, data, event) {
        // functionality
    },
    timeoutSeconds: <value>,
    timeout: function(type, data, event) {
        // functionality
    },
    formNode: dojo.byId('myForm')
};

dojo.io.bind(binding);

This allows for easier data submission of a form with Ajax instead of relying on the traditional full-page posting of the classical Web.

There is a lot more to Dojo than Ajax, so much more that it would take a whole other book to include it all. Dojo, being package-based, has many developers working on individual pieces of the toolkit at any one time, and this architecture has had great success with the number and variety of packages that have been produced, from Web 2.0 effects and enhancements to helpful charting tools and other application-type widgets. You can find more information on the rest of Dojo at http://dojotoolkit.org/docs.

Sarissa takes a more traditional approach to Ajax requests and DOM manipulation as a whole. Because of this, Ajax requests and their responses will have the same basic look and feel as the standard way of making Ajax calls. However, Sarissa uses a wrapper to execute all the functionality Ajax needs.

Everything with Sarissa starts with the DOM document, and Ajax is no exception. The first thing you must do before making Ajax requests with Sarissa is to create a document—for example, var oDomDoc = Sarissa.getDomDocument( );. The request and callback function handler are defined from there. Here is a typical example:

var oDomDoc = Sarissa.getDomDocument( );

oDomDoc.async = true;
oDomDoc.onreadystatechange = handleChanges;
oDomDoc.load('<requestURL>'),

function handleChanges( ) {
    if (oDomDoc.readyState == 4) {
        // functionality
    }
}

With Sarissa, even sending the request asynchronously is not a given, and you must define it as part of the setup. You need to create a state change handler if the server will receive any data, and then make the call with any parameters that need to be passed with the request. As I said, this process generally reflects how a standard Ajax call would be made.

Parsing data returned from the server in response to an Ajax request is also handled in much the same way as it would when the data passed is XML. Any XML DOM manipulation you would have done to a normal responseXML object, you can do directly on the oDomDoc, which is the returned data. For example:

function parseData( ) {
    var myData = oDomDoc.getElementsByTagName('data1'),

    for (var i = 0, il = myData.childNodes.length; i < il; i++) {
        var data = myData.childNodes[i];

        $('container').innerHTML = data;
    }
    $('container').addClassName(oDomDoc.getElementsByTagName('class')[0]);
}

For more information on what Sarissa can do as far as manipulation with JavaScript and the DOM, refer to Chapter 5 of this book.

Sarissa does offer tools that go above what the DOM natively offers in the browser. A handy function is Sarissa’s ability to serialize the returned XML. For example:

function parseData( ) {
    var serialized = Sarissa.serialize(oDomDoc);

    $('container').innerHTML = serialized;
}

This makes the XML much more human-readable, in cases where this may be necessary. It certainly makes it easier to debug returned data!

As you no doubt have seen, Sarissa is built to handle XML and wrap all the XML functionality of JavaScript to make it simpler for you to develop with. It specializes in everything to do with manipulating XML and gives the tools to do so: XPath, XSLT, and XML functionality are all a part of the Sarissa library. For this reason, when all you need for an application is a lightweight library to handle Ajax and other XML functions, Sarissa is an excellent choice. It is a lesser option when the library requires other functionality, such as the ability to handle JSON. When it comes to XML, however, there is nothing better. For more information on Sarissa’s XML functionality, visit http://dev.abiss.gr/sarissa/jsdoc/index.html.

The MochiKit.Async object enables you to manage asynchronous code on the client. This model was inspired by Twisted. For example:

var json = loadJSONDoc(URL);

function ParseData(p_meta) {
    if (MochiKit.Async.VERSION == p_meta.version)
        alert('You have the latest version of MochiKit.Async'),
    else
        alert('MochiKit.Async version' +  + 'is available, please upgrade1'),
}

function FetchError(p_err) {
    alert('There was a problem fetching the meta data for MochiKit.Async.'),
}

json.addCallbacks(parseData, FetchError);

The real Ajax implementation in MochiKit, however, is controlled by a different object in the library.

The Deferred object allows for all asynchronous requests that happen only once to be consistent across the implementation on the client. This wraps XHR functionality and adds features that make it a robust object.

Deferred has different error handlers built into it to tackle the different types of problems that could occur with an asynchronous request, making it easier to handle errors in an effective manner. Table B-4 shows these error types and describes what they are for.

A Deferred object creates the functionality that will surround an Ajax request, using constructor methods it contains. For example:

var deferred = new Deferred( );

deferred.addCallback(myCallback);
deferred.addErrback(myErrback);

Table B-5 lists the methods the Deferred object uses to create an instance of the object.

The Deferred object has three states associated with it: -1 means No value yet, 0 means Success, and 1 means Error.

These values define the state of the Deferred object, and not the actual Ajax request or response.

Other functions are used with Deferred objects that handle the bulk of the work involved in creating asynchronous code in an application, as shown in Table B-6.

An example Ajax request with MochiKit using these functions would look something like this:

var deferred = doXHR('<requestURL>', {
    method: 'POST',
    sendContent: 'data1=value1&data2=value2'
});

deferred.addCallbacks(parseData, handleError);

function parseData(res) { ... }

function handleError(res) { ... }

MochiKit provides much more functionality than the ability to control asynchronous threads in JavaScript using a deferred object methodology. MochiKit also offers objects for logging in an application, and Web 2.0 functionality such as drag and drop and sorting. You can find more information on what MochiKit provides at http://www.mochikit.com/doc/html/MochiKit/index.html.

You can make Ajax calls with jQuery in several ways, thanks to several functions available for specific requesting needs. Table B-7 shows these functions.

The jQuery.ajax(method) will give you the necessary functionality to make the most flexible type of request. For example:

$.ajax({
    url: '<requestURL>',
    type: 'POST',
    data: 'data1=value1&data2=value2',
    success: parseData
});

function parseData(resp) { ... }

If you know you do not need the flexibility of jQuery.ajax( ), use one of the other functions that jQuery provides. This makes it easier on the developer by configuring parameters automatically, instead of dynamically when a request is created.

jQuery offers other functionality, as do most other libraries in this appendix. Beyond Ajax wrappers and their associated functionalities, jQuery will give you the special effects and functionality to create Web 2.0 applications. More than that, though, jQuery provides good tools for bringing more powerful CSS into the JavaScript of a web page. For more information on jQuery’s additional functionality, see http://docs.jquery.com/Main_Page.