Ajax: It's not only code

Ajax works outside the page but safely inside the JavaScript sandbox.

1 2 3 4 5 6 Page 2
Page 2 of 6

Security and Workarounds

One of the reasons Ajax achieved such quick popularity is because it is relatively safe to use—as 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.

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.

1 2 3 4 5 6 Page 2
Page 2 of 6
  
Shop Tech Products at Amazon