 |
Chapter 14 Dynamic Documents |
 |
|
Chapter 14 Dynamic Documents |
|
Client-pull documents are relatively easy to prepare. All you need to do is embed a <meta> tag in the header of your HTML document. The special tag tells the client Netscape browser to display the current document for a specified period of time, and then load and display an entirely new one just as if the user had selected the new document from a hyperlink. (Note that currently there is no way to dynamically change just a portion of an HTML document using client-pull.) [the section called "The <meta> Header Element"]
Client-pull dynamic documents work with Netscape and Internet Explorer because the browsers respond to a special HTTP header field called "Refresh."
You may recall from previous discussions that whenever an HTTP server sends a document to the client browser, it precedes the document's data with one or more header fields. One header field, for instance, contains a description of the document's content type, used by the browser to decide how to display the document's contents. For example, the server precedes HTML documents with the header "Content-type: text/html," whose meaning should be fairly obvious.
As we discussed at length in Chapter 7, Links and Webs, you may add your own special fields to an HTML document's HTTP header by inserting a <meta> tag into its <head>. [the section called "The <meta> Header Element"]
The HTTP Refresh field implements client-pull dynamic HTML documents, enabled by the <meta> tag format:
<meta http-equiv="Refresh" content="field value">
The tag's http-equiv attribute tells the HTTP server to include the Refresh field, with a value specified by the content attribute (if any, carefully enclosed in quotation marks), in the string of headers it sends to the client browser just before it sends the rest of the document's content. The browser recognizes the Refresh header as the mark of a dynamic HTML document and responds accordingly, as we discuss next.
The value of the content attribute in the special <meta> Refresh tag determines when and how the browser updates the current document. Set it to an integer, and the browser will delay that many seconds before automatically loading another document. You may set the content field value to zero, meaning no delay at all. In that case, the browser loads the next document immediately after it finishes rendering the current one, by which you may achieve some very crude animation effects. [the section called "The content attribute"]
If the Refresh field's content value is the number of seconds alone, the browser reloads that same document over and over again, delaying the specified time between each cycle, until the user goes to another document or shuts down the browser.
For example, the browser will reload the following client-pull HTML document every 15 seconds:
<html> <head> <meta http-equiv="Refresh" content="15"> <title>Kumquat Market Prices</title> </head> <body> <h3> Kumquat Market Prices</h3> Kumquats are currently trading at $1.96 per pound. </body> </html>
The financial wizards among you may have noticed that with some special software tricks on the server side, you can update the price of kumquats in the HTML document so that it acts like a ticker-tape machine: the latest kumquat commodity price updated every 15 seconds.
Rather than reload the same document repeatedly, you can tell the browser to dynamically load a different document. You do so by adding that document's absolute URL after the delay time and an intervening semicolon in the <meta> tag's content attribute. For example,
<meta http-equiv="Refresh" content="15; URL=http://www.kumquat.com/next.html">
would cause the browser to retrieve the next.html document from the www.kumquat.com web server after having displayed the current document for 15 seconds.
The URL must be an absolute one, including server type and full pathname; relative URLs don't work.
Keep in mind that the effects of the Refresh <meta> tag only apply to the document in which it appears. Hence, to cycle among several documents, you must include a Refresh <meta> tag in each one. The content value for each document in the cycle must contain an absolute URL that points to the next document, with the last document pointing back to the first one to complete the cycle.
For example, the following are the <meta> tags for the headers of each in a three HTML-document cycle:
In the document first.html:
<meta http-equiv="Refresh" content="30; URL=http://www.kumquat.com/second.html">
The document second.html contains:
<meta http-equiv="Refresh" content="30; URL=http://www.kumquat.com/third.html">
And the third.html document has in its <head> (besides other crazy ideas):
<meta http-equiv="Refresh" content="30; URL=http://www.kumquat.com/first.html">
Left alone, the browser will endlessly loop among the three documents at 30-second intervals.
Cycling documents make excellent attractors, catching the attention of passers-by to a web-driven kiosk, for example. Users may then navigate through the wider collection of kiosk documents by clicking hyperlinks in one of the kiosk's attractor pages and subsequent ones.[2]
[2] This brings up a good point: the user may override the Refresh dynamic action at any time; for instance, by clicking a hyperlink before the client-pull timeout expires. The browser always ignores the Refresh action in lieu of user interaction.
To return to the cycling set of attractors, each document in the rest of the collection should have their own Refresh fields that eventually point back to the attractor. You should specify a fairly long delay period for the nonattractor pages--120 to 300 seconds or more--so that the kiosk doesn't automatically reset while a user is reading the current document. However, the delay period should be short enough so that the kiosk resets to the attractor mode in a reasonable period of time after the user finishes.
Netscape's and Internet Explorer's client-pull feature is not restricted to HTML documents, although it is certainly easiest to create dynamic documents with HTML. With a bit of server-side programming, you can add a Refresh field to the HTTP header of any sort of document from audio files to images to video clips.
For example, create a real-time video feed by adding a Refresh header field in each of a sequence of images grabbed and digitized from a camera. Include a delay of zero with the URL that points to the next image, so that as quickly as the browser displays one image, it retrieves the next. Assuming that the network keeps up, the result is a crude (really crude) TV.
Since the browser clears the window before presenting each subsequent image, the resulting flicker and flash make it almost impossible to present a coherent sequence of images. This technique is more effective when presenting a series of images designed to be viewed as a slide show, where the user expects some sort of display activity between each of the images.
Perhaps a better use of the client-pull feature is with long-playing multimedia documents for which Netscape and Internet Explorer use special helper applications to display. On a multitasking computer, such as one running UNIX or Windows 95, the browser downloads one document, while a helper application plays another. Combine the client-pull capabilities with that multitasking to improve multimedia document performance. Rather than wait for a single, large document like a movie or audio file to download before playing, break it into smaller segments, each automatically downloaded by the previous segment via the Refresh header. The browser will play the first segment while downloading the second, then third, then fourth, and so on.
You can have your client-pull dynamic HTML documents perform some neat tricks by combining the effects of the Refresh field with other HTTP header fields. One combination in particular, is most useful: Refresh with a "Redirect" field.
The Redirect field lets the server tell the browser to retrieve the requested document elsewhere at the field's accompanying URL value. The client browser automatically redirects its request to the new URL and gets the document from the new location, usually without telling the user. We retrieve redirected documents all the time and may never notice.
The most common cause for redirection is when someone moves their HTML document collection to a new directory or to a new server. As a courtesy, the webmaster programs the original host server to send an HTTP header field containing the Redirect field and new URL (without a document body) to any and all browsers that request the document from the original location. That way, the new document location is transparent to users, and they won't have to reset their browser bookmarks.
But sometimes you want the user to reset their bookmarks to the new location because the old one won't be redirecting browsers forever, perhaps because it's being taken out of service. One way to notify users of the new location is to have the redirection URL point to some HTML document other than the home page of the new collection that contains a message about the new location. Once noted, users then take a "Continue" hyperlink to the new home page location and set their bookmarks accordingly.
By combining the Redirect and Refresh fields, you can make that notification screen automatically move to the new home page. If the browser receives an HTTP header with both fields, it will honor both; it immediately fetches the redirected URL and displays it, and it sets the refresh timer and replacement URL, if specified. When the time expires, the browser retrieves the next URL--your new home page location--automatically.
Another application for the combination of Redirect and Refresh HTTP header fields is a perpetual, random URL generator. You'll need some programming skills to create a server-side application that selects a random URL from a prepared list and outputs a Redirect field that references that URL along with a Refresh field that reinvokes the random-URL application after some delay.
When Netscape or Internet Explorer receives the complete header, it immediately loads and displays the randomly selected document specified in the Redirect field's URL. After the delay specified in the Refresh field, the browser reruns the random-URL generator on the server (as specified in the Refresh URL), and the cycle starts over. The result is an endless cycle of random URLs displayed at regular intervals.
Client-pull documents consume extra network resources, especially when the refresh delay is small, since each refresh involves a completely new connection to a server. It may take a browser several seconds to contact the server and begin retrieving the document. As a result, rapid updates generally are not feasible, especially over slow network connections.
Use client-pull dynamic documents for low-frequency updates of entire documents, or for cycling among documents without user intervention.
|
 |
|
| An Overview of Dynamic Documents |  |
Server-Push Documents |
