Whether you decide to use hidden frames or XMLHttp, there are several things you'll need to consider when building an Ajax application. Expanding the role of JavaScript into the realm of server-side logic brings with it a lot of power, but also several pitfalls that require vigilance on the part of web developers.

The Same Origin Policy Because web browsers run on a user's computer, browser manufacturers craft important security restrictions to prevent malicious coders from doing damage to users' machines.

The most important security restriction in the JavaScript paradigm is called the same origin policy, which determines the servers a certain page is allowed to communicate with.

An origin is considered a single domain, such as www. wrox An origin is considered a single domain, such as www.wrox.com, accessed through a single protocol, most often HTTP. The same origin policy states that any page loaded from this origin may access, download, and interact with (using JavaScript) any other resource from the same origin.

This is what enables the hidden frame technique to work: both frames load a page from the same origin; thus, they are allowed to communicate using JavaScript. If you try to load a frame with a page from another origin, you will not be able to interact with that page or access any scripting features of it.

The intent is to prevent malicious programmers from getting your information out of a legitimate web page. The same origin policy also affects how XMLHttp works. Using XMLHttp, you cannot access any resource that is not from the same origin as the page running the code.

This means that, by default, you cannot use a URL beginning with http:// in the open() method; you can use only absolute or relative URLs from within the same domain. If you need to access a URL located in a different origin, you must create a server-side proxy to handle the communication .

Using a server-side proxy, the browser makes a request to the web server. The web server then contacts another web server outside of the domain to request the appropriate information. When your web server receives the response, it is forwarded back to the browser. The result is a seamless transmission of external data.

Cache Control Whenever you are dealing with repeat calls to the same page, you should be concerned about browser caching. For those unaware, web browsers tend to cache certain resources to improve the speed with which sites are downloaded and displayed.

This can result in a tremendous speed increase on frequently visited web sites, but can also cause problems for pages that change frequently. If you are making several Ajax calls, you need to be aware that caching may cause you problems. The best way to deal with caching is to include a no-cache header on any data being sent from the server to the browser.

This can be done using the Cache-Control header, which should be set up as follows: Cache-Control: no-cache This tells the browser not to cache the data coming from the specific URL.

Instead, the browser always calls a new version from the server instead of a saved version from its own cache.

Ajax Patterns Even though the term Ajax has been around only since early 2005, the techniques that Ajax describes have been used since the late 1990s, giving rise to several Ajax patterns that solve specific problems.

You've already seen some of these patterns in action, namely the hidden frame technique and asynchronous XMLHttp calls. These are communication patterns between the client and server using JavaScript. As you may have expected, there are many more types of patterns.

Communication Control Patterns You already know, how to communicate with the server from JavaScript. The real question is: What is the best way to initiate and continue to make requests back to the server?

In some cases, it may be best to preload information from the server so that it is available immediately upon some user action. In other cases, you may want to send data to, or receive data from, the server in varying intervals.

Perhaps everything shouldn't be downloaded at once, and instead should be downloaded in a particular sequence. Ajax affords you fine granularity in controlling the communication between client and server to achieve your desired behavior.

Predictive Fetch In a traditional web solution, a page is presented with any number of links, each one leading to a different part of the site. This may be termed "fetch on demand," where the user, through his or her actions, tells the server exactly what data should be retrieved.

The effect is of forcing the start-and-stop model of user interaction upon the user. With the help of Ajax, however, this is beginning to change.

In Predictive Fetch pattern the Ajax application guesses what the user is going to do next and retrieves the appropriate data.

Examples : 1) Suppose you are reading an online article that is separated into three pages. It is logical to assume that if you are interested in reading the first page, you're also interested in reading the second and third page.

So if the first page has been loaded for a few seconds (which can easily be determined by using a timeout), it is probably safe to download the second page in the background.

2) Most of the time, you'll be writing an e-mail to someone you know, so it's logical to assume that the person is already in your address book. To help you out, the application preloads your address book in the background and offer suggestions.

Submission Throttling Another side of an Ajax solution is the sending of data to the server. To avoid page refreshes, the question of when to send user data is important.

In a traditional web site or web application, each click makes a request back to the server so that the server is always aware of what the client is doing. In the Ajax model, the user interacts with the site or application without additional requests being generated for each click.

One solution would be to send data back to the server every time a user action occurs, similar to that of a traditional web solution. Thus, when the user types a letter, that letter is sent to the server immediately.

This may create a large number of requests in a short amount of time, which may cause problems for the server which has to process each request the user interface which may slow down as each request is being made and processed. The Submission Throttling design pattern is an alternative approach to this problematic issue.

Using Submission Throttling, you buffer the data to be sent to the server on the client and then send the data at predetermined times. For example Google Suggest feature doesn't send a request after each character is typed. Instead, it waits for a certain amount of time and sends all the text currently in the text box.

The delay from typing to sending has been fine-tuned to the point that it doesn't seem like much of a delay at all. Submission Throttling, in part, gives Google Suggest its speed.