JavaServer Pages, Second Edition

1.2 Basic Dynamic Page Generation

Fortunately, a solution to the problem of dynamic content has been available since the earliest days of the Web. Rather than reading the data from a file, the server can run a program in order to generate the data. This process is illustrated in Figure 1.2.

Figure 1.2. How a server generates dynamic content.

[View full size image]

As far as the browser is concerned, this situation is identical to that when the data comes from a file. The browser doesn't care whether the server obtains its data by reading a file or running a program, as long as what it gets back is valid HTML. However, the fact that a program is being run behind the scenes enables the content to be dynamic.

As shown in Figure 1.2, the mechanism by which the server and the HTML-generating program communicate is called CGI (common gateway interface). Over time, the terminology has shifted somewhat, and the programs themselves are now usually referred to as CGIs.

The earliest CGIs were written in a language called C. A sample CGI written in C is shown in Listing 1.1. It generates a Web page that contains the current time and date.

Listing 1.1 A sample CGI in C

#include <stdio.h>
#include <time.h>

int main(int argc, char **argv)  {
  time_t now;

  printf("<HTML>\n");
  printf("<BODY>\n");

  time(&now);
  printf("The time is now: %s", ctime(&now));

  printf("</BODY>\n");
  printf("</HTML>\n");

  exit(0);
}

This CGI illustrates two important drawbacks to the way the earliest CGIs worked. First, this program is clearly not a good format for HTML developers. Such a CGI could be created only by a programmer, and it looks nothing like the HTML that page developers are used to. In fact, this isn't even a good format for programmers. Each little piece of HTML requires its own piece of C code. This is acceptable, if ugly, for a simple CGI such as this, but for a more realistic example involving lots of tables and colors and JavaScript, this would quickly become overwhelming. It would also make it difficult to fix problems in the HTML or to make changes in order to make the page more attractive or useful.

Owing to the speed at which C programs run, C is still frequently used for CGI portions that are not directly related to the generation of HTML. However, C was rapidly overtaken as the CGI language of choice by another language, called Perl. Perl's main advantage is that it is extremely good at manipulating text, which eliminates some of the overhead involved with C. Listing 1.2 shows the Perl equivalent of the CGI from Listing 1.1.

Listing 1.2 A sample CGI in Perl

#!/usr/bin/perl

$now = localtime(time());

print <<"<EOT>"

<HTML>
<BODY>

The time is now: $now

</BODY>
</HTML>

<EOT>

This CGI is a little better; all the code is in one place, and all the HTML is in another. They are still in the same file, though, and tightly coupled, so there is no easy way for different people to work on different portions. In addition, it was possible to move all the code to the top only because of the simplicity of this example. In a more complex example, it would likely still be necessary to intermingle the logic with the HTML.

Today, it is possible to write CGIs in almost every language available, even Java. In the end, however, the CGI model itself has a number of intrinsic problems, regardless of any language-specific issues.

The first problem is speed. Just the mere task of having the Web server locate and invoke the CGI program may take up to half a second or so. This may not seem like much, but as any impatient Web surfer can attest, those seconds add up.

Worse, this start-up penalty must be paid for every request, as once it has finished processing one request, a CGI program exits and disappears from the computer's memory. The next time it needs the program, the Web server must be restarted. This is particularly a problem for complex CGIs that need to access a database or other system resource. These programs need not only to start up fresh each time but also to load up their resources.

The transient nature of CGI programs also limits what they can do, at least without help. The shopping cart is a classic example of this. Clearly, a shopping cart will need to remember which items a user has selected, but it cannot do this alone if it is going to evaporate after each item is added. In more technical terms, CGI programs are stateless, meaning that they cannot keep track of any data between requests. Most CGIs get around this problem by saving all necessary information to a database before they exit, but this can be slow and requires that the connection to the database be opened each time the program is started.

Perhaps the most serious problem with CGIs is the way they mesh presentation with logic. As noted, the presentation of a page is expressed as HTML and is typically written by designers and/or expert HTML authors. Program logic, such as what to do on a stock page if the requested ticker symbol does not exist, lives in the program code and is written by programmers. Despite exceptions to this division of labor, both HTML coding and programming are generally such complex and specialized activities that it is rare to find someone skilled at both.

The problem here is that at some point, the HTML must be incorporated into the program because ultimately, the program must generate the output; in order to do this, the program must have all the HTML that will go on the page. This is bad for both the programmers and HTML authors. When the design changes or new pages are designed, the HTML authors cannot change the HTML directly because it is buried in the program. They must present the new designs to the programmers, who must then incorporate the changes into their code without breaking any functionality. The HTML authors must then try out the program to ensure that the HTML that comes out is identical to the HTML that went in, and so on. Hours of company time can be lost this way, and animosity can all too frequently develop between the programming and production groups.

[ directory ]