Section 13.1. Ajax: It s Not Only Code


13.1. Ajax: It's Not Only Code

Ajax provides a huge bang for the buck, especially when you really need the functionality. The first time your web-page form is validated in place, you'll see what I mean. When you can click on a button and collapse a huge form, clearing up the clutter on the page, you'll be convinced Ajax is the One True Way.

Well, yes and no. Ajax, like other JavaScript-enabled applications, has its pluses and minuses.

13.1.1. PermaWhat?

If you wanted to, you could create an entire web site in one page, using Ajax and other JavaScript-enabled and replace functionality based on your web-page reader's actions. However, the problem with this is that it becomes increasingly difficult to recreate a specific view of the content.

Ajax, like all DHTML functionality, does not create permanent page effects. They have to be recreated each time a page is loaded, or each time a person makes a sequence of movements. They may not be accessible via source or printable.

There will be no permalink to individual pieces, nor will your web-page readers have a history of their actions.

Most of all, when your web-page reader hits the Back key, rather than being taken in a reverse direction within the Ajax/DHTML display stack, chances are she will be taken completely out of the page.

There are entire frameworks that have taken on these issues, with solutions such as resolving an anchor-tag release into a sequence of Ajax calls and/or DHTML. However, for the most part, before you look into these, you should ask whether having this capability is essential to your work. Again, if Ajax and DHTML are complementary approaches available to help other more traditional work, then chances are you have what you need with existing technology; you won't have to add what could be large libraries. For instance, if Ajax and DHTML are used to dynamically validate a form as it's being completed, a bookmark to the form page should be sufficient.

One of the first and most common uses of JavaScript was to build menus. This is both sad and funny because one aspect of your site that should be completely accessibleno matter by whom or by what browseris site navigation. JavaScript navigation breaks most accessibility tools.

One of the best pages on Ajax and accessibility is the WebAIM (Web Accessibility in Mind) page on the topic at http://www.webaim.org/techniques/ajax/. In addition to covering the issues, it also links to other sites that provide additional information.


13.1.2. Security and Workarounds

One of the reasons Ajax achieved such quick popularity is because it is relatively safe to useas safe as most web applications (and requiring many of the same safeguards). The reason for its safety is the JavaScript sandbox and how it impacts on XMLHttpRequest.

In the examples, the server page is on the same server and domain as the page that made the request to the server. If I tried to put that server on another domain, I'd get an error. Why? Because Ajax operates under the JavaScript same source/same domain rule: you can only invoke services on the same server (domain) as the web page.

Internet Explorer has a setting that allows requests to other domains, but other browsers don't. Firefox supports digitally signed script and cross-domain work, but again, other browsers do not. This means you'll have to either restrict page accesses to one specific domain or find a workaround.

One approach is to work through a proxy. If a proxy is installed on the web server, all calls to the service can be made through the proxy, and the proxy then distributes them accordingly.

Other web services, such as Google and Yahoo!, encode the web-service requests within the script tag rather than use the XMLHttpRequest. In addition, you can have your web server rewrite a web request and redirect the calls to a different location. This requires mod_rewrite with Apache and other services with other web servers, but most sites support this capability.

13.1.3. Ajax Best Practices

Aside from the usual practices outlined for DHTML and sanitizing data coming into the applications, there really is only one specific best practice for Ajax: use it when it makes sense.

I am really fond of Ajax because I think it's a great way to validate form input in-page, and it quickly populates lists and drop-downs. However, I don't use it for all of my applications; accessibility issues, lack of permalinks, and history are all good reasons why I don't. More than that, there are many other application components that are currently in use; they are stable, simple to implement, and should continue to be used.

For instance, I wouldn't recommend using Ajax to get a number of rows from a database and build a table of the values. Why? Because using the server application to generate a table of data (either by outputting the values or through a template system) is easier and faster; the page can, typically, be bookmarked; and the query can be stored in history and, possibly, in the bookmark.

Other than the whizbang factor, Ajax doesn't add much to this type of functionality. However, Ajax is terrific when it comes to validating a login or other form content because you don't lose what you've already typed in.

As for using Ajax to create applications to replace word editors, I already have a terrific editor: NeoOffice, the Mac frontend to OpenOffice. I don't need a browser-based alternative; the huge majority of people don't. However, when I use my online weblog-editing tool, I like some of the Ajax features; for example, I can pull up categories only when I click a toolbar, and thus select a category other than the default.

In other words, Ajax is a tool. It is not a mindset, philosophy, or badge of coolness. Definitely use it, but only when it makes sense. As Star Trek's Scotty would say, "How many times do I have to say it? Use the right tool for the job."

Beam me up, Scotty.




Learning JavaScript
Learning JavaScript, 2nd Edition
ISBN: 0596521871
EAN: 2147483647
Year: 2006
Pages: 151

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net