Back to description
From 2001 to 2005, the World Wide Web went through a tremendous growth spurt in terms of the technologies and methodologies... more
From 2001 to 2005, the World Wide Web went through a tremendous growth spurt in terms of the technologies and methodologies being used to bring this once-static medium to life. Online brochures and catalogs no longer dominated the Internet as web applications began to emerge as a significant portion of online destinations. Web applications differed from their web site ancestors in that they provided an instant service to their users, not just information. Whether for business process management or personal interests, developers were forced to create new interaction paradigms as users came to expect richer functionality.
Spurred on by little-known and lesser-used technologies that had been included in web browsers for some time, the Web took a bold step forward, shattering the traditional usage model that required a full page load every time new data or a new part of the application’s logic was accessed. Companies began to experiment with dynamic reloading of portions of web pages, transmitting only a small amount of data to the client, resulting in a faster, and arguably better, user experience.
At the forefront of this movement was Google. After the search giant went public, new experiments conducted by Google engineers began popping up through a special part of the site called Google Labs (labs.google.com). Many of the projects at Google Labs, such as Google Suggest and Google Maps, involved only a single web page that was never unloaded but was constantly updated nevertheless. These innovations, which began to bring the affordances of desktop software interfaces into the confines of the browser, were praised around the Web as ushering in a new age in web development. And indeed they did.
Numerous open source and commercial products began development to take advantage of this new web application model. These projects explained their technology using a variety of terms such as JavaScript remoting, web remote procedure calls, and dynamic updating. Soon, however, a new term would emerge.
... less
The driving force behind Ajax is the interaction between the client (web browser) and the server. Previously, the understanding... more
The driving force behind Ajax is the interaction between the client (web browser) and the server. Previously, the understanding of this communication was limited to those who developed purely on the server-side using languages such as Perl and C. Newer technologies such as ASP.NET, PHP, and JSP encouraged more of a mix of client- and server-side techniques for software engineers interested in creating web applications, but they often lacked a full understanding of all client-side technologies (such as JavaScript). Now the pendulum has swung in the other direction, and client-side developers need to understand more about server-side technology in order to create Ajax solutions.
Design patterns describe programming techniques to solve common problems. Given that programming has been around for several... more
Design patterns describe programming techniques to solve common problems. Given that programming has been around for several decades, chances are that many of the problems you face every day have already been solved by someone else. Since the mid-1990s, a lot of attention has been drawn to design patterns as a way to cut development time.
Even though the term Ajax has been around only since early 2005, the techniques that Ajax describes have been used since the late 1990s, giving rise to several Ajax patterns that solve specific problems. You’ve already seen some of these patterns in action, namely the hidden frame technique and asynchronous XHR calls. These are communication patterns between the client and server using JavaScript. As you may have expected, there are many more types of patterns.
Author and programmer Michael Mahemoff was the first to attempt to document Ajax design patterns at his web site, www.ajaxpatterns.org. The patterns presented in this chapter are a mixture of Mahemoff’s and others that your authors have identified. Note that design patterns, whether described on a web site or in a book, can never be official, only accepted. Design patterns are not standards to be followed, but merely designs of solutions that have worked previously. It is up to the development community to generate a “collective wisdom” around specific patterns; it’s up to the individual developer to decide whether to implement a given pattern in his or her own application.
With the popularity of Ajax applications exploding in 2005, developers and companies began looking for ways to streamline... more
With the popularity of Ajax applications exploding in 2005, developers and companies began looking for ways to streamline the process. As with many common programming practices, Ajax involves a lot of repetitive procedures that can be identified and simplified for common use. It wasn’t long before JavaScript developers started introducing libraries to ease the redundant and sometimes quirky behavior of Ajax communication techniques. These libraries sought to break outside of the hidden frame and XHR modalities of communication and introduce their own methods (which typically are just wrappers for already accepted forms of Ajax communication). All of the libraries discussed in this chapter use interfaces that resemble but do not mimic the techniques discussed in Chapter 2. Remember, the goals of such libraries are to free the developer from worrying about cross-browser Ajax issues by hiding the details.
Ajax applications, while powerful and user-friendly, do have some issues relating to the requests sent from the client to... more
Ajax applications, while powerful and user-friendly, do have some issues relating to the requests sent from the client to the server and the responses received back. A major concern is the number of times that communication occurs between the client and server. If the requests are initiated frequently, the server can get bogged down trying to handle requests from multiple users. Further, the client can become unresponsive while waiting for a large number of responses from the server.
Central to this problem is part of the HTTP 1.1 specification that states a client can have no more than two simultaneous connections to a single domain name at a time. While there are ways of working around this strict limitation, such as using subdomains to handle some requests, most browsers do have a maximum number of connections that can be open at a single time. When using XHR, this limitation is handled behind the scenes: you simply initiate requests as you see fit, and the browser queues them up for sending when there’s an open connection. This works fine when requests are few and far between, but when requests are being sent from various parts of an application at different times, the built-in queuing mechanism just doesn’t provide enough control over when requests are sent and what requests should be sent first. Fortunately, it’s not too difficult to implement a custom request manager that can handle more complex communication patterns.
As the popularity of XML grew, web developers wanted to use the technology on both the server and client side, but only the... more
As the popularity of XML grew, web developers wanted to use the technology on both the server and client side, but only the former initially offered XML functionality. Starting with Internet Explorer 5.0 and Mozilla 1.0 (predecessor to Firefox), Microsoft and Mozilla implemented JavaScript support for XML in their browsers. Opera 8 and Safari 1.2 introduced some basic XML support, and while Opera’s JavaScript XML support is catching up, Safari still lags behind the pack with the least amount of implemented support. With that being said, browser makers continue to broaden the availability of XML support with new features, giving web developers powerful tools akin to those formerly found only on the server.
The introduction of XML ushered in a new era of information sharing. Previously, data sharing was difficult at best as companies... more
The introduction of XML ushered in a new era of information sharing. Previously, data sharing was difficult at best as companies used proprietary transmission protocols and data formats that were unavailable to the public. The idea of transmitting information on a web site using anything other than HTML was a strange, if not unheard of, idea. But this changed in 1998 when Microsoft introduced Internet Explorer 4.0 with a new feature called Active Channels. Built upon the Microsoft-developed Channel Definition Format (CDF), Active Channels allowed web site content to be transmitted (or syndicated) to users’ desktops using the bundled Active Desktop. The problem with Active Channels, however, was its poor support for the everyday user. Anyone could make a channel from scratch, but the industry lacked tools to create and manage CDF files easily. The primary users of Active Channels, big media companies, pushed users away with excessive ads that increased the amount of bandwidth the channels used. Additionally, there was little demand for or perceived value in using Active Channels. The whole concept of syndication seemed to have died with Active Channels and the failure of CDF to reach recommendation status from the World Wide Web Consortium. Then came RSS.
With the popularity of web services around 2004, XML practically became the de facto standard for data transmission. However... more
With the popularity of web services around 2004, XML practically became the de facto standard for data transmission. However, XML is not without its detractors. Some consider it to be overly verbose for data transmission purposes, necessitating the sending of many more bytes across the Internet to accomplish what could have been done in a much smaller form. Because of this consideration, new forms of XML compression and even entirely new XML formats, such as Binary XML, have been developed. All these solutions work on extending or adding on to XML, making backward compatibility an issue. Douglas Crockford, a long-time software engineer, proposed a new data format built on JavaScript, called JavaScript Object Notation (JSON).
Earlier in the book we discussed how Ajax changed the nature of the Web by freeing users from the traditional click-and-wait... more
Earlier in the book we discussed how Ajax changed the nature of the Web by freeing users from the traditional click-and-wait paradigm. Although it improves the user experience, Ajax still uses the standard HTTP model: the client sends a request for resources to the server, which is answered by a response from the server with the requested resources (or an error message if they are not available). This is called a pull method of communication.
In the pull architecture, the client is in control. Communication begins when the client makes a request and ends when the client receives the response. The pull architecture is how the Web has always worked, but as it continues to evolve and user expectations rise, this communication method is increasingly becoming a burdensome hurdle.
Consider a typical chat client such as Yahoo! Messenger. This type of client uses a push architecture, allowing the server to push information out to the client whenever necessary. The result is fast communication because data is being sent as soon as it is available. If chat clients used a pull architecture, their performance would suffer, and there would be significantly more network traffic as the client repeatedly polled to see if new data was available. Since the nature of chat is such that new data may be available several times a second, the push architecture is much more suitable for this purpose.
Given the speed and usability advantages of push architectures, web developers have begun investigating means by which the same functionality can be realized on the Web. Ajax was just the beginning; the next step is going beyond traditional HTTP to implement push-based web systems using one or more of several new techniques. Alex Russell coined the term Comet to describe the evolving push architecture of the web (Comet is a tongue-in-cheek jab at Ajax, since both are also household cleaners).
In the beginning, there was MapQuest (www.mapquest.com), a site that allowed users to find maps and get driving directions... more
In the beginning, there was MapQuest (www.mapquest.com), a site that allowed users to find maps and get driving directions in the United States. Debuting during the dot-com era, MapQuest grew incredibly popular and even went public, being listed on the NASDAQ exchange. All of the hype caught the eye of America Online, which acquired the company in 2000. Competitive mapping sites were developed by others, most notably Yahoo! and Microsoft, but MapQuest remained the most popular site for mapping and driving directions. Mapping web sites went through iterative changes over the next few years, but for the most part, things stayed still.
When Google Maps (maps.google.com, later local.google.com) came online in 2004, it offered a revolutionary interface for the traditional web-based mapping systems. Instead of the traditional click-and-wait interaction that MapQuest and others used to pan and zoom maps, Google Maps used Ajax communication to download additional mapping info or maps at different zoom levels without reloading the page. Additionally, the ability to drag the map around instead of relying on the ubiquitous compass interface provided a truly unique user experience in the world of online mapping.
The development of Google Maps reignited interest in online mapping and the possibilities that Ajax opened for this particular usage. Yahoo!, Microsoft, and even MapQuest rushed to update their map offerings to be more competitive with Google Maps, using Ajax and other, more responsive user interface paradigms.
As with many new developments in technology, developers were immediately drawn to the new interfaces used by Google Maps and other Ajax-enabled applications. Savvy web developers reverse-engineered Google Maps, embedding its interface in their own pages as a proof of concept. Though not harmful, this occurrence opened the eyes of Google, and soon they released the Google Maps API to the public. As before, Yahoo!, Microsoft, and MapQuest each followed suit with their own Ajax-enabled mapping APIs, flooding the technology world with numerous options for embedding maps into web pages.
One of the most important parts of the software development cycle is testing. In most companies, the developers who write... more
One of the most important parts of the software development cycle is testing. In most companies, the developers who write the software are at least partially responsible for testing their code. The responsibilities vary from writing case studies for quality assurance personnel to creating and running unit tests themselves. In any case, software bugs will occur, and that is when debugging software becomes an invaluable tool.
Debuggers have come a long way since their humble beginnings. What used to be an arduous journey at a text-based console has given way to today’s graphic debuggers, complete with color-coded information to make rapid application development more, well, rapid.
For Ajax applications, debugging has historically been difficult. The mixture of JavaScript and client-server communication proved to be a unique challenge for programmers trying to bulletproof their code. More recently, however, new techniques and technologies have arisen that make debugging Ajax applications much easier.
Both on the desktop and on the Web, widgets have become a highly sought-after commodity. A widget is a small, self-contained... more
Both on the desktop and on the Web, widgets have become a highly sought-after commodity. A widget is a small, self-contained application that performs a specific function. Programs like the Yahoo! Widget Engine (http://widgets.yahoo.com/) offers users a platform to run widgets on their computers. Ranging from newsreaders to eBay feedback monitors, these widgets provide useful information to people that want them. They are applications that require little to no setup and perform only their allotted function.
On the Web, most widgets are DHTML-based and designed to emulate operating system controls such as menus, structure trees, and toolbars. While these widgets have provided a means to emulate traditional applications, they don’t offer much more than that. With the introduction of Ajax, web widgets are changing to incorporate data manipulation and retrieval, creating rich widgets that have traditionally been found only on the desktop.
Up to this point, the examples and discussions in the book have focused on writing every piece of functionality for both... more
Up to this point, the examples and discussions in the book have focused on writing every piece of functionality for both client and server. You may have noticed that there can be a fair amount of repetition between examples, code being duplicated and altered only slightly to produce a different result. It is undoubtedly innefficient for numerous developers to be writing the same code over and over again. The identifyication of these common threads in Ajax solutions has given rise to several frameworks that aim to allow rapid development of Ajax applications by freeing the developer from programming low-level communication between client and server.
The frameworks covered in this chapter are known as remote invocation frameworks, meaning that the framework is responsible for generating client-side JavaScript that abstracts out the XMLHttp communication, parameter passing, and response handling. Fortunately, there are frameworks available for each of the three major application server technologies: PHP, JSP, and ASP.NET.
As Microsoft readied the release of .NET 2.0, the software giant announced that it had begun work on project known as “Atlas... more
As Microsoft readied the release of .NET 2.0, the software giant announced that it had begun work on project known as “Atlas,” an Ajax framework built to interface seamlessly with ASP.NET 2.0. Microsoft’s original goal for Atlas was ambitious: a cross-browser framework for building Ajax-enabled applications with rich UI and connectivity to web services and/or an ASP.NET 2.0 application. Over one year later, Microsoft came close to the mark with the newly renamed ASP.NET AJAX Extensions (note that the official name of the framework has the word “AJAX” in all capital letters, as opposed to the way it is used throughout this book).
While ASP.NET AJAX Extensions contains “ASP.NET” in its name and is released to work with ASP.NET, the framework contains tools that any JavaScript developer can use. The core libraries and the Community Technology Preview (CTP) releases contain a variety of JavaScript functionality, such as an Ajax library, namespace and interface constructs, and classes that wrap DOM elements (Microsoft calls these “controls”), providing a development environment similar to what Windows developers are accustomed to.
But don’t assume that ASP.NET AJAX Extensions are strictly client side. The framework contains a variety of new .NET classes and server controls, providing developers with a simple, and seamless, interface for developing Ajax-enabled applications.
Whether you’re an ASP.NET developer or someone looking for a set of tools to aid your Ajax development, ASP.NET AJAX Extensions could be for you.
Chapter 7 covered syndication with RSS and Atom and how easy it is to share information. In order to view information from... more
Chapter 7 covered syndication with RSS and Atom and how easy it is to share information. In order to view information from several different sources, an application called an aggregator is used to combine the different feeds in one location. An aggregator makes it easier and faster to stay up to date with information collected from around the Web (much easier than visiting several web sites each day).
FooReader.NET is a web-based, .NET RSS/Atom aggregator ported from ForgetFoo’s ColdFusion-based FooReader (http://reader.forgetfoo.com/). With many conventional applications filling the aggregator void, including popular e-mail and browser applications, why build a web-based RSS/Atom aggregator? Consider the following reasons:
The Web is cross-platform. Building a web-based aggregator ensures that anyone with Internet Explorer 6+, Firefox, or Opera can access it.
The Web is centrally located. One of the problems with conventional aggregators that are installed on the computer is the upkeep of data in many locations. If you like to read syndicated feeds at work and at home, you must install an aggregator on each computer and load it with the appropriate feeds. A web-based aggregator eliminates this problem because any change made to the feed list is seen regardless of the user’s location.
This chapter explains how FooReader.NET is built using Ajax, and as with any web application, there are two main components: the client side and the server side.
If you installed a version of Visual Studio, open it and create a new web site called FooReader. Make sure that the language is C#.
One of the most popular Ajax applications is Gmail, a web-based e-mail system that incorporates a lot of Ajax techniques... more
One of the most popular Ajax applications is Gmail, a web-based e-mail system that incorporates a lot of Ajax techniques to create a seamless user experience. Gmail loads a single page and then makes changes to reflect user actions, eliminating almost entirely the “click-and-wait” experience of most web applications. There is a lot of back and forth with the server to retrieve information that the user never knows is occurring because of the system’s design. Because Gmail is an excellent example of how to build an Ajax-based web application, this chapter focuses on developing a similar application called AjaxMail.
In this chapter, you will use techniques learned throughout the book to bring AjaxMail to life. Both hidden frames and the XHR object will be used for communicating with the server, and you will be reminded when and how to use each technique. Remember, the whole point of using Ajax is to improve the user’s experience; this chapter gives you the opportunity to see first-hand how to create an application with the user in mind.
For your convenience the source code download includes the following libraries or frameworks that are discussed and used... more
For your convenience the source code download includes the following libraries or frameworks that are discussed and used in the book.
Ajax.NET Professional
DWR
JPSpan
jQuery
JSON-PHP
Prototype
YUI library
The following sections reprint the appropriate licensing information for this software.
Purchase Before purchasing this product, please be sure you have met all software and system requirements, and that you understand any limits placed upon its use.
Return Policy Wrox Chapters on Demand are non-returnable and non-refundable.
Watermarking Wrox Chapters on Demand are sold with a small unique watermark at the bottom of each page identifying the purchaser name, email address, and order number.
Reader Software Wrox Chapters on Demand are offered as PDFs, and they can be viewed using the Adobe Reader, ADE, or a compatible PDF reader. If you do not have the Reader installed, it can be downloaded for free at Adobe.com.
Test Download As Wrox Chapters on Demand purchases are non-returnable, it is advisable that you test your system and software configurations with a free sample download before you place an order.
Usage Rights for a Wrox Chapters on Demand File Any Wrox Chapters on Demand product you purchase from this site will come with certain restrictions that allow Wiley to protect the copyrights of its products. After you purchase and download this title, you:
If you have any questions about these restrictions or need any further assistance please refer to Technical Support (www.wiley.com/techsupport) or call (877) 762-2974 (8 a.m. - 5 p.m. EST, Monday - Friday).
Related Books