Slashdot Mirror
Creating Web Pages With Ajax
Ravi writes "Asynchronous Javascript And Xml, popularly known as Ajax, is a combination of Javascript, XML and some coding on the server side. Even though this technology existed for years, many believe it was Google which brought it to the front by implementing it on its sites and thus raising it to the cult status it enjoys now. There is something magical in seeing a website update its content without reloading the whole page, which is the visual essence of Ajax." Read the rest of Ravi's review.
AJAX - Creating Web Pages with Asynchronous JavaScript and XML
author
Edmond Woychowsky
pages
390
publisher
Prentice Hall
rating
9
reviewer
Ravi
ISBN
0-13-227267-9
summary
A useful introductory book in picking up the skills in using Ajax
I found the book titled "AJAX — Creating web pages with Asynchronous JavaScript and XML" authored by Edmond Woychowsky to be a very good introductory level book on learning the basics of Ajax. Spanning 390 pages and 16 chapters, this book imparts a sound understanding of the basic features which make ajax possible.
The author starts by giving a brief introduction to the different types of web pages — static and dynamic, the tools and code used to serve them.
In the second chapter which is titled "Introducing Ajax", the author dives into the philosophy and principles of Ajax and with the aid of three simple examples explains three different ways of implementing ajax in a webpage. I found this chapter to clear some of the doubts that a newbie will have about the hype surrounding ajax.
The third chapter takes a step backwards in that it gives a birds eye view of all the XHTML elements and their associated attributes. The author also provides a table which lists the most commonly used CSS 1 elements. I found this chapter more of a ready reference than an indepth thesis on XHTML and CSS.
The fourth chapter titled "Javascript" provides a very good understanding of the language. Javascript plays an invaluable part in the greater scheme of the working of Ajax. Apart from the snippets of code and explanations, this chapter also has a number of tables listing things such as the essential JavaScript functions, characters used to create regular expressions, event handlers, Javascript operators and so on.
In the next chapter titled "Ajax Using HTML and JavaScript", the author explains how to use HTML, Javascript and stored procedures incorporated in the latest version of MySQL to create a semblance of an Ajax shopping cart. What is worth noting is that this chapter explains an old fashioned but very reliable technique which uses hidden frames and inline frames to update the data on the page. Of course the author is quick to point out that this technique is not really Ajax in the sense that it lacks the XML part.
I found the author's narration quite refreshing as he explains each concept one at a time with the aid of snippets of code, gradually building up and eventually tying all the threads together to write a true Ajax web application.
XML — eXtensible Markup Language is the successor of SGML — the language which powers HTML. XHTML on the other hand uses the XML schema. XML is a vast subject which can easily fit in a book of its own. Perhaps knowing this, and because XML plays a significant part in Ajax, the author has intelligently provided just the necessary information about XML in the sixth chapter.
The seventh chapter is a very important chapter which gives an indepth understanding of the XMLHttpRequest object which can be considered the brain behind Ajax. The author also provides some insights into the XML document object model, RSS and Web services such as SOAP.
In Chapter 8, the author gives a more indepth take on the XMLHttpRequest object and the other technologies explained in the previous chapter and illustrates by applying them in building a shopping cart application. Throughout the book, the author has highlighted the fact that ajax is a browser dependent technology and if people disable javascript in their browsers, then the whole effort will come to naught.
XPath is a technology which can be used to locate and navigate the various parts of an XML. The ninth chapter gives an introduction to the syntax used by XPath.
The next two chapters explain the concept of eXtensible Stylesheet Language for Transformations (XSLT) and how it can be used to implement Ajax. XSLT can be compared in some ways to CSS but is much more powerful and can be used to display pure XML in different styles targeting diverse media. These two chapters contain all the necessary details such as the syntatic reference and snippets of code which walks one through creating an Ajax application using XSLT.
In chapter 12, the author talks about the advantages of code reuse where creating javascript objects are explained. Surprisingly, there are two chapters on Ruby on Rails — the latest fad with the web developer community.
I found the book to be a valuable reference for upcoming Ajax web programmers. The number of tables listing the tags and their attributes itself will more than make up for the cost of the book. It has the right amount of content covering all pertinent topics without overwhelming the reader, which makes it a very good introductory book on Ajax.
Ravi Kumar is passionate about all things related to open source and free software and likes to share his thoughts and experiences related to these through his site "All about Linux".
You can purchase AJAX - Creating Web Pages with Asynchronous JavaScript and XML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I found the book titled "AJAX — Creating web pages with Asynchronous JavaScript and XML" authored by Edmond Woychowsky to be a very good introductory level book on learning the basics of Ajax. Spanning 390 pages and 16 chapters, this book imparts a sound understanding of the basic features which make ajax possible.
The author starts by giving a brief introduction to the different types of web pages — static and dynamic, the tools and code used to serve them.
In the second chapter which is titled "Introducing Ajax", the author dives into the philosophy and principles of Ajax and with the aid of three simple examples explains three different ways of implementing ajax in a webpage. I found this chapter to clear some of the doubts that a newbie will have about the hype surrounding ajax.
The third chapter takes a step backwards in that it gives a birds eye view of all the XHTML elements and their associated attributes. The author also provides a table which lists the most commonly used CSS 1 elements. I found this chapter more of a ready reference than an indepth thesis on XHTML and CSS.
The fourth chapter titled "Javascript" provides a very good understanding of the language. Javascript plays an invaluable part in the greater scheme of the working of Ajax. Apart from the snippets of code and explanations, this chapter also has a number of tables listing things such as the essential JavaScript functions, characters used to create regular expressions, event handlers, Javascript operators and so on.
In the next chapter titled "Ajax Using HTML and JavaScript", the author explains how to use HTML, Javascript and stored procedures incorporated in the latest version of MySQL to create a semblance of an Ajax shopping cart. What is worth noting is that this chapter explains an old fashioned but very reliable technique which uses hidden frames and inline frames to update the data on the page. Of course the author is quick to point out that this technique is not really Ajax in the sense that it lacks the XML part.
I found the author's narration quite refreshing as he explains each concept one at a time with the aid of snippets of code, gradually building up and eventually tying all the threads together to write a true Ajax web application.
XML — eXtensible Markup Language is the successor of SGML — the language which powers HTML. XHTML on the other hand uses the XML schema. XML is a vast subject which can easily fit in a book of its own. Perhaps knowing this, and because XML plays a significant part in Ajax, the author has intelligently provided just the necessary information about XML in the sixth chapter.
The seventh chapter is a very important chapter which gives an indepth understanding of the XMLHttpRequest object which can be considered the brain behind Ajax. The author also provides some insights into the XML document object model, RSS and Web services such as SOAP.
In Chapter 8, the author gives a more indepth take on the XMLHttpRequest object and the other technologies explained in the previous chapter and illustrates by applying them in building a shopping cart application. Throughout the book, the author has highlighted the fact that ajax is a browser dependent technology and if people disable javascript in their browsers, then the whole effort will come to naught.
XPath is a technology which can be used to locate and navigate the various parts of an XML. The ninth chapter gives an introduction to the syntax used by XPath.
The next two chapters explain the concept of eXtensible Stylesheet Language for Transformations (XSLT) and how it can be used to implement Ajax. XSLT can be compared in some ways to CSS but is much more powerful and can be used to display pure XML in different styles targeting diverse media. These two chapters contain all the necessary details such as the syntatic reference and snippets of code which walks one through creating an Ajax application using XSLT.
In chapter 12, the author talks about the advantages of code reuse where creating javascript objects are explained. Surprisingly, there are two chapters on Ruby on Rails — the latest fad with the web developer community.
I found the book to be a valuable reference for upcoming Ajax web programmers. The number of tables listing the tags and their attributes itself will more than make up for the cost of the book. It has the right amount of content covering all pertinent topics without overwhelming the reader, which makes it a very good introductory book on Ajax.
Ravi Kumar is passionate about all things related to open source and free software and likes to share his thoughts and experiences related to these through his site "All about Linux".
You can purchase AJAX - Creating Web Pages with Asynchronous JavaScript and XML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Now, now Mel. You aren't supposed to be drinking in the middle of the day.
Quality Hosting e3 Servers
Google definitely didn't invent it. At this point I think more people are using JSON for the data format versus xml. There is just way too much overhead associated with xml. There are a host of javascript and other programming langauge libraries built up to make mall this more easy. For example, the dojo toolkit for javascript has functions for sending the request and decoding the JSON for you automatically. It also provides some framework for passing parameters, handlign errors, and more. Then JSON.org has a host of built up libraries in Java, Perl, C++, Ruby, ...(many many more) for encoding the data to send back. It's all very easy to do now.
...a 4th grade book report.
just get .net 2.0 and atlas
...made a webpage out of AJAX, the FBI arrested me for attempting to poison the world as a terrorist act.
My biggest problem with AJAX is the popular misconceptions that surround it. For example, I was speaking to somebody a few days ago and they asked me how I would implement some survey widget as a webpage. I thought about it for a bit and told them it would be pretty easy with some PHP and MySQL. I was informed that my idea is "old and outdated". It appears this guy had already hired somebody and he is "coding it in AJAX and Dreamweaver".
I suggested that AJAX is nice, but it's not a programming language, and more importantly it is not always the best solution for a problem. His reply? That I need to get more "2.0 centric". I was done at this point, but not before informing him that Web 2.0 is little more than pastel colors and BS.
Surprisingly, the reason he asked me in the first place is that the guy they hired has been working on the system for the last 3 months with "little visible progress". Oh well, at least he's "2.0" enough for them.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
Ajax is definitely at the forefront of what we think of as "Web 2.0" or Symantec Web technologies. The whole point of pushing web applications forward is to make them more like desktop applications that run natively (and I am not talking about Flash, Java applets, or stuff that requires 3rd-party software or requires stuff to run on the client machine except for JavaScript). In my mind, that is when the Symentec Web will finally arrive, and Google is already making it happen.
... she is brillant with ajax!
AJAX creates javascript applications which are like web applications except they require clients to support and enable script.
http://www.freeringtoneheaven.com/ has tracked over 70,000 ips and about 64% have javascript enabled. At http://www.icarusindie.com/ with 78,000 ips tracked only about 38% have javascript enabled.
The only reason FRH is higher is because visitors were required to have javascript enabled in order to download ringtones. That restriction has been removed. Icarus Indie has never required javascript to be enabled. It just keeps statistics. The sites keep track by using javascript to switch an image from a jpg to a php script. Those without js just see the jpg and those with see the image returned by the php script which also updates the database to indicate the ip has js enabled.
AJAX may be cool but if you use it you better have a good reason to convince people to turn javascript on or you're just going to lose visitors.
There were all kinds of Javascript security issues not too long ago and people still don't trust it.
Work Safe Porn
Ultimately, AJAX is nothing more than spagetti Javascript and HTML.
As much as I truly despise Macromedia Flash, the more Flash develops the more Flash makes sense for the web, and especially media rich Web 2.0. AJAX is like putting a tiny bandage on a gaping wound the size of a grapefruit. I think Flash is an abomination but the typical end user (and most MacInfags) sure loves the stuff. By the time Macromedia Flash v10.0 rolls out, AJAX will be relegated to the dustbin of technological history, much like Java applets, while Flash will be alive and kicking, and making my 2ghz CPU feel like a P2 running at 200mhz while sucking up all my network bandwidth.
This is the last Ajax post Im going to make... its getting silly at this point I get asked about it everyday. its not a language , its not even a standard... its a silicone valley buzzword made up by a guy named Jessy James . Ask someone to make you a www2 homepage for fear that your web 1.0 one will be outdated and not run on Windows vista in the long run the only winner in the hype is a hand full of early bandwagon companies (like my ajax company :) ) and Colgate-Palmolive who get all this free publicity.
Ricahrd Corsale
I find it interesting that the review mentions XSLT, which, IMHO, is very powerful:
You can completely separate most display logic from the "data" and business logic. (...which can be handled before the XSL transformation, and done such that you get XML nodes to feed into your transformations.)
It may seem complicated at first, but there are so many advantages:
1.) you get the layout of the site defined in a declarative manner, basically as as data. (and that XSL "code" can be easily analyzed or transformed, itself.)
2.) you can disentangle a lot of markup from your PHP/ASP[VBS/JScript]/Python code.
3.) The output of your XSLT transformation can be fed into other transformations.
4.) Your XSLT is highly portable across platforms, even between server vs. client-side rendering.
(Although, it bums me out that Microsoft has decided to not support XSL 2.0.)
5.) Manipulating an X/HTML dom via a browser's built-in XSLT processor is much faster than using JavaScript only. (E.g.: using JavaScript-only to traverse a DOM in order to select, merge, append, and move nodes...)
I'd be curious to know what this book has to say on the matter.
Once upon a time people were stuck with screens refreshing slowly on RS232-connected terminals or lags of busy centralized servers. Then they realized they can have a small computer right on their desk and get instant response. Why would anyone want to go back to retro lag? I am not saying applications shouldn't be installed or auto-updated form the web, but is JavaScript + text data files really a perfect client side UI? There is Java, .Net and even C++/Objective C in a virtualized sandbox.
Races that didn't do any fucking died out centuries ago.
Please sign petition to restore sanity to our banking system!!!
http://financialpetition.org/
Here's my couple of rules when to and when not to use AJAX (from experience)
;)
Do nots:
1) Navigation - save yourself both time and effort and just pass varables in URLs.
2) Application depend on it - like someone mentioned above, not everyone has Javascript enabled.
Dos:
1) Prevent popup windows - there's no reason to popup a window to make a small choice. Just switch the DIV with AJAX and make the choice done from within it.
2) Small enhancments to a site - like to scrol through a couple news clips or something similar
I'm sure there are more but I really need to get back to fixing my AJAX application-dependant-navigation-system.
I don't make any attempt to filter out bots so you can feel free to subtract as many IPs as you feel is reasonable from the total number of IPs counted. But when you're starting at 38%, you're going to have to dismiss a lot of IPs to justify breaking your site for a lot of people just because you want to use AJAX.
The other thing that should be noted is that IcarusIndie is mostly visited by technical people. Free Ringtone Heaven is more mainstream.
If you're using AJAX on a technical site you're going to have a lot more people with javascript turned off. If your site is more mainstream you'll have fewer people with JS turned off.
I'd highly recommend setting up a simple tracker like I have because every site is different. Once you have a number you're confident is accurate enough, then you can decide if making javascript necessary is a worthwhile thing to do.
Keep in mind that no javascript means no AdSense being displayed and possibly other ad systems. When I require JS, ad revenue goes up. Your results may vary.
Work Safe Porn
AJAX is an (ugly) hack to make people believe their internet is as fast as in Germany, Japan or South Korea.
The worst part about it that "experts" seem to believe that is has to involve JS in parts that could, most of the time, easily be done with competent CSS use.
JS is the most broken script language ever. And if you use JS and more then just your favourite browser, you wont need long to realize ths yourself. Sure you can write hacks (again) that detect the browser and use different code for the same effect (ugly).
3
I have built a few simple ajax apps but found the workarounds necessary to get these standard browser features working again not worth the effort in most cases.
In some countries, use of AJAX and Flash runs counter to disability discrimination legislation. Fortuantely for the web2.0 crowd WCAG2 has been sabotaged so these lowlifes can pay lip service to accessiblity while (poetic license) continuing to kick cripples in the face.
He'll enjoy his whine, you'll enjoy your AIDS.
It is the people who think AJAX pages don't send requests over the internet that I worry about.
'Oh, AJAX is cool, saves people having to wait for pages to load.' The content has got to come from sonewhere.
the typical end user (and most MacInfags) sure loves the stuff.
You email your mother with that keyboard?
You can't take the sky from me...
I always think it's funny when people say that "Web 2.0" technologies are going to put Microsoft out of business. In fact, Microsoft OWA (Outlook Web Access) is by far the most popular, and in my opinion one of the best, AJAX programs released to date.
Try AJAX with markup only, no hand-written JavaScript, by using the W3C's XForms standard. There are a number of implementations such as the Servlet-based Chiba (which fronts for Dojo and other packages), FormFaces written entirely in JavaScript (no server-side component), entire server-side pipeline systems such as Orbeon, and full client implementations such as the Mozilla/Firefox XForms Extension (just type "xforms" into your Firefox extensions finder), FormsPlayer IE Plugin, or cell-phone capable implementations such as PicoForms and SolidForms.
I wrote an entire webmail reader using PHP for the back end and XForms for the client. It runs in the Mozilla XForms implementation but could easily be made to work in any of the above, which differ mostly in how the CSS works. xmlmail
And for completness, I was an editor of an earlier version of the W3C XForms recommendation.
Actually, it is a Microsoft invention. No kidding. The Outlook Web Access (OWA) team are the ones that lobbied the Internet Explorer team to include the (original) XMLHTTP object; which was originally MADE by the OWA team.
It's fair to say that OWA for Exchange 2000 was the _first_ AJAX application. They started development of it all in 1998.
I just had to explain to someone what AJAX meant and I did it in less than 300 seconds with the help of one of my tests that I created for one of the previous projects.
// UNPARSED TEXT EXAMPLE
// ARRAY EXAMPLE
// HASH MAP EXAMPLE
Here is my test example, it is synchronous and it uses an evaluated array instead of XML, but those concepts can be explained in just another example of the same length:
<HTML><SCRIPT LANGUAGE="JAVASCRIPT">
<!--
function handleHTTPResponseForArray(str) {
handleHTTPResponse(str);
var textarea = document.getElementById("textarea2");
var result=""; var array=eval(str); var hashMap=new Array(array.length);
for(var i=0;i<array.length;i++) {
hashMap[array[i][0]] = array[i][1];
result += "key:" + array[i][0];
result += "\t\t\tval:" + array[i][1] + "\n";
}
textarea.value=result;
result="";
for(var i=0;i<array.length;i++) {
var tmpKey = array[i][0];
result += "key(" + tmpKey + ")=" + hashMap[tmpKey] + "\n";
}
textarea = document.getElementById("textarea3");
textarea.value = "Use result as a hash map with key/value pairs:\n";
textarea.value += result;
}
function handleHTTPResponse(str) {
var textarea = document.getElementById("textarea1");
textarea.value=str;
}
function handleHTTPError(str) {
alert(str);
}
function makeHTTPRequest(url, onLoadFunc, onErrorFunc) {
var request;
if(window.XMLHttpRequest) {
try {
request = new XMLHttpRequest();
} catch(e) {
alert(e);
return;
}
} else if(window.ActiveXObject) {
try {
request = new ActiveXObject("Msxml2.XMLHTTP");
} catch(e) {
try {
request = new ActiveXObject("Microsoft.XMLHTTP");
} catch(e1) {
alert(e1);
return;
}
}
}
try {
window.status = "ECSM:AJAX:Connecting to "+ url;
request.open("POST",url,false);
request.setRequestHeader('Content-Type','applicati on/x-www-form-urlencoded; charset=UTF-8');
request.send(null);
window.status = "";
} catch (e) {
window.status = "";
alert(e);
return;
}
if (request.status==200) {
onLoadFunc(request.responseText);
} else {
onErrorFunc(request.status);
}
}
function testHTTPRequest() {
var urltext = document.getElementById("urltext");
makeHTTPRequest(urltext.value, handleHTTPResponseForArray, handleHTTPError);
}
//--></SCRIPT><BODY><table>< tr><td>URL:</t
You can't handle the truth.
god no, nothing like frames
My all time favorite Firefox extension, Noscript, blocks Javascript in a flexible way that allows whitelisting by domain either permanently or temporarily. It's really fun to click and be able to turn on Javascript for just the site you're interested in and none of the advertisers on it.
...they both break the standard features of your browser like a back button but at least ajax content is visible to search engine robots
"think" is the important word when suggesting Google had something to do with AJAX. They have had NOTHING to do with it's creation seeing how that is up to the makers of web browsers. Microsoft really invented the functionality while most of the slashdotters were still getting wedgies in school.
The term AJAX may have been coined a couple of years ago in an article, but MS deserves the credit. Its also worth noting they were using it on microsoft.com before most of us had even heard the word google.
Lets see how many of you can swallow that and actually give them their do.
I think flapjax is a real good implementation of ajax enabling for javascript. Just have a look at http://www.flapjax-lang.org/.
troll? you people have no sense of humor..
Didn't you get the Slashdot memo that said the MS has never invented anyting accept MS Bob? So naturally, what you say can't possibly be true.
Yes, but it took Google to embrace and extend it!
Erm, that would be SEMANTIC web, as in the word "semantic" (see http://dictionary.reference.com/browse/semantic) not Symantec, as in the security software company (see http://www.symantec.com/index.htm).
It's all semantics, anyway I guess. Jesus.
I do like programming things that work super quickly, especially when they work super quickly, super quickly.
The simplest way to use "ajax" is to have the server send a chunk of HTML (a small table, or a paragraph, e.g.) to the browser, where the javascript just sticks it in the page where you want it. You don't need to use XML, JSON, or anything complicated. With the simplest approach, the user is essentially submitting a form inside your page and getting the result right back in the same place, with no parsing involved. I don't know why more people don't take this easy way out -- it substantially lowers the bar for getting started with ajax.
Love that URL -- msexchangeteam.com They're the ones working on a gender interchange protocol, right?
This is not a trust issue, this is probably the only place where people know what's JavaScript. I think it's an anti-virus "problem". Norton IS, just as an example, block and "cleans" every piece of JS code in a page. I have a site with a small roll down menu made in JS and users with that version of Norton can't see it. I obviously made a new text menu for those who have JS disabled...
It was an evolution, not a revolution.
Using a small or invisible frame/iframe to send hidden requests was older than that.
And lots of people (at least me) used to push some logic to the javascript side, and modify html input elements according to other elements.
Hidden (or shown) iframes were/Are great for queries.
The same behavior of ajax pages could be acheived, and the effect for the user was the same. All without a C00l buzzword.
It definately has its place.
However generally there is no right answer, only the one best for you. For example it depend how much load you want your browser to take compared to your server. Our servers are embedded devices, so it makes sense to send the raw data(in JSON or XML) and let the javascript on the broswer create the page. On the other hand some times its better to as you say just send raw HTML(Tables especially can be a nightmare, I always seem to end up losing memory when deleting and creating table rows)
Choose your allies carefully, it is highly unlikely you will be held accountable for the actions of your enemies
Prevent popup windows - there's no reason to popup a window to make a small choice. Just switch the DIV with AJAX and make the choice done from within it.
This is bad news. Basically, it means that advertisers will exploit AJAX to make mind-blowingly annoying ads. This is why we have popup blockers in the first place: the marketplace of eyeballs has limits on how much it can stand to be annoyed. It's also why the Flashblock extension exists: to block the world's most annoying ads. But now we have applications that will depend on AJAX (a.k.a. JavaScript) to function, which means that we have no way of blocking out that "div" which will likely be something so annoying it will make you want to bite your monitor. What else can people do beside shutting off JavaScript altogether?
I don't make the rules. I just make fun of them.
Of course the primary advantage of a web app is the ability to be used from a variety of OS's. If you have an in-house application and you can control the configuration of the computers, a "fat client" application is probably going to be easier to develop and give a better user experience than an AJAX-based one.
this is entirely correct and obvious. Iframes and addressing the window.opener allowed you to do some of the same things but it would be incredibly ugly way to control content in the window opener. But you have far more a framework built up now for handling sending parameters, handling errors, controlling the layout better... It's far different than submitting a simple url via an iframe.
Save yourself $1.80 by buying the book here: Creating Web Pages With Ajax. And if you use the "secret" A9.com discount, you can save an extra 1.57%!