| By Vishwas Lele |
Article Rating: |
|
| June 1, 2006 11:45 AM EDT |
Reads: |
145,185 |
In the past few months, the design pattern of combining Asynchronous JavaScript and XML (AJAX) to develop highly interactive Web applications has been growing in popularity. High-profile Web applications such as Google Maps and A9 are currently leveraging the combination of these technologies to produce rich client-side user experiences. The individual technologies that compose AJAX are not recent developments; they have been around for some time and have been continuously updated and improved. However, it is the recent confluence of these technologies that is leading to interesting possibilities.
I have three goals in this article. First, I want to provide a high-level overview of AJAX-style applications. My second goal is to provide a detailed description of asynchronous callback features of ASP.NET 2.0. Finally, I want to provide an insight into upcoming enhancements of tools and frameworks for building AJAX-style applications.
AJAX-style Web applications exhibit the following characteristics:
- Asynchronous requests made to the Web server. The browser user interface is not blocked while waiting for a response from the Web server. The browser can continue to respond to user interaction while awaiting a server response.
- High dependence on browser-based logic written in JavaScript. Recent enhancements to and standardization of the W3C DOM provide support for dynamic client-side updates to UI.
- Exchange of nonpresentation XML-based data between the browser and the Web server. The XMLHttp object makes it possible to communicate with the Web server without the need to reload the page.
The big difference between an AJAX application and a traditional Web application is that every user interaction does not result in an HTTP request being sent to the Web server. Instead, browser-based logic implemented in JavaScript receives control that, in turn, decides whether to handle the request locally or to make an asynchronous call to the server. Upon the completion of the asynchronous call to the server, the client-side logic appropriately updates the relevant sections of the UI. This approach provides the following benefits:
- The user experience is richer. For example, when a Google map user drags the map in one direction, an asynchronous request is made to the server in the background, to continue to fetch tiles beyond the edge of the screen. This way when the user drags the map further, the new image is readily available. This creates a perception of a speedier response.
- Since the state is not lost across XMLHttp-based calls to the server, AJAX applications can avoid rerendering the UI widgets each time.
- More logic residing in the browser reduces the number of roundtrips to the Web server, thereby improving the overall latency of the system.
For all the pros, AJAX-style applications have a number of cons associated with them as well. AJAX-style development is difficult because of the absence of framework (a collection of UI classes similar to the MFC toolkit for Windows) and IDE support (i.e., debugging, visual designers, etc.). One has to know at least two languages well (DHTML and JavaScript). Further, AJAX-style applications take longer to code because of the additional testing required to support multiple browser versions and types. Finally, as the JavaScript-based source is accessible to the end user, threat analysis becomes very important.
Fortunately, the arrival of things such as Atlas, AJAX.NET, and the Google Maps API etc. is a sign of better support for building AJAX-style applications in the future. In the next section, we will look into how the support for building AJAX applications is evolving over time and what to expect from the newly announced toolkits such as Atlas.
Let's start with the XMLHttp object, which was introduced by Microsoft and later implemented on other platforms including Mozilla and Apple's Safari browser. XMLHttp enables asynchronous requests to the Web server, which allows Javascript- based logic on the client to call the Web server without the need to reload the page.
In other words, it is possible to have interaction with the Web server in the background without causing a page reload - a side effect of the exchange between the browser and the Web server.
Using the XMLHttp object is straightforward. For the sake of simplicity, let's just consider IE specific syntax. The syntax for XMLHttp implementations on other browsers is similar.
request = new ActiveXObject("Microsoft.XMLHTTP");
if (request)
{
request.onreadystatechange = CallbackHandler;
request.open("GET", URL, true);
request.send();
}
function CallbackHandler()
{
if ((request.readyState == 4) && (request.status == 200)
{
string response = request.responseXML;
// Update the relevant sections of the UI
}
}
In the code snippet shown above, the first step is to instantiate the Microsoft.XMLHttp class. Next, we set the properties on the XMLHttp instance we just created, including the address of callback function that will get control when the XMLHttp request is complete. The callback function address is needed because we are making asynchronous calls to the server (an intent conveyed by setting the third parameter on the open method call to true). Inside the implementation for the callback function, we make additional checks to make sure that the request is complete.
Subscribe to Eclipse Developer's Journal Email News Alerts
Subscribe via RSS
