لطفا منتظر باشید ...
13.2 Client-Pull 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 or
XHTML document. The special tag tells the client 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
change just a portion of a document dynamically using client-pull.)
[<meta>]
13.2.1 Uniquely Refreshing
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 in Chapter 6, you can add your own
special fields to an HTML document's HTTP header by
inserting a <meta> tag into its
<head>. [<meta>]
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 in the next section.
13.2.2 The Refresh Header Contents
The value of the
content attribute in the special
Refresh <meta> tag
determines when and how the browser updates the current document. Set
it to an integer, and the browser delays that many seconds before
automatically loading another document. You may set the content field
value to 0, meaning no delay at all. In that case, the browser loads
the next document immediately after it finishes rendering the current
one, which allows you to achieve some very crude animation effects.
[Section 6.8.1]
13.2.2.1 Refreshing the same document
If the Refresh field's
content value is just the number of seconds, 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 reloads the following client-pull 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 document so that it acts like a ticker-tape
machine, with the latest kumquat commodity price updated every 15
seconds.
13.2.2.2 Refreshing with a different document
Rather than reloading the same document repeatedly, you can tell the
browser to load a different document dynamically. You do so by adding
that document's 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/nextl">
would cause the browser to retrieve the
nextl document from the
www.kumquat.com web server after having
displayed the current document for 15 seconds.
13.2.2.3 Cycling between documents
Keep in
mind that the effects of the Refresh
<meta> tag apply only to the document in
which it appears. Hence, to cycle between 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.
The document firstl contains:
<meta http-equiv="Refresh"
content="30; URL=secondl">
The document secondl contains:
<meta http-equiv="Refresh"
content="30; URL=thirdl">
And the thirdl document has in its
<head> (besides other crazy ideas):
<meta http-equiv="Refresh"
content="30; URL=firstl">
If it is left alone, the browser endlessly loops between 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 time-out 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 its own Refresh
field that eventually points 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.
13.2.3 Pulling Non-HTML Content
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 0 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, which Netscape and Internet Explorer use
special helper applications to display. On a multitasking computer,
such as one running Unix or Windows 98, 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 waiting 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 plays the first segment while downloading the second, then
third, then fourth, and so on.
13.2.4 Combining Refresh with Other HTTP Header Fields
You can have your client-pull dynamic
documents perform some neat tricks by combining the effects of the
Refresh field with other HTTP header fields. One
combination that is particularly useful is 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 an 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 users 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 honors 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 automatically retrieves the next URL your
new home page location.
13.2.4.1 A random URL generator
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.
13.2.5 Performance Considerations
Client-pull documents consume extra
network resources, especially when the refresh delay is small, since
each refresh may involve a 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.
