7.3.3
Dynamic Web Documents
So far, the model we have used is
that of Fig. 6-6: the client sends a file name to the
server, which then returns the file. In the early days of the Web, all content
was, in fact, static like this (just files). However, in recent years, more and
more content has become dynamic, that is, generated on demand, rather than
stored on disk. Content generation can take place either on the server side or
on the client side. Let us now examine each of these cases in turn.
To see why server-side content
generation is needed, consider the use of forms, as described earlier. When a
user fills in a form and clicks on the submit button, a message is sent to the
server indicating that it contains the contents of a form, along with the
fields the user filled in. This message is not the name of a file to return.
What is needed is that the message is given to a program or script to process.
Usually, the processing involves using the user-supplied information to look up
a record in a database on the server's disk and generate a custom HTML page to
send back to the client. For example, in an e-commerce application, after the
user clicks on PROCEED TO CHECKOUT, the browser returns the cookie containing
the contents of the shopping cart, but some program or script on the server has
to be invoked to process the cookie and generate an HTML page in response. The
HTML page might display a form containing the list of items in the cart and the
user's last-known shipping address along with a request to verify the
information and to specify the method of payment. The steps required to process
the information from an HTML form are illustrated in Fig. 7-33.
The traditional way to handle forms
and other interactive Web pages is a system called the CGI (Common Gateway
Interface). It is a standardized interface to allow Web servers to talk to
back-end programs and scripts that can accept input (e.g., from forms) and
generate HTML pages in response. Usually, these back-ends are scripts written
in the Perl scripting language because Perl scripts are easier and faster to
write than programs (at least, if you know how to program in Perl). By
convention, they live in a directory called cgi-bin, which is visible in the
URL. Sometimes another scripting language, Python, is used instead of Perl.
As an example of how CGI often
works, consider the case of a product from the Truly Great Products Company
that comes without a warranty registration card. Instead, the customer is told
to go to www.tgpc.com to register on-line. On that page, there is a hyperlink
that says
Click
here to register your product
This link points to a Perl script,
say, www.tgpc.com/cgi-bin/reg.perl. When this script is invoked with no
parameters, it sends back an HTML page containing the registration form. When
the user fills in the form and clicks on submit, a message is sent back to this
script containing the values filled in using the style of Fig. 7-30. The Perl script then parses the
parameters, makes an entry in the database for the new customer, and sends back
an HTML page providing a registration number and a telephone number for the
help desk. This is not the only way to handle forms, but it is a common way.
There are many books about making CGI scripts and programming in Perl. A few
examples are (Hanegan, 2001; Lash, 2002; and Meltzer and Michalski, 2001).
CGI scripts are not the only way to
generate dynamic content on the server side. Another common way is to embed
little scripts inside HTML pages and have them be executed by the server itself
to generate the page. A popular language for writing these scripts is PHP (PHP:
Hypertext Preprocessor). To use it, the server has to understand PHP (just as a
browser has to understand XML to interpret Web pages written in XML). Usually,
servers expect Web pages containing PHP to have file extension php rather than html
or htm.
A tiny PHP script is illustrated in Fig. 7-34; it should work with any server that
has PHP installed. It contains normal HTML, except for the PHP script inside
the <?php ... ?> tag. What it does is generate a Web page telling what it
knows about the browser invoking it. Browsers normally send over some
information along with their request (and any applicable cookies) and this
information is put in the variable HTTP_USER_AGENT. When this listing is put in
a file test.php in the WWW directory at the ABCD company, then typing the URL www.abcd.com/test.php
will produce a Web page telling the user what browser, language, and operating
system he is using.
PHP is especially good at handling
forms and is simpler than using a CGI script. As an example of how it works
with forms, consider the example of Fig. 7-35(a). This figure contains a normal HTML
page with a form in it. The only unusual thing about it is the first line,
which specifies that the file action.php is to be invoked to handle the
parameters after the user has filled in and submitted the form. The page
displays two text boxes, one with a request for a name and one with a request
for an age. After the two boxes have been filled in and the form submitted, the
server parses the Fig. 7-30-type string sent back, putting the name
in the name variable and the age in the age variable. It then starts to process
the action.php file, shown in Fig. 7-35(b) as a reply. During the processing of
this file, the PHP commands are executed. If the user filled in ''Barbara'' and
''24'' in the boxes, the HTML file sent back will be the one given in Fig. 7-35(c). Thus, handling forms becomes
extremely simple using PHP.
Figure 7-35. (a) A Web page containing a form. (b) A PHP
script for handling the output of the form. (c) Output from the PHP script when
the inputs are ''Barbara'' and 24, respectively.
Although PHP is easy to use, it is
actually a powerful programming language oriented toward interfacing between
the Web and a server database. It has variables, strings, arrays, and most of
the control structures found in C, but much more powerful I/O than just printf.
PHP is open source code and freely available. It was designed specifically to
work well with Apache, which is also open source and is the world's most widely
used Web server. For more information about PHP, see (Valade, 2002).
We have now seen two different ways
to generate dynamic HTML pages: CGI scripts and embedded PHP. There is also a
third technique, called JSP (JavaServer Pages), which is similar to PHP, except
that the dynamic part is written in the Java programming language instead of in
PHP. Pages using this technique have the file extension jsp. A fourth technique,
ASP (Active Server Pages), is Microsoft's version of PHP and JavaServer Pages.
It uses Microsoft's proprietary scripting language, Visual Basic Script, for
generating the dynamic content. Pages using this technique have extension asp.
The choice among PHP, JSP, and ASP usually has more to do with politics (open
source vs. Sun vs. Microsoft) than with technology, since the three languages
are roughly comparable.
The collection of technologies for
generating content on the fly is sometimes called dynamic HTML.
CGI, PHP, JSP, and ASP scripts solve
the problem of handling forms and interactions with databases on the server.
They can all accept incoming information from forms, look up information in one
or more databases, and generate HTML pages with the results. What none of them
can do is respond to mouse movements or interact with users directly. For this
purpose, it is necessary to have scripts embedded in HTML pages that are
executed on the client machine rather than the server machine. Starting with
HTML 4.0, such scripts are permitted using the tag <script>. The most popular scripting language for the client side is
JavaScript, so we will now take a quick look at it.
JavaScript is a scripting language, very
loosely inspired by some ideas from the Java programming language. It is
definitely not Java. Like other scripting languages, it is a very high level
language. For example, in a single line of JavaScript it is possible to pop up
a dialog box, wait for text input, and store the resulting string in a
variable. High-level features like this make JavaScript ideal for designing
interactive Web pages. On the other hand, the fact that it is not standardized
and is mutating faster than a fruit fly trapped in an X-ray machine makes it
extremely difficult to write JavaScript programs that work on all platforms,
but maybe some day it will stabilize.
As an example of a program in
JavaScript, consider that of Fig. 7-36. Like that of Fig. 7-35(a), it displays a form asking for a
name and age, and then predicts how old the person will be next year. The body
is almost the same as the PHP example, the main difference being the
declaration of the submit button and the assignment statement in it. This
assignment statement tells the browser to invoke the response script on a
button click and pass it the form as a parameter.
What is completely new here is the
declaration of the JavaScript function response in the head of the HTML file,
an area normally reserved for titles, background colors, and so on. This
function extracts the value of the name field from the form and stores it in
the variable person as a string. It also extracts the value of the age field,
converts it to an integer by using the eval function, adds 1 to it, and stores
the result in years. Then it opens a document for output, does four writes to
it using the writeln method, and closes the document. The document is an HTML
file, as can be seen from the various HTML tags in it. The browser then
displays the document on the screen.
It is very important to understand
that while Fig. 7-35 and Fig. 7-36 look similar, they are processed totally
differently. In Fig. 7-35, after the user has clicked on the submit
button, the browser collects the information into a long string of the
style of Fig. 7-30 and sends it off to the server that
sent the page. The server sees the name of the PHP file and executes it. The
PHP script produces a new HTML page and that page is sent back to the browser
for display. With Fig. 7-36, when the submit button is clicked the
browser interprets a JavaScript function contained on the page. All the work is
done locally, inside the browser. There is no contact with the server. As a
consequence, the result is displayed virtually instantaneously, whereas with
PHP, there can be a delay of several seconds before the resulting HTML arrives
at the client. The difference between server-side scripting and client-side
scripting is illustrated in Fig. 7-37, including the steps involved. In both
cases, the numbered steps start after the form has been displayed. Step 1
consists of accepting the user input. Then comes the processing of the input,
which differs in the two cases.
This difference does not mean that
JavaScript is better than PHP. Their uses are completely different. PHP (and,
by implication, JSP and ASP) are used when interaction with a remote database
is needed. JavaScript is used when the interaction is with the user at the
client computer. It is certainly possible (and common) to have HTML pages that
use both PHP and JavaScript, although they cannot do the same work or own the
same button, of course.
JavaScript is a full-blown
programming language, with all the power of C or Java. It has variables,
strings, arrays, objects, functions, and all the usual control structures. It
also has a large number of facilities specific for Web pages, including the
ability to manage windows and frames, set and get cookies, deal with forms, and
handle hyperlinks. An example of a JavaScript program that uses a recursive
function is given in Fig. 7-38.
JavaScript can also track mouse
motion over objects on the screen. Many JavaScript Web pages have the property
that when the mouse cursor is moved over some text or image, something happens.
Often the image changes or a menu suddenly appears. This kind of behavior is
easy to program in JavaScript and leads to lively Web pages. An example is
given in Fig. 7-39.
JavaScript is not the only way to
make Web pages highly interactive. Another popular method is through the use of
applets. These are small Java programs that have been compiled into machine
instructions for a virtual computer called the JVM (Java Virtual Machine).
Applets can be embedded in HTML pages (between <applet>
and </applet>) and interpreted by JVM-capable browsers. Because Java
applets are interpreted rather than directly executed, the Java interpreter can
prevent them from doing Bad Things. At least in theory. In practice, applet
writers have found a nearly endless stream of bugs in the Java I/O libraries to
exploit.
Microsoft's answer to Sun's Java
applets was allowing Web pages to hold ActiveX controls, which are programs
compiled to Pentium machine language and executed on the bare hardware. This
feature makes them vastly faster and more flexible than interpreted Java
applets because they can do anything a program can do. When Internet Explorer
sees an ActiveX control in a Web page, it downloads it, verifies its identity,
and executes it.
Since nearly all browsers can
interpret both Java programs and JavaScript, a designer who wants to make a
highly-interactive Web page has a choice of at least two techniques, and if
portability to multiple platforms is not an issue, ActiveX in addition. As a
general rule, JavaScript programs are easier to write, Java applets execute
faster, and ActiveX controls run fastest of all. Also, since all browers
implement exactly the same JVM but no two browsers implement the same version
of JavaScript, Java applets are more portable than JavaScript programs. For
more information about JavaScript, there are many books, each with many (often
> 1000) pages. A few examples are (Easttom, 2001; Harris, 2001; and
McFedries, 2001).
Before leaving the subject of
dynamic Web content, let us briefly summarize what we have covered so far.
Complete Web pages can be generated on-the-fly by various scripts on the server
machine. Once they are received by the browser, they are treated as normal HTML
pages and just displayed. The scripts can be written in Perl, PHP, JSP, or ASP,
as shown in Fig. 7-40.
Dynamic content generation is also
possible on the client side. Web pages can be written in XML and then converted
to HTML according to an XSL file. JavaScript programs can perform arbitrary
computations. Finally, plug-ins and helper applications can be used to display
content in a variety of formats.
No comments:
Post a Comment
silahkan membaca dan berkomentar