A for Ajax, Part 8: The XMLHttpRequest object (Part 3)

In this post we modify the XHR Library. This is now capabale of:
•  working with GET and POST requests
•  handling JSON formatted text and XML documents returned by the server
•  handling timeouts, and aborting requests

You can read the full article here.

A for Ajax, Part 8: The XMLHttpRequest object (Part 2)

Part 2: Aborting a request, caching of dynamic data, handling timeouts - some of the things we need to watch out for when using the XMLHttpRequest object

In Part 1 we saw that using the XMLHttpRequest object is easy; however there are a few things we need to watch out for.

To begin with we modify Country.htm to add a ‘refresh’ button to the country dropdown from the example in Part 1. This results in the following interface:

As in the example in Part 1, the windows.onload event calls the GetAllCountries() function which populates the country dropdown with Country data after the page has loaded. Clicking the refresh button calls the GetAllCountries() function which re-populates the country dropdown.

In this post we will discuss the following questions:
What happens if the user was to click the refresh button before the request from the windows.onload event returned?
What happens if the user was to click the refresh button indiscriminately?
How do we avoid the bad effects of such actions?
How do we cancel a request once it has been sent?
How can we ensure that dynamic data is not cached by the browser?
How can we recover if a request never returns after it has been sent?

By the end of this discussion we should have a fairly robust, reusable library to handle asynchronous GET requests through the XMLHttpRequest object.

You can read the full article here.

A for Ajax, Part 8: The XMLHttpRequest object

Part 1: Asynchronous and Synchronous requests

“The XMLHttpRequest object is a data transport object that is the core of AJAX. XMLHttpRequest was introduced in 2000, mainly to enable Microsoft Outlook Web Access to display e-mails without notification. Since then, AJAX applications have gained popularity for their ability to asynchronously exchange data with a server and then display that data without having to reload the Web page on which the data appears.” [from MSDN]

The XMLHttpRequest object establishes the communication between the browser and the server over HTTP. As the video below illustrates, it is possible to setup multiple simultaneous requests bringing about a huge improvement in user experience.

In a serious Ajax based web application, you will probably be using an established javascript library, such as jQuery, which will abstract the use of the XMLHttpRequest object in efficient cross browser capable methods.

In this, and in subsequent posts, we will examine the nitty gritty of the XMLHttpRequest object.

You can read this article online here.

Code download:
You can download the example code here. This code helps you to test out the XMLHttpRequest object in an asynchronous mode. The article has details on how to set up the application.

Download the full video here [XMLHttpExample_FullVideo.rar, 384 KB] or here [XMLHttpExample_FullVideo.zip, 4.4 MB].

A for Ajax, Part 7: DOM Events

Events make a web page interactive.

Most events occur when a user interacts with the UI – for example, when a user selects a value from the dropdown list; there are others that occur due to programmatic processing of the document – for example, the load event is raised when the document fully loads in the browser.

The W3C Working Draft and the W3C Recommendation describe an event model around the following:
1. an event object: this contains contextual information about the event.
2. an event target: this is the element on which the event occurs.
3. an event listener: this implements a function that knows how to respond to an event when it occurs on the target.
4. the life cycle of the event object through its capture, target and bubble phases.

The IE model describes a similar model:
1. an event object: this contains contextual information about the event.
2. a source element: this is the element on which the event occurs.
3. an event handler: this is a function that knows how to respond to an event when it occurs on the source element.
4. the life cycle of the event object through its target and bubble phases.

You can read this article online here.

Code download:
You can download the DOMEvents.zip here. This code describes the events discussed in this article in more detail.
You can download the DOMNavigation_Enhanced.zip here. The tree representation of the DOM from the last post can now be collapsed/expanded using events.

A for Ajax, Part 6: The Document Object Model [DOM]

What is the DOM?
The W3C Recommendation defines it as: “The Document Object Model (DOM) is an application programming interface (API) for valid HTML and well-formed XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. In the DOM specification, the term "document" is used in the broad sense - increasingly, XML is being used as a way of representing many different kinds of information that may be stored in diverse systems, and much of this would traditionally be seen as data rather than as documents. Nevertheless, XML presents this data as documents, and the DOM may be used to manage this data.”

What can be done with the DOM?
From the W3C Recommendation: “With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model, with a few exceptions..”

You can read the article online here.

