Chapter One
Overview of AJAX
AJAX has definitely been the hot buzzword in the Web application world for the last few years. AJAX is an acronym for Asynchronous JavaScript and XML and, in Web application development, it signifies the capability to build applications that make use of the XMLHttpRequest object.
The creation and inclusion of the XMLHttpRequest object in JavaScript and the fact that most upper-level browsers support it led to the creation of the AJAX model. AJAX applications, although they have been around for a few years, gained popularity after Google released a number of notable, AJAX-enabled applications such as Google Maps and Google Suggest. These applications demonstrated to the world the real value of AJAX, and every developer that saw these applications in action immediately went out to do research in how these applications were built.
AJAX is now an out-of-the-box feature of ASP.NET 3.5, and every ASP.NET application that you build is AJAX-enabled by default. This means that you don''t have to create a separate AJAX project for your Web applications as the standard projects in Visual Studio for Web application development will already be enabled to use ASP.NET AJAX. This is one of the main new features of ASP.NET 3.5 because of the power that AJAX brings to your applications. The AJAX capability has become so popular since the release of ASP.NET 3.5 that most ASP.NET applications built today make use of at least some features provided by this technology.
Why AJAX Applications Are Needed
Web applications were in a rather stagnant state for many years. The first "Web" applications were nothing more than text and some images, all represented in basic HTML tags. However, this wasn''t what people wanted; they wanted more - more interactivity, a more integrated workflow, more responsiveness, and an overall richer experience.
When building applications, even today, you have to make some specific decisions that really end up dictating the capabilities and reach of your application. Probably one of the more important decisions is the choice of building the application as a "thin" client or a "thick" client.
A thick client application is a term used for applications that are either MFC (in the C++ world) or Windows Forms applications. These types of applications also provide the container along with all the container contents and workflows. A thick client application is typically a compiled executable that end users can run in the confines of their own environment, usually without any dependencies elsewhere (for example, from an upstream server).
A thin client application is the term generally used for Web applications. These types of applications are typically viewed in a browser, and your application can provide end user workflows as long as it is contained within this well-known container. A thin client application is one whose processing and rendering are controlled at a single point (the upstream server), and the results of the view are sent down as HTML to a browser to be viewed by the client.
Typically, a Web application is something that requires the end user to have Internet access in order to work with the application. On the other hand, a thick client application was once generally considered a self-contained application that worked entirely locally on the client''s machine. However, in the last few years, this perception has changed as thick clients have evolved into what are termed "smart clients" and now make use of the Internet to display data and to provide workflows.
Web applications have historically been less rich and responsive than desktop applications. End users don''t necessarily understand the details of how an application works, but they know that interacting with a Web site in the browser is distinctly different from using an application installed locally. Web applications are accessible from just about any browser, just about anywhere, but what these browsers present is limited by what you can do with markup and script code running in the browser.
There are definitely pros and cons in working with either type of application. The thick client application style is touted as more fluid and more responsive to an end user''s actions. Thick client applications require that users perform an installation on their machine but let developers leverage the advanced mouse and graphics capabilities of the operating system that would be extremely difficult to implement in a Web browser, and also take advantage of the user''s machine for tasks such as offline storage.
Conversely, the main complaint about Web applications for many years has been that every action by an end user typically takes numerous seconds and results in a jerky page refresh.
Conversely, Web applications can be updated just by changing what is running on the server, and site visitors get the latest version of that application instantaneously. However, it is much more difficult to update a desktop application, because you would have to get users to perform yet another installation or else ensure that the application has been coded to include a clever system for doing updates automatically.
Web applications are said to use a zero-deployment model, but desktop applications use a heavy deployment and configuration model. The choice is often characterized as a tradeoff between rich and reach: Desktop applications generally offer a richer user experience than what could be offered in the browser, but with a Web application you are able to reach users anywhere on any OS with almost no extra effort. Furthermore, many companies have restrictive policies in place regarding what software can be installed on employees'' machines, and they often don''t allow employees to have administrative access that is required to install new applications, so Web applications are the only viable option in many situations.
AJAX is the first real leap of a technology to bridge this historic wall between thick and thin. AJAX, though still working through the browser, focuses on bringing richness to Web applications by allowing for extremely interactive workflows that usually were only found in the thick client camp.
Bringing Richness to Web Applications
Years ago, having a Web presence was a distinguishing factor for companies. That is no longer the case. Now just having a Web presence is no longer enough. Companies are distinguishing themselves further through Web applications that react intuitively to customer actions and anticipate user input. This book shows you how ASP.NET AJAX addresses specific Web development challenges and paves the way for taking your Web site to another level of user experience.
The fundamental set of technologies used in the AJAX model that enable the next generation of Web applications is not entirely new. You will find that many people point to Google, Flickr, and several other services as prime examples of leveraging AJAX and its underlying technologies in unique ways. The applications have some unique features, but in reality, the underlying technologies have been around and in use for nearly a decade. Look at how Microsoft Exchange Server provided rich access to e-mail from a Web browser in the Outlook Web Access application, and the concept of ubiquitous access from a browser while leveraging a common set of browser features for a rich user experience has been around for years. In this case, users get a remarkably full-featured application with no local installation and are able to access e-mail from virtually any machine.
While the AJAX acronym is nice, it doesn''t do much to explain what is actually happening. Instead of building a Web application to be just a series of page views and postbacks, developers are using JavaScript to communicate asynchronously with the Web server and update parts of the page dynamically. This means that the Web page can dynamically adapt its appearance as the user interacts with it, and it can even post or fetch data to or from the Web server in the background. Gone are the days of the ugly post-back, which clears the user''s screen and breaks his concentration! Instead, you need to post back now only if you want to change to a different Web page.
Even that rule can be bent. Some applications are pushing this boundary and completely changing the user''s view, just as though they navigated to a new page, but they do so through an asynchronous post and by changing the page content without actually navigating to a new URL.
The AJAX acronym refers to XML as the data format being exchanged between client and server, but in reality, applications are being built that retrieve simple pieces of text, XML, and JSON (JavaScript Object Notation) (which is discussed in more detail in Chapter 4). Part of the AJAX appeal is not even covered by the acronym alone: In addition, to communicating with the server without blocking, developers are leveraging Dynamic HTML (DHTML) and Cascading Style Sheets (CSS) to create truly amazing user interfaces. JavaScript code running on the client communicates asynchronously with the server and then uses DHTML to dynamically modify the page, which supports rich animations, transitions, and updates to the content while the user continues interacting with the page. In many cases, end users will sometimes forget they are using a Web application!
Just remember that AJAX is not a single holistic entity but instead is a novel and creative way of using a combination of technologies such as the XMLHttpRequest object, HTML, XHTML, CSS, DOM, XML, JSON, XSLT, and JavaScript. You might be thinking of the difficulties of piecing this all together to get the Web applications you want to build. Be ready to be wowed, however, as the focus of this book is on showing you how to use the built-in technologies provided by ASP.NET 3.5 to give you this power in an easy to use manner.
Who Benefits from AJAX?
AJAX offers benefits to both end users and developers. For end users, it reduces the "rich or reach" conflict; for developers, it helps in overcoming the constraints raised by HTTP such as the dreaded page postback.
Why End Users Want AJAX Applications
Users tend to view desktop applications as a commitment. They install a program, usually from a disk pulled from a costly shrink-wrapped box. The program consumes hard disk space as well as a position in the program menu. The user may need to update the program periodically or perform an upgrade later on to get new features. If the program is proactive about updating itself, the user is confronted regularly with dialogs about accepting patches or downloads. In exchange for this investment of time, money, and energy, the user is repaid with an application that is able to leverage the operating system and machine resources. It is a rich application. It has local storage capabilities, offers quick response times, and can present a compelling and intuitive graphical user interface.
More and more applications are becoming accessible from the Web browser, where the full resources of the hardware and OS are not available, but the user commitment of a desktop application is not required. Over the years, interacting with a Web application has meant a predictable pattern for users. They click a link in the page, and the browser flashes while the user waits until the page is repainted (the dreaded page postback). This cycle is repeated over and over. The user looks at what is presented on the page, interacts with it, and clicks somewhere on the page. The browser then produces an audible click for feedback and begins to postback to the server. The screen of the Web browser flashes blank and some icon spins or flashes while the user waits for a new version of the page to be returned from the server. Many times, the new version of the page is almost exactly the same as the previous version, with only part of the page being updated. And then the cycle begins all over again. This has a sluggish feeling even when the user has a high-speed network connection and is simply unacceptable for some types of applications.
The AJAX set of technologies has changed what users expect from Web applications. JavaScript code running in the browser works to exchange data with the Web server asynchronously. There is no click sound and the browser does not flash. The request to the server is non-blocking, which means the user is able to continue viewing the page and interacting with it. The script gets the updated data from the server and modifies the page dynamically, using the DHTML coding methodology. The user is able to continue looking at the page while parts of it are updated in the background. AJAX is used to provide a more responsive experience, making Web applications behave more like desktop installations. JavaScript is used to provide a richer experience with support for drag-and-drop, modal dialogs, and seemingly instantaneous updates to various parts of the page based on user inputs.
A big part of successfully leveraging AJAX technologies is in the perceived performance increase. Users appreciate Web applications that anticipate their actions. If you also use JavaScript code in the background to pre-fetch images and data that may be needed, users can get a speedy response without the usual pause that accompanies their actions. Nobody wants to wait for data exchanges between client and server; studies have shown that a time lag between user input and subsequent UI changes can significantly reduce their productivity and give them the frustrating feeling that they are fighting the application. Users want Web applications to behave like desktop installations but without the overhead associated with an installation. As more applications employ smart caching, anticipate user actions, and provide richer UIs, the difference between Web and desktop applications is definitely becoming blurred. Expectations for Web applications are rising. The end user has now seen that it is possible to avoid the commitment of installing a desktop application and still have a rich and responsive experience.
Why Developers Want AJAX
Often, the first question to arise when starting a new development project is what type of application it will be. Should it be a desktop application or a Web application? This is a key decision because it has historically dictated a lot about the nature of the application and the development problem space. Many developers are now choosing to build Web applications by default unless something about the application dictates that it must be a desktop install. If it must run offline or if it requires a user interface that is too complex to achieve in HTML, targeting the Web browser may be ruled out, and developers are forced to write a standalone application.
Developers have a difficult job writing modern Web applications due to the inherent World Wide Web functionality constraints imposed by the use of the Hypertext Transfer Protocol (HTTP) and the way that browsers use it. HTTP is a stateless protocol. The Web browser requests a page, possibly carrying some sort of state (a querystring or form input parameters), and the Web server processes the request and sends a response that includes HTML-rendered content. The Web server can only react to the information supplied in the current request and does not know any additional information from the request itself, such as any details about the path the user took to get to the current view.
When the response is rendered, the connection may be broken and the server will not have any information to preserve for the next request. From the server''s perspective, it is simply listening for requests to come in from any browser anywhere and then reacting. The browser issues a request to the page and receives an HTML page in response. It uses the HTML it receives to render the user interface. The user interacts with the page, and, in response, the browser clears the screen and submits a new request to the server, carrying some information about user input or actions. Again, a complete HTML page is returned. The browser then presents the new version of HTML. Fundamentally, the HTTP protocol is stateless. The server gets a request and responds to it. The request carries limited information about the ongoing conversation that is happening between client and server. This can definitely be a problem.
(Continues...)
Excerpted from Professional ASP.NET 3.5 AJAXby Bill Evjen Matt Gibbs Dan Wahlin Dave Reed Copyright © 2009 by Bill Evjen, Matt Gibbs, Dan Wahlin and Dave Reed. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
