Introducing Ajax - Part 2/Page 3
'; figDoc.write(zhtm); figDoc.close(); } // modified 3.1.99 RWE v4.1 -->
Introducing Ajax - Part 2
2.6 An Ajax Encounter of the Third Kind
The fifth part of Ajax, an optional part, isn't for the faint of heart. It transcends the "mad scientist stuff" into the realm of the magical, and it is called eXtensible Stylesheet Language for Transformations, or XSLT. In other words, if Ajax really was mad science and it was taught in school, this would be a 400-level course. Why? The reason is that the technology is both relatively new and very, very browser dependent. However, when it works, this method provides an incredible experience for the user.
XSLT is an XML-based language that is used to transform XML into other forms. XSLT applies a style sheet (XSLT) as input for an XML document and produces output—in most cases, XHTML or some other form of XML. This XHTML is then displayed on the browser, literally in the "wink of an eye."
One of the interesting things about XSLT is that, other than the XML being well formed, it really doesn't make any difference where the XML came from. This leads to some interesting possible sources of XML. For example, as you are probably aware, a database query can return XML. But did you know that an Excel spreadsheet can be saved as XML? XSLT can be used to transform any XML-derived language, regardless of the source.
Listing 2-9 shows a simple Internet Explorer–only web page along the same lines as the earlier examples. By using XSLT and the
XMLHttpRequest object to retrieve both the XML and XSLT shown in Listing 2-10, it is extremely flexible. This is because after the initial page is loaded, any conceivable page can be generated simply by changing the XML and/or the XSLT. Sounds pretty powerful, doesn't it?
Listing 2-9 A Simple IE-Only Web Page
Listing 2-10 The XML and XSLT Part
2.6.2 Variations on a Theme
First, the only thing that the
initialize function does is call another function,
doPOST, passing a
doPOST reveals that the purpose of the
true is to indicate what the
SOAPAction in the request header is,
http://tempuri.org/getState to get information pertaining to states and provinces from the web service, or
http://tempuri.org/getXML to get XML/XSLT from the web service. The first time through, however, we're getting the XML.
The second difference, also in
doPOST, is the addition of a call to
buildSOAP right smack in the middle of the
send. This is how arguments are passed to a web service, in the form of text—a SOAP request, in this instance. Checking out
buildSOAP, you'll notice that
doPOST is passed to indicate what the body of the SOAP request should be. Basically, this is what information is needed from the web service, states or XSLT.
You'll remember the
stateChangeHandler from the earlier set of examples, and although it is similar, there are a few differences. The first thing that jumps out is the addition of a "work" XML document that is loaded and then used to test for specific nodes;
getXMLResponse. The first indicates that the SOAP response is from a request made to the web service's
getState method, and the second indicates a response from the
getXML method. Also notice the
doPOST with an argument of
false in the part of the function that handles
getState responses; its purpose is to get the XSLT for the XSL transformation.
Speaking of a transformation, that is the purpose of the code that you might not recognize in the
getXML portion of the
stateChangeHandler function. Allow me to point out the
The use of XSLT to generate the HTML "on the fly" offers some interesting possibilities that the other two methods of implementing Ajax do not. For instance, where in the earlier example the look of the page was dictated by the hard-coded HTML, this doesn't have to be the case when using XSLT. Consider for a moment the possibility of a page using multiple style sheets to change the look and feel of a page. Also, with the speed of XSLT, this change would occur at Windows application speeds instead of the usual crawl that web applications proceed at.
2.7 The Shape of Things to Come
The sole purpose of this chapter is to offer a glimpse of the shape of things to come, both in this book and in the industry. All joking aside, this glimpse wasn't the result of mad science or any other dark art. It is the result of several years of beating various web browsers into submission, consistently pushing a little further to create rich application interfaces with consistent behavior.
The wide range of technologies that comprise Ajax can be a double-edged sword. On one hand, there is extreme flexibility in the tools available to the developer. On the other hand, currently Ajax applications are often sewn together in much the same way that DHTML pages were in the late 1990s. Unfortunately, although the hand-crafted approach works for furniture and monsters, it relies heavily on the skill level of Igor—eh, the developer.
In future chapters, it is my intention to elaborate on the various techniques that were briefly touched upon in this chapter. Also, even though Ajax is currently considered a technique that takes longer to develop than the "traditional" methods of web development, I'll show some ideas on how to reduce this time. After all, what self-respecting mad scientist cobbles together each and every monster by hand? It's all about tools to make tools—eh, I mean monsters.
This chapter started with a brief introduction to Ajax that included some of the origins and problems associated with using "mad scientist stuff," such as the accusations of attempting to pass off a mock-up as an actual application and the inability to describe just how something works. Of course, some people still will think Corinthian helmets and hoplites at the very mention of Ajax, but you can't please everyone.
Next there was a brief outline of the philosophy behind Ajax, which centers on the idea of not bothering the server any more than is necessary. The goal is that of reducing, if not eliminating, the unload/reload cycle—or "blink," as some call it. The Ajax philosophy also includes the idea of making the client's computer work for a living. After all, personal computers have been around in some form for close to 30 years; they should do some work—take out the trash, mow the lawn, or something.
Finally, I presented the three simple examples of how Ajax can be implemented. The first example, although not quite Ajax, does much to show something of the first attempts to implement a web application with the feel of a Windows application. Although it's primitive by today's standard, it is still better than 99 percent of the web pages out there today.
XMLHttpRequest object, the second example is dead on as to what is expected from an Ajax application. Broken are the bonds that limit updates to the unload/reload cycle that has been confronting us on the Web since Day 1. In addition, XML plays well with the concept of reducing traffic.
The third and final example pushes Ajax to the current limits with the addition of XSLT to the mix. XSLT allows XML to be twisted and stretched into any conceivable shape that we can imagine. No longer are our creations limited to the parts that we can dig up here and there; we can make our own parts on demand.