Code download
You can download the DOMNavigation.zip here. The JavaScript code has examples of:
-navigating and manipulating the DOM
-object detection
-a way to create a tree representation of the DOM. We will improve upon this code in our next post on DOM events

A for Ajax, Part 5: Object Oriented JavaScript, JavaScript libraries

JavaScript is the glue that makes Ajax work. It is the only language through which we can create Ajax enabled front-ends.

As ASP.NET developers, our approach when we need to use JavaScript in our applications is to ‘Google, copy and paste’, with some modifications, if required. But Ajax enabled web applications are serious applications and require a much better understanding of the language.

Ray Djajadinata in Create Advanced Web Applications With Object-Oriented Techniques writes: “Indeed, until recently, I’d always been able to get by with whatever little JavaScript I knew, armed only with the MSDN DHTML reference and my C++/C# experience. It was only when I started working on real-world AJAX applications that I realized how inadequate my JavaScript actually was. The complexity and interactivity of this new generation of Web applications requires a totally different approach to writing JavaScript code. These are serious JavaScript applications! The way we’ve been writing our throwaway scripts simply doesn’t cut it anymore.”

And continues: “I didn’t learn JavaScript of my own volition. I had to pick it up quickly because I realized that I was ill-prepared to work on a real-world AJAX application without it. At first, I felt like I had gone down a few levels in the programmer hierarchy. (JavaScript! What would my C++ friends say?) But once I got over my initial resistance, I realized that JavaScript was actually a powerful, expressive, and compact language. It even boasts features that other, more popular languages are only beginning to support.”

JavaScript’s object-oriented approach is different then a conventional object-oriented language such as C#. However it brings to your applications the same advantages you derive from a conventional OO language. OO Javascript may seem quirky at first, but as you get up to speed, you begin to appreciate its awesome power. You also realise the discipline required so you don’t abuse its power.

For complex projects, it is best to use a JavaScript library. JavaScript libraries extend Javascript to make it even more powerful. A few examples:
• ExtJS provides you with an excellent collection of controls for the front end.
• Microsoft’s Ajax Library extends JavaScript “objects to give them the richness of .NET Framework classes”.
• jQuery is important for ASP.NET developers if only because Mirosoft will be using it in a big way in ASP.NET 4.0.

For those on the ASP.NET platform, knowing how to use the Microsoft’s Ajax Library and JQuery would certainly be an asset.

Further reading
General:
JavaScript
A re-introduction to JavaScript
Code Conventions for the JavaScript Programming Language

Microsoft:
Microsoft AJAX Library namespaces
jQuery and Microsoft

Books
JavaScript:
David Flanagan, JavaScript: The Definitive Guide, 5th Edition, Wiley Publishing, Inc., ISBN-13: 978-0596101992
Douglas Crockford, JavaScript: The Good Parts, O'Reilly Media, Inc., ISBN-13: 978-0596517748
Stoyan Stefanov, Object-Oriented JavaScript, Packt Publishing Ltd., ISBN-13: 978-1847194145
Ross Harmes and Dustin Diaz, Pro JavaScript Design Patterns, Apress, ISBN-13: 978-1590599082

jQuery:
Bear Bibeault and Yehuda Katz, jQuery in Action, Manning Publications, ISBN-13: 978-1933988351
Jonathan Chaffer andKarl Swedberg, Learning jQuery, Packt Publishing Ltd., ISBN-13: 978-1847192509
Jonathan Chaffer andKarl Swedberg, jQuery Reference Guide, Packt Publishing Ltd., ISBN-13: 978-1847193810

ExtJS:
Shea Frederick, Colin Ramsay and Steve 'Cutter' Blades, Learning Ext JS, Packt Publishing Ltd., ISBN-13: 978-1847195142

Video links (from Mix 11):
Mix 11

A for Ajax, Part 4: The technologies and practices an Ajax enabled web application developer must know

To create an effective Ajax enabled application, a developer needs to have a good understanding of a number of front-end and back-end technologies and performance related best practices. In a series of future posts, I will cover some of these. This post is more of a road map to those future posts.

Front-end:
Jesse James Garrett of Adaptive Path coined the word ‘Ajax’: “Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:
• standards-based presentation using XHTML and CSS;
• dynamic display and interaction using the Document Object Model;
• data interchange and manipulation using XML and XSLT;
• asynchronous data retrieval using XMLHttpRequest;
• and JavaScript binding everything together.”

