Ajax Tutorial Objectives:
• Review HTTP request/response paradigm
• Discuss motivation for new paradigm
• Learn the distinctive combination of tools comprising Ajax
• See an Ajax example in action
• Briefly discuss web standards
• Get an overview of the parts that make up Ajax
• Define terms making up the acronym soup surrounding Ajax
• Cover the basic rules for well-formed XML and learn the syntax for Namespaces in XML
• Discuss XHTML and how it differs from HTML
• Discuss alternatives to common Ajax component technologies that fill the same space
• Get an overview on the future of HTML forms, XForms
The existing web paradigm requires round-tripping to the server for most common tasks. This request and
response paradigm is the reason web applications have distinct behavioral differences compared to their non-
web-enabled brethren. The ubiquity of web browsers, combined with the variety of server side environment
choices, provides reason for building applications to run on the web. Bandwidth availability and speed, server
load, full page refresh, and navigational limitations are some of the negatives assumed to “come with the
Ajax is a new term for a combination of tools that give new way of building user responsive web applications.
It alleviates the drawbacks, while losing none of the benefits. Simply put, the technologies of Ajax allow for
applications to move away from single large, request/response pairs and go towards communicating smaller
packets of data. Ajax allows for refreshing parts of a page, rather than the whole which gives more user-
responsiveness and design options for the user interface.
Existing Web Paradigm
The fundamentals of web technologies include several parts.
- HTTP, the network protocol for sending and receiving data
- HTML, the language of web pages providing basic layout, linking and formatting
- The web server, which allows for sophisticated functionality such as database connectivity,
session and application state management, complex logic and computations, etc.
- The web browser, acting as a container for the HTML and intermediary capable of sending and
receiving via HTTP protocol
The HTTP is used to send and receive “resources”. Resources may be HTML pages, images, files, plain text,
XML, etc. Most resources are files or output from the execution of some server-side code, i.e. ASP, CGI or
HTTP is a client/server model. The most typical client is a web browser. Web servers have several
components. An example server may be IBM hardware, Microsoft OS and server software, and a server-side
code execution environment such as ASP. The two partners, client and server, communicate using the HTTP
The typical web browser behavior has several noticeable manifestations. The new location, or URL, is
displayed within the browser’s address line. The window area refreshes, or completely loads the resource
acquired from the server response. Browsers have some interesting “eye candy” that may change to reflect
the new loaded resource, such as the title bar or status. The back and forward buttons may be enabled or
There may additionally be some less obvious changes. A cookie may be created, deleted or modified.
Resources, such as images, may be added to the client side cache. The previous location, or URL, is added to
the browser’s history collection.
This web behavior creates a sense of navigating, or moving throughout the web space.
- A user may be submitting a form with registration data.
- A user may be clicking links, moving about within some brochure or browsing through topical
What’s the Problem?
Client applications allow the designer to create interfaces that are comfortable, and highly responsive to user
input and interaction.
Users become accustomed to familiar and responsive user interface behaviors. A menu is full of useful tools,
some common to most applications and some unique to a given application. Selection of items in a user
interface, like choosing an item in the left tree/folder view initiates a scroll through the preview window on the
right side. Items become grayed out, or made inactive based on items selected, or highlighted by the user.
User interface changes are nearly always instantaneous, providing an obvious connection between the user’s
action and the application’s reaction. Web application response times are much slower. Loading the full
browser window, rather than selected areas, eliminates the clear association with action and reaction. This full
page load also is more jarring to the user, without smoothness or continuity that comes with selected area
Slowly Evolving Improvements
The mid to late 1990’s were busy and competitive years in the web browser markets. Circa 1997, Netscape
Navigator and Internet Explorer browsers version 4, introduced support for CSS. Also, circa 1997, the two
Web developers began taking advantage of those techniques to improve client side user interactivity. The
browser itself has a document object model, DOM, allowing for programmatic access to various browser
language of choice for adding functionality on the client side. Cascading Style Sheets, CSS, provide the ability
to associate colors, sizes, position, etc. for the browser elements.
However, DHTML failed to gain traction due to a number of factors:
- Only supported in version 4 of browsers, making it impractical for production use due to
prevalence of older browsers.
- Incomplete and incompatible support for CSS between the two main browsers limited what could
be done with it.
- DOM differences between the browsers were irritating and added complexity.
So, DHTML was declared dead and was soon forgotten… or was it?
A Little Thing Called XML…
While the browser war raged, the next generation markup language, XML, was being developed. XML was
recognized immediately by both Microsoft and Netscape as being important. Both browsers provided some
form of XML support: IE in version 3 and Netscape in version 4.
Microsoft’s XML support was in the form of a COM component, MSXML. Component is installed when
the browser is installed. Component also installed with Windows OS itself. Later MSXML versions were
installed with products such as SQL Server and BizTalk Server.
At this time, several XML standards were still under development and had not yet fully baked.
- XSLT: Transformation of XML
- XSD: Schema language for defining XML structure
- XPath: Part of XSL whereby nodes in an XML tree are selected/identified/located
These early MSXML parser versions supported pre-versions, or working draft versions of the above.
- XSL: Microsoft referred to the pre-release implementation of the transformation language as XSL.
This is confusing as well as misleading as it turns out.
- XDR: XML Data Reduced was the schema language supported for validation. This was based on a
note submitted to the W3C and differs from the final schema language.
- XSL Patterns: Limited functional set and differing axes available makes this a pseudo-subset of the
final version of XPath.
In addition, a de-facto standard known as SAX (Simple API for XML) was not present in Microsoft’s early
versions of MSXML.
- SAX was heavily used in Java camps.
- SAX is not a W3C standard.
Microsoft providing early support for XML standards had a twofold affect.
- Ubiquity of MSXML due to installation of IE with OS meant every Windows box had an available
XML parser with many features. This is good.
- Early adopters of XML technologies used what eventually became non-standard syntax. This is
A key standard implemented in MSXML was the DOM, Document Object Model.
- DOM provides an API for working with general XML as well as HTML.
- MSXML DOM implementation allowed for performing XSL transforms on DOM nodes.
At this time, developers on the edge were using some interesting approaches combining CSS, XSL Patterns,
downloaded to the browser and manipulated using DOM, transformed to HTML using XSL, and styled using
CSS. Scriptlets provided a way to create reusable components using only scripting language, such as
provided the ability to execute server side code from the client side. It used a Java applet to perform the
Over time, more options for remote scripting came about. Java applet, Active X control, or Flash were ways
to include feature richness on the client side capable of making requests to the server without forcing a page
reload. XML RPC libraries provided ways to send and receive XML data between client and server, but they
also required using third party components or libraries. The IFrame, introduced in HTML 4.0, was
considered the best choice at the time. The IFrame is an HTML element that indicated the server side page to
call for code execution.
Microsoft Outlook Web Access took advantage of remote scripting via the Java applet.
Why didn’t this approach take off?
- Back button and reload buttons were rendered useless.
- Reliance on client side components to be installed, applets or Active X, was a bad thing. And, if
you could rely on them, why not write your own fully functional component for richer client side
difficult when browser version or type could not be assumed.
- The time had not yet come.
Table of Contents
Copyright (c) 2008-2013. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any copying is strictly prohibited.
Internet Explorer Version
Internet Explorer 4.0
Internet Explorer 4.0a
Internet Explorer 4.01, Service Pack 1
Internet Explorer 5.0
Internet Explorer 5.0a
Internet Explorer 5.0b
Internet Explorer 5.01
2.5 Service Pack 1
Internet Explorer 5.01 Service Pack 1
2.5 Service Pack 1
Internet Explorer 5.5