5.3. Using RequestManager
To try out the RequestManager object, it's easiest to set up a page that sends multiple requests in a row and reports back when the results have been received. In this way, the order in which the responses are received indicates the order in which the requests were sent (with a small margin of error due to different server response times per request). Consider the following simple HTML page:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Request Manager Example</title>
<script type="text/javascript" src="PriorityQueue.js"></script>
<script type="text/javascript" src="RequestManager.js"></script>
<script type="text/javascript" src="RequestManagerExample.js"></script>
</head>
<body>
<fieldset>
<legend>Responses</legend>
<div id="divResponses"></div>
</fieldset>
</body>
</html>This page includes the necessary RequestManager files and has a <fieldset/> surrounding a <div/> called "divResponses". This <div/> element is responsible for outputting the results of each request so that it's obvious as to what has occurred. The RequestManagerExample.js file contains the JavaScript for this example, beginning with some callback functions to handle various responses:
function outputResult(oResponse, sColor) {
var divResponses = document.getElementById("divResponses");
var oRequest = oResponse.request;
var sMessage = "<div style="background-color:" + sColor + "">"
+ oResponse.status + " (" + oRequest.priority + ") "
+ oRequest.type + " " + oRequest.url + " " + oRequest.age + "</div>";
divResponses.innerHTML += sMessage;
}
function outputSuccessResult(oResponse) {
outputResult(oResponse, "white");
}
function outputFailureResult(oResponse) {outputResult(oResponse, "red");
}
function outputNotModifiedResult(oResponse) {
outputResult(oResponse, "silver");
}Each of these functions handles a different case and is used as the values of onsuccess, onfailure, and onnotmodified for each request. They each output a message, including the HTTP status, the priority (in parentheses), the request type, the URL, and the age of the request. The outputSuccessResult() function prints its message with a white background, outputFailureResult() uses a red background, and outputNotModifiedResult() has a silver background. This color-coding makes it easier to differentiate which function was called. Since the color is the only thing that changes, the outputResult() function provides the basic functionality used by the other functions.
Next, there are some functions to create specific types of requests:
function addPoll() {
RequestManager.poll({
type : "get", url : "poll.txt",
onsuccess : outputSuccessResult,
onfailure : outputFailureResult,
onnotmodified : outputNotModifiedResult
});
}
function addSubmit() {
RequestManager.submit({
type : "post", url : "post.txt", data : "name=Nicholas",
onsuccess : outputSuccessResult,
onfailure : outputFailureResult,
onnotmodified : outputNotModifiedResult
});
}
function addSubmitPart() {
RequestManager.submitPart({
type : "post", url : "post.txt", data : "name=Nicholas",
onsuccess : outputSuccessResult,
onfailure : outputFailureResult,
onnotmodified : outputNotModifiedResult
});
}
function addPreFetch() {
RequestManager.prefetch({
type : "get", url : "data.txt",
onsuccess : outputSuccessResult,
onfailure : outputFailureResult,
onnotmodified : outputNotModifiedResult
});
}
function addLowPriority() {RequestManager.send({
priority: 10, type : "get", url : "data.txt",
onsuccess : outputSuccessResult,
onerror : outputFailureResult,
onnotmodified : outputNotModifiedResult
});
}Each of these functions creates a different type of request to be placed in the queue. The addPoll() function creates a poll request to poll.txt, which doesn't exist; this should result in a 404 error. Next, the addSubmit() and addSubmitPart() functions create POST requests to a text file, post.txt, which should fail with a 405 error (most servers won't let you post data to a plain text file). The addPreFetch() function creates a GET request for data.txt, while addLowPriority() creates a very low-priority request that should be executed only after everything else has been completed.
The onload event handler is then assigned to initiate a few requests using these methods:
window.onload = function () {
addPoll();
addPoll();
addSubmit();
addPreFetch();
addLowPriority();
addSubmitPart();
addLowPriority();
addPreFetch();
addPoll();
addSubmit();
};This creates a series of different requests with varying priorities. Since these requests are added in rapid succession, they effectively end up being added to the queue simultaneously, which means that the output on the page should be very similar to this:
405 (0) post post.txt 0 405 (0) post post.txt 250 405 (2) post post.txt 500 404 (3) get poll.txt 750 404 (3) get poll.txt 1000 404 (3) get poll.txt 1250 200 (5) get data.txt 1500 200 (5) get data.txt 1750 200 (10) get data.txt 2000 200 (10) get data.txt 2250
In this output, it's clear to see that the calls to submit() were executed first; they each returned a 405 error, had a priority of 0, used POST, and were 0 and 250 milliseconds old, respectively. Next up is the call created via submitPart(), which had a priority of 2. After that, the various polling requests were executed at a priority of 3, and requests created using prefetch() were executed with a priority of 5. The two low-priority requests were executed last.
It is possible to see differing results due to the differences in client machines, how long it takes to create an XHR object, and how long it takes to get a response from the server. However, most browsers should execute very similarly, producing output resembling the output reproduced in the preceding examples, with maybe one or two higher-priority requests not executing correctly (although, all other requests should still complete before the lowest-priority ones).