Foundations of Ajax 176
Craig Maloney writes "You've no doubt heard about Ajax. Practically every new and exciting application on the web uses some form of Ajax. Google's suite of applications (GMail, Google Maps, etc.), Amazon's A9 search engine, and Netflix use Ajax interfaces to give the user a better browsing experience. By using some pretty basic innovations to current technology, browsers can now deliver content in ways unimaginable only a few short years ago. Foundations of Ajax provides developers who haven't taken the time to look into Ajax a hands-on guide for quickly leveraging these technologies in their own applications." Read on for Craig's review.
Foundations of Ajax | |
author | Ryan Asleson and Nathaniel T. Schutta |
pages | 273 |
publisher | Apress |
rating | 8/10 |
reviewer | Craig Maloney |
ISBN | |
summary | A good first-look at Ajax and client-side development using JavaScript, HTML, and CSS. |
Foundations of Ajax starts with a brief history of interactive web-applications, starting from the crudest CGI and Java Applets, and chronicling various interactive technologies (Javascript, Servelets, ASP, PHP, Flash, DHTML, and the various XML browser languages like XUL, XAMJ, etc.). Ajax seems like another acronym in a sea of acronyms, but the authors quickly point out why Ajax can help with the development cycle. Ajax allows the server to validate the user's input, without creating ugly and messy JavaScript validation rules, and it allows the server to use the same rules for input validation on both the client and the server. Unfortunately, Ajax does break some of the conventions users have grown accustomed to in using traditional web applications. XMLHTTPRequest requests aren't stored in the browser history, and it can be confusing to the user to determine what changed on the page after refresh. Issues aside, the book is very encouraging on the prospects of using Ajax in web applications, and invites the reader to use Ajax where it makes sense.
Chapter 2 talks about the request method that makes Ajax possible: XMLHTTPRequest (XHR). The XHR methods are explained with several examples that detail the fundamentals occurring with the request. The examples are very clear, and the entire process is laid out in careful detail, although the Dynamic Object Model (DOM) is mentioned, but not explained until the end of the chapter.
Chapter 3 delves into server communication. It's interesting to note that the authors haven't instantiated a server yet for their Ajax communication, and for the balance of chapter 3, the server is replaced by text files. It's not until the GET/POST examples that the authors start using Servelets. While it may seem strange for the authors to be talking about client/server programming without instantiating a server, it does allow the developer to get their proverbial feet wet without battling server configuration issues. The chapter starts by introducing innerHTML, but then moves to using XML DOM for data transfer from the client. From there, the authors demonstrate a few examples of the server sending XML to the client, and the client sending XML to the server. Happily, the authors weren't content to leave us parsing XML using JavaScript, instead they finish up the chapter by introducing the JSON framework with a few examples.
Chapter 4 is really where the book starts doing very interesting examples with Ajax. It's also, coincidentally, the largest chapter in the book, and the chapter readers will find the most useful reference examples. The book steps through the creation of examples of Simple date validation, Reading response headers for a simple ping application, Dynamically Loading List Boxes, Automatically Refreshing Pages, Progress bar (a personal favorite), Tool tips, Accessing Web Services using REST, and Auto complete. Each example is introduced with a real-world working application as an example (such as the auto complete feature of the Google search engine), and could easily be implemented in a developer's application. I found myself thinking of ways to enhance my code using these techniques.
Following chapter 4's examples, the chapters on creating a developer toolbox, testing scripts using JsUnit, and debugging Javascript seem a bit of a let-down. Chapter 5 outlines various packages for helping JavaScript coders to better spot errors in their code, and create documentation using the JavaDoc-like application JSDoc. There is also a mention of an application for crunching and compressing JavaScript code, as well as the excellent Web Developer Extension. Rounding out the chapter is a brief history of JavaScript, and some advanced JavaScript techniques. Chapter 6 introduces JsUnit and Unit Testing. Chapter 7 talks about JavaScript debuggers, such as Microsoft's Script Debugger, and the very powerful Venkman. The Venkman tutorial is very good, and would be a great starting point for anyone wanting more information on how to use this great tool.
Chapter 8 rounds out the book with the typical "for more information" sites to visit. However, in true Steve Jobs "One more thing" fashion, the authors not only plug their Ajax Framework, but also create a browser-based, Macintosh-like Dashboard application with four widgets. I was all set to finish the book, but the authors quietly slipped the best for last in the final pages of the book, bringing out a complete Mac OSX-like "Dashboard" windowed-environment in a browser complete with the drag-and-drop elements I've most associated with Ajax sites. This is by far the most complicated project in the book, and it make for an excellent ending to an already fine book.
Foundations of Ajax is a great starting point for developers wondering how they can incorporate Ajax into their own web-based projects. One minor gripe I had with this book was the examples looked pale in comparison with their real-world models, but design is hardly the focus of the book. Where Foundations of Ajax shines is it's no-nonsense introduction, implementation, and expansion of the basics of Ajax programming, leaving the reader confidently ready to utilize the concepts within. The authors have seen the potential of Ajax, and competently convey their expertise and enthusiasm for this technology."
You can purchase Foundations of Ajax from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Wow (Score:2)
Re:Wow (Score:2)
Re:Wow (Score:2)
Re:Wow (Score:2)
Re:Wow (Score:2)
Re:Wow (Score:2)
Fantastic. What do you do to people who use the term Web 3.0?
Re:Wow (Score:2)
Re:Wow (Score:2)
Re:Wow (Score:2)
Re:Wow (Score:2)
Not even one mention of "Web 2.0"!
You can always count on slashdotters to shoot down anything that smacks of enthusiasm.demo? (Score:2)
Re:demo? (Score:2)
Re:demo? (Score:2)
Re:demo? (Score:1)
World Airport and Airspace Database [roborg.co.uk] - Really cool if you like looking at aeroplanes and airports
GeoNews - News with geographical data [roborg.co.uk] - See global news feeds parsed for place data and plotted on a map.
Both these projects use Google Maps - the second one has a few special features added, like a custom zoom tool and locator beacons. I'm going to make the source available as soon as I neaten it up a bit and write some documentation.
Re:demo? (Score:2)
Re:demo? (Score:2)
More unfortunately, Adaptive Path, the coiners of the original term/acronym also do not [adaptivepath.com].
Unless I'm missing something...
Re:demo? (Score:2)
Re:demo? (Score:2)
Re:demo? (Score:2)
It's nice if, in retrospect, you don't want a word to be an acronym, but as popular as certain words get, they are and will still be acronyms, like RADAR, which is often represented as "Radar" or "radar" in terms of capitalization in print media.
The fact is that AJAX (or Ajax) is in fact a direct derivation of the first letters of the words it represents, and thusly is, like it or not, an acronym. Further, I would think it impr
Re:demo? (Score:2)
Really? Improper? For a little perspective, we used to think that it would be improper to code in C if you couldn't write assembler. Suprisingly lots of people were successful at a higher level of abstraction without understanding the underlying structure.
Ajax is just a more recent example of the same phenomena. For now, it's important to understand the underlying technologies becau
Re:demo? (Score:2)
"Q. Why did you feel the need to give this a name?
A. I needed something shorter than "Asynchronous JavaScript+CSS+DOM+XMLHttpRequest" to use when discussing this approach with clients."
Re:demo? (Score:2)
Moving target (Score:2)
Re:Moving target (Score:2)
Now if it were a reference manual, then I'd be more likely to agree. But even there, a lot of us like to lay the hard-copy book down on our desks while we program. Jus
Re:Moving target (Score:2)
You're not old you just haven't gone paperless yet. It is difficult.
If you already know cgi programming and don't know ajax all you need is this:
Rasmus' 30 second AJAX tutorial. [rajshekhar.net]
It's just call back functions for the web; most good programmers could pick this up in an hour. I looked at the 30 second tutiorial and only needed to understand the syntax, it's obvious what it does. That took 11 seconds not 30.
Re:Moving target (Score:2)
Please don't promote that awful tutorial. It makes two classic newbie mistakes: javascript: hrefs and browser detection. These are stupid [jibbering.com] and wrong [quirksmode.org]. Yes, I know Rasmus is a hot shot PHP developer, but his Javascript sucks.
Re:Moving target (Score:2)
I don't find Rasmus' AJAX tutorial all that bad. His point is that it's not all that hard to do AJAX. I do agree that he's not up on the latest JavaScript best practices though, so he ends up doing JS things the wrong way sometimes.
Re:Moving target (Score:2)
It can't be that bad of a tutorial as I actually added Web 2.0 AJAX functionality leveraging legacy infrastructurte.
In other words I added a quick hack to an exising webware app of mine in under 5 minutes.
Sincerely,
Dilbert
Re:Moving target (Score:2)
These are hardly "latest best practices", they are well-established principles that have been around for the best part of a decade. For instance, here's a posting from 1997 [google.com]:
Here's a posting from 2001 [google.com]:
And another from 1999 [google.com]:
Re:Moving target (Score:2)
You make it sound like being paperless is the goal. I suppose that's a decent goal to have, in order to help the environment. But I have a bigger goal -- to read what I need/want, when and where I want, comfortably. And in many cases, books are still a lot better at meeting that goal. Granted, the Internet helps me achieve that goal a lot of the time, but not always. I'd consider going paperless a secondary goal for myself.
As far as Rasm
Re:Moving target (Score:2)
Well, it does save on ink.
When I learned this stuff (c/unix) there were no books, except the K+R books so I'm used to learing by hacking. I find books tedious and annoyingly slow. I can learn things faster by doing than reading and have been doing this long enough that I'm generally aware of common pitfalls.
Other than K+R 1st edition I did buy an O'reilly book once, for one page had some answers that at the time google could not produce.
I realize the book
Re:Moving target (Score:2)
So I'd say, yes, the book is neccesary. Rather than meandering all over the web trying to figure
Re:Moving target (Score:2)
So... (Score:2)
I totally agree. (Score:2)
Re:So... (Score:2)
Ajax applications are not GUI applications. They are web applications, and the web isn't tied to a single type of interface.
People who pretend the web is GUI-only usually end up building things that are fragile and inaccessible, not just for the people who don't use GUIs, but power-users and people using alternative user-agents as well (e.g. search engines, UserJS/Greasemonkey scripts, etc).
Re:So... (Score:2)
Re:So... (Score:2)
The correct link is here: Atlas [asp.net]
Bill
Re:So... (Score:2)
I feel sorry for all the trees... (Score:2)
I feel sorry for all the trees that have to be cut down needlessly so that developers can try to keep up with the latest crappy technology that will obsolete in less than 2 years.
On the bright side, at least its under 300 pages long.
It's a conspiracy! (Score:1)
Re:It's a conspiracy! (Score:2)
That explains the book on slash... [oreilly.com]
Re:It's a conspiracy! (Score:2)
Re:I feel sorry for all the trees... (Score:2)
As if the 100 romance novels published every month are any more worthy...
Re:I feel sorry for all the trees... (Score:2)
Romance novels...?
Yeah, but at least some people get off on romance novels. The same cannot be said for the computer-book-du-jour.
Re:I feel sorry for all the trees... (Score:2)
Speak for yourself, you insensitive clod!
Re:I feel sorry for all the trees... (Score:2)
What level? (Score:1)
Re:What level? (Score:2)
Hope this helps!
Re:What level? (Score:2)
see sig. (Score:1)
Re:see sig. (Score:2)
Re:see sig. (Score:2)
Which is the standards-compliant, non-crazy-scripty way of doing it. Also this method and yours SHOULD both respect the same-source rule. If it doesn't, it's a browser bug. Also, it won't display your data in the page by accident if you make a mistake in your stylesheet (class/name that's styled "position: absolute;" in yo
Re:see sig. (Score:2)
Actually, that's not true. The load() method [w3.org] was part of early DOM3LS drafts, but was taken out before the specification reached Recommendation [w3.org] status. As far as I'm aware, there's no non-draft specification describing load(), nor plans to write one.
XMLHttpRequest, on the other hand, is part of the draft "HTML 5" specification [whatwg.org] published by the WHATWG, and I expect it will remain there permanently.
Re:see sig. (Score:2)
Standard specifies you're allowed to insert any DOM element at will, and makes no special exceptions for "script." It makes lots of assertions about cross-window, cross-frame etc scripting, about limits of what can you do with elements inherited by inserted elements etc, but in normal conditions you're free to load a script from an
Re:see sig. (Score:2)
Um... as far as I believe in them? Is their existence in question?
That's your opinion. But how is it "abusing a hole in the specs" to do something according to spec and have it work according to spec?
Re:see sig. (Score:2)
you add a script element and it is parsed and executed... seems fairly straightforward to me.
Except the specs came to lengths to prevent this kind of behaviour in cross-domain linking. You can't perform xmlHTTPRequest for a website other than the one the page is loaded from. You can't do shit to a DOM tree of a document in other frame/window. The specs' intention of preventing ability to dynamically load scripts from sites other than where the page comes from see
Re:see sig. (Score:2)
Please be more clear. This is the second time you've skirted around what you are trying to say here without coming out and saying it.
So? There's a huge difference between XMLHttpRequest, iframes, etc,
Re:see sig. (Score:2)
Re:see sig. (Score:2)
It's
There's no such method as
in DOM [w3.org] (which, contrary to what the reviewer says, stands for Document Object Model, not Dynamic Object Model).
yep, its a good book (Score:3, Informative)
Ajax vs. Comet (Score:1)
Oh, that Ajax.
Nevermind...
Off Topic (Score:3, Interesting)
I noticed all the stories have very few comments modded to 3 or above. And by few I mean 20. Just skip through any of the articles on the front page.
Did I not get the memo?
Re:Off Topic (Score:2)
I have been wondering that too (Score:2)
Re:Off Topic (Mod Parent Up) (Score:2)
Re:Off Topic (Mod Parent Up) (Score:2)
Too bad they didn't use Ruby on Rails... (Score:2)
I'm using AJAX a fair bit (mostly on the admin pages) on getindi [getindi.com]; it's very handy stuff!
Yet Another Buzzword (Score:2)
All "Ajax" means is that Javascript now works. I used to accomplish the same tasks (i.e. asynchronously send/receive bits of data, dynamically update tables without refreshing the whole page) using hidden frames and javascript submits back in 1999. Javascript now has built-in functions to do this so it's less of a hack, but I don't think that it merits a whole new buzzword.
Then again, I guess it's something for new startups to tout and investors to latch on to, so maybe it's more of a business/marketing b
Re:Yet Another Buzzword (Score:2)
Yeah, this was hardly "unimaginable" a few years ago. It was more like "what do you mean, none of this stuff really works the way it ought to?"
AJAX is just a hack on top of a kludge to try to make a stateless batch protocol into a persistent interactive "experience". HTTP works fine for what it was designed for, HTML works fine for what it was designed for, AJAX reminds me of the classic Yiddish joke about the tailor:
Re:Yet Another Buzzword (Score:2)
Seriously, everyone here clearly understands what is meant by Ajax, and it's less clunky than "asynchronously send/receive bits of data, dynamically update tables without refreshing the whole page," so I can't complain. You, however, are welcome to bitch until the cows come home.
I don't want to "leverage" it (Score:2)
Damn marketing driods
I've read this book and... (Score:2, Informative)
Re:I've read this book and... (Score:2)
No wonder hookers and strippers hate geek conventions.
Dude, what happens in Vegas stays in Vegas.
OK book (Score:5, Informative)
If you use Java, great. But the book title is misleading, and it should be called "Foundations of Ajax in JavaScript and Java."
The other caveat: the book is designed for people who want to use Ajax to spruce up an existing web page a little, not design new applications built from the ground up to use Ajax as the data transport mechanism. If this meets your needs, great. If you're looking to do bigger stuff, get "Ajax in Action" froom Manning.
Gecko DOM Reference (Score:2)
Re:Gecko DOM Reference (Score:2)
Re:Too bad ... (Score:2)
Re:Too bad ... (Score:2)
As for those "Recommendations", that part just happens to tell you what's here already and what's still in the works. But go ahead and write five versions of your code. (IE, Mozilla, Opera, Konqueror, Safari) Less competition is a good thing for me.
AJAX? that some new thing? (Score:2)
Is it good or is it wack?
Re:AJAX? that some new thing? (Score:3, Funny)
Ajax is great! It cleans my hands, is tough on grime, and makes my dishes sparkling clean.
Unimaginable? (Score:2)
DOM (Score:2)
"New" and "exciting", eh? (Score:2)
If by "new and exciting" you mean "redundant and obnoxious", then yes. Yes they do. So much for being able to browse information in a way that I dictate; now I'm subject to the whims of some insane application living inside my web browser.
If that's what it comes to, why not just stick with Flash? At least with Flash, it doesn't take a dozen images and pages of CSS to effect a rounded rectangle! (This may be an exaggeration!)
Re:"New" and "exciting", eh? (Score:2)
Me thinks his knee jerketh too much.
Re:"New" and "exciting", eh? (Score:2)
Keep in mind, though, two things. First, Google Maps is the exception to the rule in terms of the tradeoff between usefulness and complexity (in the sense of lacking a reasonable degradability for browsers without the necessary functionality). Second, imagine how much better [google.com] Google Maps would be if it didn't have to be crammed into a browser.
Re:"New" and "exciting", eh? (Score:2)
As for Google Earth v Google Maps, sure Google Earth is an interesting app. Is it a better app? Well, not really in terms of usefulness. Most of the time if I'm looking for an
Re:"New" and "exciting", eh? (Score:2)
Many of my concerns with AJAX are not inherent to it; they are problems inherent to any software development. Hence the analogy to Flash. As a specific example, Flash provides all sor
Re:"New" and "exciting", eh? (Score:2)
JsUnit and AJAX don't mix! (Score:3, Informative)
As I'm sure you all know, testing AJAX stuff in multiple browsers is really important if you want to guarantee cross-browser compatibility; it's also really tedious. JsUnit seemed like it would be a promising tool for AJAX automation.
In fact, I'm sad to say, JsUnit can't be used to validate AJAX components at all; in fact, it can't it be used to validate *any* command that requires a callback, including XmlHttpRequest, event handlers, pop-up windows, etc.
This is because browsers (IE/Firefox both) interpret JavaScript in a single thread, but actions you perform may have asynchronous side effects OUTSIDE of your own thread. So when you attempt one of those fancy asynchronous XmlHttpRequests, you can't just sleep/wait until your request finishes, because it will *never* finish until you completely return from your current thread. Only then will the interpreter begin working on the next item in the event queue.
That means, among other things, that it's impossible to wrap an AJAX request in a "try/catch" block: Because this will never work, JsUnit's strategy of emulating JUnit or the other *Unit frameworks is fundamentally unsuitable for testing AJAX in multiple browsers.
If you *are* interested in testing AJAX applications in multiple browsers, I recommend looking into Selenium [openqa.org], which basically works around the problem by constantly scheduling timers to re-invoke itself every 10ms... that gives the interpreter enough time to do other work, and allows Selenium to implement a simple "pause" action that actually works.
Unimaginable? (Score:2)
Wha? I happily admit that we've seen some pretty cool uses of the available technology in recent times, but I've personally been doing what is now known as Ajax for at least 5 years.
Would people please stop taking all the fun arcane stuff and wrapping up in media-friendly (and code monkey friendly) parcels?
Now a good chunk of my fun work will be replaced by some co
Re:Ajax is suboptimal (Score:2)
Re:Ajax is suboptimal (Score:2)
Your premise - that developing Ajax web applications is harder than developing Flash applications - doesn't support your conclusion - that Flash is technically better.
You are assuming that Ajax web applications and Flash applications are of a similar quality - they are not. Flash applications are essentially executables that you are handed, with no choice but to run them or not run them. Web applications are documents linked together, with stylesheets to suggest a presentation and script to suggest an
Re:Ajax is suboptimal (Score:2)
Yes, and if web applications were made up of nothing but Javascript, then you might have a point. But they are not. Javascript is just one non-essential component.
Flash vulnerabilities certainly exist. [google.com]
It seems you've assumed that my problem with it being a chunk of executable code is one of security. This is not the case. Given executable code, you've really only got two
Re:Ajax is suboptimal (Score:2)
If this were true, then browsers like Lynx, JAWS and IBM Homepage Reader would be impossible. Content and presentation are clearly not bound together as tightly as you claim.
You might consider HTML to be a poor data format, but that doesn't change the fact that it's as close to a native format for the web as there is, with practica
Re:Ajax is suboptimal (Score:2)
If I were to be given a choice, I'd develop in Flash over "AJAX" any day. No issues with browser sniffing, cross-browser glitches, or the debugging hell that comes bundled with complex javascript apps. But there are some things you can do with javascript that you simply cannot do with Flash. And there are degree
Re:If AJAX is so amazing... (Score:2)
Re:If AJAX is so amazing... (Score:2)
Re:If AJAX is so amazing... (Score:2)
And the server-side part of AJAX can certainly be Perl.
Re:Save $5.60! (Score:2)
Muchos gracias.
And if you use the "secret" A9.com discount [amazon.com], you can save an extra 1.57%!
Appreciated, but...
from A9: You can save an additional 1.57% (/2%) on virtually all your purchases at Amazon.com by simply becoming a regular user of our search engine at A9.com and on A9.com. Once you use A9.com for a few days you will be eligible for the A9 Instant Reward.
I'm not so easily bribed... at least not