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
- 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
- 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 hierarchy.
- 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?
- 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
- 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.
- SAX was heavily used in Java camps.
- SAX is not a W3C standard.
- 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 bad.
- DOM provides an API for working with general XML as well as HTML.
- MSXML DOM implementation allowed for performing XSL transforms on DOM nodes.
- 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 interaction?
- The time had not yet come.
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 territory”.
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 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 protocol requirements.
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 disabled.
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.
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 changes.
Slowly Evolving Improvements
However, DHTML failed to gain traction due to a number of factors:
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.
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?
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.