Análisis del proceso de trabajo

The preceding example is simple and illustrates that Ajax is indeed an 11-line solution. However, there are many ramifications; the first and most notable is that the simple example will run only on Microsoft Internet Explorer. When using another browser such as Mozilla Firefox or Apple’s Safari, the sample will not work. When writing Ajax applications, you need to think in a cross-platform, cross-browser manner because you will be confronted with these problems right from the beginning.

Extending the first ramification, it means when writing Ajax applications that Dynamic HTML is your user interface toolkit. Some individuals may extend the functionality by including Java applets or ActiveX controls, or even Macromedia Shockwave or Flash,2 but in essence Ajax

requires that you understand Dynamic HTML. I highly recommend that all Ajax developers purchase the book Dynamic HTML: The Definitive Reference by Danny Goodman (O’Reilly Media, 2002). It is a thick book, but it provides answers to all browser issues—what works and does not work.

The second ramification is that all content should be referenced by using REST URLs. If REST is not used, then referencing the data within the brown areas of Figure 2-1 will result in using remote procedure calls (RPCs). Using RPCs is not recommended, because additional overhead is required, such as method name encoding, parameter encoding, and data decoding. Programmers may like using RPCs, but they are intended for classical programming techniques and not for Ajax or Internet applications.3

The third and final ramification is that to keep things simple. It is possible to reference other websites, but that will introduce security issues that will need to be resolved. For example, using Internet Explorer to make the domain trusted where the HTML page was downloaded allows XMLHttpRequest to download content from other domains. Keeping things simple includes using techniques that work across all browsers on all platforms. It is possible to do more “neat” and “cool” tricks, but those tricks need to be maintained and extended.

It is important to understand these ramifications because they define from an architectural perspective our boundaries on what patterns and best practices can and cannot be applied.

XMLHttpRequest Details

Regardless of how the XMLHttpRequest type is instantiated, and regardless of which browser and platform are used, a set of methods and properties is associated with XMLHttpRequest. Table 2-1 defines the methods.

3. http://www.tbray.org/ongoing/When/200x/2004/04/26/WSTandP, Web Services Theory and Practice, Tim Bray

Table 2-1. Methods of XMLHttpRequest

Method Description

abort() Stops a request that is being processed.

getAllResponseHeaders() Returns the complete set of HTTP headers from the HTTP request as a string.

getResponseHeader(label) Returns the associated HTTP header identified by the variable label.

open(method, URL, asyncFlag, username, password)

Opens and prepares an HTTP request identified by the HTTP method and URL. The variable asyncFlag can either be true or false, where true means to make an asynchronous request. The variables username and

password are used to access a protected HTTP resource.

send(content) Executes the HTTP request, where the variable content

represents data that is posted if applicable.

You’ll be using these methods throughout the book, so more details are not necessary at this moment. What does need some special attention are the properties. When a request has retrieved data, four properties are used to indicate how the request fared. Consider the following HTML code that references the four properties and would be called after the send method had completed:

document.getElementById('httpcode').innerHTML = xmlhttp.status; document.getElementById('httpstatus').innerHTML = xmlhttp.statusText; document.getElementById('result').innerHTML = xmlhttp.responseText; document.getElementById('xmlresult').innerHTML = xmlhttp.responseXML;

The four properties can be subdivided into two subcategories: result and HTTP status. The properties status and statusText retrieve the HTTP result codes. The property status contains an integer value, such as 200 for success. The property statusText contains a textual represen- tation of the HTTP result code, such as OK. The properties responseText and responseXML contain the result of the HTTP request. The difference between the two properties is that responseText

contains a string buffer of the results, and responseXML references an XML Document Object Model (DOM) representation of the results. If responseXML does reference an XML DOM instance, then responseText references a valid XML text buffer.

Adding the property code to a modified version of the simple Ajax application and executing the HTML page results in Figure 2-4.

Figure 2-4. Output of XMLHttpRequest properties in two web browsers

The results in Figure 2-4 are generated for two browsers: Mozilla Firefox and Microsoft Internet Explorer. The values for status, statusText, and responseText are identical across most browsers (Internet Explorer, Firefox, and Safari). The difference is the value for responseXML.

For Firefox a textual representation does not exist, for Internet Explorer it is text with square brackets, and finally for Safari it is the text undefined. The reason for the difference is that the script is trying to convert an object into a piece of text. There is no defined result, and as such, different browsers generate different representations. To use the XML DOM node, you must use XML operations.