It’s been a long ride... and you’re almost to the end.
We can barely stand to let you go, but before you do, there’s still a few things left to cover. We can’t possibly fit everything about Ajax into one 600-page book. Well, actually, we tried that... but marketing felt that a 28-pound technical book wouldn’t do too well on the shelves. So we threw out everything you didn’t really need to know and kept the last few important bits in this appendix.
That’s right... this really is the end. Well, except for one more short appendix... and the index (truly, a must-read). Oh, and a few ads in the back... well, you get the idea.
By now, you’re a pro at using the Document Object Model to update your web pages on the fly. But once you’ve used the DOM to make changes to your page, how can you see exactly what the web browser sees? The answer is to use a DOM inspector:
You’ll need to download and install a separate tool for inspecting the DOM on Windows, using Internet Explorer. IEInspector is a tool that includes a DOM inspector for Internet Explorer as well as an HTTP Analyzer tool). Here’s exactly what you need to do:.
Where to get it: | |
How to use it: | Download and install the .EXE for IEInspector. You can then launch the tool and view a page, its markup, and its DOM tree all in a single window. |
To inspect the DOM in Safari, you’ll need to use WebKit. WebKit is the open-source system framework used by Mac OS X apps like Safari, Dashboard, and Mail. You can get it from http://webkit.opendarwin.org/.
Once you’ve downloaded WebKit, drag it into your Applications folder. Then you’ll need to run the following command in a terminal window:
defaults write com.apple.Safari WebKitDeveloperExtras -bool trueNow go to your Applications folder and open WebKit. Right-click anywhere on your page, and select “Inspect Element:”
One of the thorniest issues in Ajax is graceful degradation: how do you ensure that your app works for browsers without JavaScript enabled (or with a really old version of JavaScript). Since this is such a tricky topic, and lots of folks are designing apps targeted specifically at modern browsers, we’ve had to leave the topic for an appendix.
Still, if you’re interested in creating a user experience for every possible visitor, here’s what you’ll need to do:
Start out by designing a JavaScript-free site.
This is the biggest difference in building degradable sites. You can’t start with an Ajaxian site and then create code to “fall back” to a non-Ajax site; there’s no code that runs on a non-JavaScript browser.
So you’ve got to create a site that works well without any JavaScript. This is why most designers simply ignore non-JavaScript browsers.
Use <a> elements and Submit buttons liberally.
No JavaScript means no event handlers. When you’re stripped of
onBlurandonClick, the only markup you can use to trigger action is an<a>element (a link) and a form submit button. You should use those elements a lot since they’re the only way to initiate server-side processing from a non-JavaScript page.Write server-side programs that don’t assume Ajaxian requests.
Writing a server-side program that responds to an asynchronous request isn’t fundamentally different from writing a program that responds to a form submit. The big difference, though, is in what that server-side program returns. The response to a validation request from an Ajax page might be “okay”; but how can a non-JavaScript page interpret “okay”?
Instead, your server-side programs usually need to figure out, based on request parameters, what’s making a request. Then, based on that, your programs will need to return different data. So for an Ajax request, your program might return a short response; for a non-Ajax request, the response might be a new XHTML page or redirect.
Test, test, test... and then test some more.
The biggest issue in graceful degradation is testing. Even if you build a non-JavaScript version of your page and use the right elements and server-side programs, you’ve got to test your pages on every browser you can think of. In particular, once you’ve added in an Ajax version of the page, test on those non-JavaScript browsers a few more times. You never know what’s crept in as you’ve added interactivity.
You’ve already seen a bit about some of the cool Ajax toolkits and frameworks out there, and we mentioned script.aculo.us as one of those. Really, though, script.aculo.us is more of a user interface (UI) toolkit. There are more UI libraries out there, too. All of them are focused on making it easy to build nice, user-friendly, and sometimes visually amazing user interfaces.
These libraries are usually just JavaScript files you can download and then reference in your XHTML pages, whether the page is connected to asynchronous JavaScript or not.
You’ve already seen how JSON can help you send and receive complex objects in your Java apps. But for PHP scripts, you’re going to need a library if you don’t want to type in your JSON-formatted data manually. That’s a pain, so having a JSON library is a big deal for server-side JSON interaction.
Here’s how you can use JSON in your PHP scripts, without getting into lots of JSON-specific syntax in your PHP:
Where to get it: | It’s included with PHP 5.2.0 and later |
How to use it: | Call |
Say you’re not using PHP 5.2, and you can’t get your system upgraded (or don’t want to). In that case, you’ll need to download a library to get PHP working with JSON on your server.
Where to get it: | |
How to use it: | Create a new |
If you’re frequently working with Microsoft technologies, you may want to look into ASP.NET Ajax. ASP.NET Ajax is Microsoft’s free, proprietary version of Ajax that hooks into Visual Studio 2008 and the rest of the Microsoft technology stack.
Because ASP.NET Ajax is built to work with Microsoft’s visual products, it’s more of a drag-and-drop set of front end controls, along with the ability to build code to “back” those controls.
You can find out all you ever wanted to know about ASP.NET Ajax at http://www.asp.net/ajax.
There are a lot of good reasons to dig into ASP.NET Ajax if you’re working on or for a hardcore Microsoft product or shop. And if you’re already building apps using Visual Studio, then ASP.NET Ajax will drop right in with what you’re already doing.
But if you’re just building web apps that you want to work on Internet Explorer—as well as other browsers like Firefox and Safari—then you don’t need ASP.NET Ajax. You can use the techniques you’ve already learned, along with the DOM and request creation utility methods, to get your apps working on all major browsers.
