Ajax Fundamentals
Ajax is fundamentally a simple three-step process:
- Invoke a URL from JavaScript code on the client.
- Handle the URL on the server and write to the response.
- After the response is complete, integrate the response into the DOM.
Those steps are almost identical to what JSF does when you click a link that illicits a request. JSF handles that request on the server by ultimately writing to the response, which overwrites the preceding response.
The same applies for Ajax requests, except for the last step. In an Ajax request, we don’t refresh the entire page; instead, we update only part of the page. That subtle difference lets us perform all kinds of interesting interactions that were heretofore unheard of in Web applications.
To illustrate the steps involved in an Ajax request, let’s take a look at the application shown in Figure 1.
Figure 1. Basic Ajax with an XHR object and a servlet
The preceding application performs an Ajax request to obtain the current date and time from the server. Subsequently, on the client, the application integrates that response into the Web page’s DOM. That causes the date to update without refreshing the entire page.
Here’s how it works. First, we have a DIV, which is initially empty. After the request, we’ll update that DIV’s inner Hypertext Markup Language (HTML). Here are the button and the DIV that set everything in motion:
Notice that the button’s type is button, which means it’s a push button and not a submit button. When a user activates that button, JSF doesn’t submit the surrounding form; instead, it calls the JavaScript showDateAndTime function, which looks like this:
The showDateAndTime function calls sendRequest(), which locates the XMLHttpRequest object (otherwise known as the XHR object) with the initXHR function.
Once we have the XHR object, we’re ready to go. First, we set the XHR object’s callback function to our own processAjaxCall(), and then we open and send the request. As the Ajax call progresses, the XHR object will repeatedly invoke our callback function with news concerning the request’s progress. As it turns out, in practice, folks are mostly concerned with reacting to an Ajax request only after it has successfully completed, as is the case for our example. In our callback function, we check for a successful response code-named readystate 4 and status 200. That status code corresponds to the HyperText Transfer Protocol (HTTP) status, which means the request was handled successfully.
Once the Ajax call has successfully completed, we set the inner HTML of our DIV to the response text. That response is generated by a servlet:
The preceding servlet is associated with the URL dateAndTime.ajax in the deployment descriptor, which associates all URLs that end in .ajax with the AjaxServlet.
Note: Ajax requests do not necessarily reduce server-side traffic
Ajax newcomers sometimes mistakenly believe that Ajax, because it provides a more responsive user interface, reduces server-side traffic. In fact, Ajax applications typically have more server-side traffic because each Ajax request involves a trip to the server. Because those requests are asynchronous, however, Ajax creates the perception of a more responsive UI, but it typically does not reduce the load on the server.