In future posts we will look at these technologies in some detail, probably in the following order:
JavaScript and libraries
DOM
XMLHttpRequest object and how to handle XML and JSON data formats
XHTML and CSS

Front-end Best Practices:
Separating Content, Style and Behavior
This is also known as Separating HTML, CSS, and Javascript. In a forum I found this question: “..Why should i keep JavaScript code out of the HTML code? I asked someone else and he told me "1. separation of concerns. 2. don't have to worry about breaking attributes 3. not all events have attributes 4. works better with custom events and delegation." Why should i care about any of those things?..”

We will look at this in more detail in a later post and try to answer the ‘why should I care’ question.

Usability
Ajax enabled web applications break the way we use the Back/Forward buttons and Bookmarks. Most JavaScript libraries now have support to overcome this usability issue; developers need to code this into the application. For situations where this support is not available we could use one of the following libraries:
Really Simple History (RSH): Ajax history and bookmarking library
Yahoo! UI Library: Browser History Manager

Validate the XHTML, CSS and Javascript
It is always a good practice [http://validator.w3.org/docs/why.html] to validate the XHTML, CSS before we go into production.
You can validate the markup of the XHTML document at http://validator.w3.org/#validate_by_input.
You can validate the CSS at http://jigsaw.w3.org/css-validator/#validate_by_input.

You can validate JavaScript code using the JSLint JavaScript Verifier tool at http://www.jslint.com/. Douglas Crockford, the author of this tool writes: “JavaScript is a young-for-its-age language. It was originally intended to do small tasks in webpages, tasks for which Java was too heavy and clumsy. But JavaScript is a very capable language, and it is now being used in larger projects. Many of the features that were intended to make the language easy to use are troublesome for larger projects. … JavaScript is a sloppy language, but inside it there is an elegant, better language. JSLint helps you to program in that better language and to avoid most of the slop.”

Front-end Performance:
In an Ajax enabled web application project I was involved in, the client described the performance of the application as “scary fast in Firefox and Chrome, and much faster than usual in IE”. In later posts I will share some of the important aspects for improving performance, such as:
• Tools to monitor HTTP traffic
• Minification of CSS and Javascript
• IIS settings to increase performance

Back-end:
Ajax enabled web applications are more often than not, datacentic applications. As .NET developers we need to know how to convert the data to a JSON format before it is passed to the front-end. The .NET framework has several ways to do this. In future posts we will explore areas such as:
• Converting data to JSON format in C#.
• Communication with the database, in particular LINQ to SQL and the ADO.NET Entity Framework.
• Communication between the front-end and back-end.

A for Ajax, Part 3: Accessibility

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” Sir Tim Berners-Lee

In Part 1 and 2, I reasoned why and how an Ajax enabled web application performs better than an application built the traditional way. So should we Ajax enable all our web applications? The answer is no.

A serious issue with Ajax enabled web applications is that of accessibility by persons with disabilities.

Most of the discussion center on visually impaired users who have embraced “the power of the web” through assistive technologies such as screen magnifiers and screen readers. The problem arises from the inability of Ajax enabled web applications to effectively communicate to assistive technology, especially screen readers, that a part of the page has been updated, and allow users to easily investigate those changes.

These articles detail the problem:
AJAX Accessibility Overview
AJAX and Screen Readers - Content Access Issues

James Edwards, presenting his findings on how screen readers dealt with Ajax enabled web applications [http://www.sitepoint.com/article/ajax-screenreaders-work], remarks: “I’m forced to conclude that, unless a way can be found to notify screen readers of updated content, Ajax techniques cannot be considered accessible, and should not be used on a production site without a truly equivalent nonscript alternative being offered to users up-front.”

In 2006, Freedom Scientific, the developers of JAWS, a widely used screen reader indicated that version 7.1 of the software would be designed to work with Ajax based applications:
Developers Working to Overcome AJAX Accessibility Issues

This 2007 article indicates that, though some improvements have been made, the current level of support for Ajax in screen readers leaves a lot to be desired:
Improving Ajax applications for JAWS users

With Ajax pushing the boundaries of technology on the Web, and screen readers still stuck on outdated technology, it is very frustrating for the innovative developer.

However, there are other areas of accessibility where the developer can be more attentive to his users: think of people with learning/cognitive disabilities, for example, people who can’t use a mouse: did you provide them with an alternative to that cool drag and drop feature? Do you really require that drag and drop feature?

Some initiatives are underway: Charles L. Chen and T.V Raman has come up with a JavaScript framework - AxsJAX - for enhancing the accessibility of AJAX applications. “The AxsJAX framework helps inject accessibility features into these applications so that users of adaptive technologies such as screen readers and self-voicing browsers experience the same level of interactivity that is now taken for granted by users of Web 2.0 applications.”

The W3C has begun working on a standard that “defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.” This standard is currently a working draft. It will be a while before this is a recommendation, and developers and manufacturers of assistive technology understand and implement it.

Till then, if we have to develop a web application where accessibility is mandated, it is best to go the traditional route.

Further reading:
Accessibility Links
IBM Human Ability and Accessibility Center
Microsoft

Firefox extensions:
Fire Vox: a cross-platform self-voicing extension that includes early support for most of the leading edge features of W3C ARIA
Fangs: a screen reader emulator

A for Ajax, PART 2: Some data to substantiate claims made in Part 1

In Part 1 we discussed that an Ajax enabled application will perform better than a traditional web application. In this post we substantiate this claim with some data.

We compare a web application built the traditional way, in ASP.NET 3.0, with the same application built the AJAX way. Both application fetch data from the Northwind database using the same stored procedures. All the stored procedures have a wait period of 1 second to simulate delay.

We use Fiddler and Firebug to monitor the HTTP traffic, and the Web Application Stress Tool to load the sites with concurrent requests, and examine some of the data generated.

You can read the entire document here [http://docs.google.com/Doc?id=dcggqmtv_36c2tjrqg4].

The source code of the example applications, the Fiddler data used in this post, can be found here. The code is in C#, targets the .NET 3.5 Framework and developed using VS2008 SP1. The Northwind database is included in the download, you can either copy it to the App_Data folder of the applications, or attach them to SQL Server 2005. Rememeber to change to the appropriate connection string in the web.config.

A for Ajax, Part 1: Expectations from Ajax enabled web applications

Many of today’s web applications are Ajax enabled. What are our expectations from an Ajax enabled web application vis-à-vis traditional web applications?

Traditional page-based web applications process every request entirely on the server and sends across a HTML response that is rendered on the browser of the client machine. The HTML will contain the content [the HTML markup] and data. Refer Figure 1.














Figure 1: The traditional request-response web application architecture [please click the image for a larger view]

This request-response strategy is characterized by:
• high end server hardware.
• a browser on the client machine acting as a dumb terminal.
• complicated state management.
• the user waiting for a response after every request because of the synchronous nature of the request-response operation.

Considering that client machines are quite powerful nowadays, it makes sense to move part of the processing from the server to the client. This is the strategy followed in Ajax enabled web applications. The immediate gain is that this frees server resources, allowing the same server hardware to service more client requests concurrently. Ajax enabled web applications scale better than the traditional applications.

In an Ajax enabled web application, the only time the server processes a request entirely on the server is when the page is loaded the first time. This is the only time that the server serves content and maybe some data. For subsequent requests it serves only raw data, encoded in a given format. The client receives data feeds and updates only the parts of the Web page that have changed using JavaScript. In Ajax enabled web applications, UI updates take effect without postback. Refer Figure 2.















Figure 2: The Ajax enabled web application architecture [please click the image for a larger view]

Since only raw data is served, the size of the data is much smaller than what would be served by a traditional web application. This speeds up individual request and response, resulting in reduced network traffic and bandwidth requirements. Ajax enabled web applications are faster than the traditional applications.

By default the request-response strategy of an Ajax enabled web application is asynchronous in nature. This means that the user can continue to use the application while the client requests information from the server in the background and updates the UI [think Google Map]. Ajax enabled web applications are more responsive than the traditional applications.

In Ajax enabled web applications UI processing happens at the client. This makes it possible to achieve rich functionalities such as drag and drop, auto-completion, smooth animation, client side calculation, validation, etc. JavaScript libraries, such as ExtJS, bring in more sophistication to the UI. Ajax enabled web applications result in a rich user experience.

In summary, Ajax enabled web applications [with respect to traditional web applications] can be expected to:
1. scale better
2. have better overall performance
3. result in a richer user experience