Introduction

ASP.NET AJAX is the newest addition to ASP.NET 2.0 and is a supported Microsoft framework for next -generation Web development using AJAX technologies. AJAX is shorthand for “Asynchronous JavaScript + XML,” an approach to Web applications that utilizes asynchronous data requests from the page with a client-side JavaScript engine. It is not one technology, but rather a combination of technologies that enables rich-client responsiveness in the browser when used together. It’s also not a new technology, but rather a new trend that combines old technologies in a new way. The technologies include object-oriented JavaScript, asynchronous data requests utilizing the XMLHttpRequest object, XML data streams, Extensible Stylesheet Language Transformation (XSLT) transforms, and dynamic manipulation of the HTML Document Object Model (DOM). It more closely resembles a recipe for Web applications than a single architecture-it is an approach to Web applications based on rendering and manipulating data in smaller components during the page’s life cycle in response to user actions on the client rather than the processing of the entire page as a whole. Because of this design pattern, Web Parts make an excellent deployment mechanism for AJAX components in Microsoft Windows SharePoint Services (WSS), and many of the built-in WSS APIs can be leveraged in JavaScript code from the browser.

The main benefit of using AJAX techniques in Web applications is an increased level of responsiveness once possible only in rich-client applications. Instead of waiting for a page reload or form post to update the user interface, the browser can send a discrete call to the server by using the XmlHttpRequest object while enabling the user to continue working.

A callback method on the client is then used to handle the Web request when it is completed. Compared to traditional applications, AJAX applications typically make smaller and more frequent data requests, loading data as needed rather than performing large data transfers up front. Figure 5-1 displays the traditional WSS page life cycle, in which the entire page is reprocessed as the user interacts with the data. In this traditional model, the page is requested and sent to the client as a whole. Upon page refresh, all required data must be reprocessed and resent , making data manipulations and navigation a disruptive activity. If multiple Web Parts exist on the page, each Web Part must be refreshed during the page request/response cycle. There is also significant overhead in the WSS page itself that would ideally be processed only once per user context rather than on each user interaction.

Figure 5-1: The traditional WSS Web page life cycle