Flash is a capable platform that compares adequately to Ajax in terms of web application features. Behind the scenes, the workhorse is ActionScript
which also has a direct lineage to EcmaScript. Flash supports XML, as well as
transferring XML between the client and server. So a server-side component
designed to talk to Ajax clients can also talk to Flash clients without
modification.
Flash probably has the upper hand when it comes to the range
of web applications it can implement. Flash applications will probably be more
usable and user friendly than its Ajax equivalent, owing more to its past uses
as a glitzy presentation interface.
Flash's disadvantages lie in its development tools. Yes,
Macromedia Flash is known to be an extraordinary rich development tool, but it
is expensive.
XUL web applications
XUL applications are going to be a hot topic in up coming
years. One project in particular will offer the underpinnings, XulRunner. XUL
applications have a stack load of useful components. Recently, a very
interesting milestone has been added: rewrite Firefox as a XulRunner
application.
XUL and Ajax
The technology behind XUL is almost identical to Ajax except the structure of the front end can be done in HTML, XUL, or a combination of
both. Like Ajax, XUL uses JavaScript, CSS and DOM. XUL and Ajax are so closely
aligned that switching between the two is far easier than trying to get your
head around Flash.
XUL and Ajax score major points over Flash because it
requires nothing more than a text editor to develop an application. (In terms
of deployment, XUL probably would require a zip application like WinZip). Flash
scores on its user interface capabilities, which easily outperform HTML and
CSS.
Desktop widgets
Another web application area that has seen an incredible
rise of popularity is that of desktop widgets. These are tiny applications that
sit on the users desktop doing small tasks like checking for new mail, checking
the local weather, football scores and the ubiquitous news ticker.
The surprising feature of these desktop widgets is that they
are typically nothing more than HTML (or XML if you prefer) with CSS and
JavaScript, along with a smattering of XML (or JSON) for data transfer; everything
that comprises a typical web-based application.
The first step is to create an XML file with some data. We
will call this file data.xml. It is a simple XML file and would most certainly
be more complex in a real-world application, but for clarity our examples will
be simple and concise.
Listing 1
<?xml version="1.0" encoding="UTF-8"?>
<root>
<data>
This is some sample data. It is stored in an XML file and retrieved by JavaScript.
</data>
</root> |
Now let us create a simple web page containing some sample
data. This is the page that all our JavaScript will be in and the page that
users will visit to see the Ajax script in action. Let us call this file
ajax.html.
Listing 2
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en" dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Developing Web Applications with Ajax - Example</title>
</head>
<body>
<h1>Developing Web Applications with
Ajax</h1>
<p>This page demonstrates the use of
Asynchronous Javascript and XML (Ajax) technology to
update a web page's content by reading from a remote
file dynamically -- no page reloading
is required. Note that this operation does not work
for users without JavaScript enabled.</p>
<p id="xmlObj">
This is some sample data. It is the default data for
this web page. <a href="data.xml"
title="View the XML data."
onclick="ajaxRead('data.xml'); this.style.display='none'; return
false">View XML data.</a>
</p>
</body>
</html> |
Note that we link to the data.xml file for users without
JavaScript. For users with JavaScript, the function “ajaxRead” is called, the
link is hidden, and the link does not redirect to the data.xml file. The
function “ajaxRead” is not defined yet, so if you test the example code above,
you will get a JavaScript error. Let us go ahead and define that function (and
another) so you can see how Ajax works. The following SCRIPT goes in your HEAD tags.
Listing 3
<script type="text/javascript"><!--
function ajaxRead(file){
var xmlObj = null;
if(window.XMLHttpRequest){
xmlObj = new XMLHttpRequest();
} else if(window.ActiveXObject){
xmlObj = new ActiveXObject("Microsoft.XMLHTTP");
} else {
return;
}
xmlObj.onreadystatechange = function(){
if(xmlObj.readyState == 4){
updateObj('xmlObj',
xmlObj.responseXML.getElementsByTagName('data')[0].firstChild.data);
}
}
xmlObj.open ('GET', file, true);
xmlObj.send ('');
}
function updateObj(obj, data){
document.getElementById(obj).firstChild.data = data;
}
//--></script>That is quite a bit, so let us take this one piece at a
time. The first function is “ajaxRead” – what we call from our “View XML data”
link on the web page. In the function, we define an “xmlObj” variable – this
will be the middleman between the client (user viewing the web page) and the
server (the web site itself). We define this object in an if/else chunk.
Listing 4
if(window.XMLHttpRequest){
xmlObj = new XMLHttpRequest();
} else if(window.ActiveXObject){
xmlObj = new ActiveXObject("Microsoft.XMLHTTP");
} else {
return;
}This is just a test for the availability of different
objects; some browsers implement the XMLHttpRequest object differently, so when
we define “xmlObj” as our XMLHttpRequest object, we have to define it depending
on what browser implementation is available. If no XMLHttpRequest object is
available, we end the function with a “return” statement to avoid errors. Most
of the time this check will return an XMLHttpRequest object; this particular
code should work in almost every browser out there, with the exception of some
older browsers (it works in IE 5.01, but will cease to function in Netscape 4).
Next is this block.
Listing 5
xmlObj.onreadystatechange = function(){
if(xmlObj.readyState == 4){
updateObj('xmlObj', xmlObj.responseXML.getElementsByTagName('data')[0].firstChild.data);
}
} 
