The Age of Scripts and Databases

The search for solutions to these problems prompted the first real revolution in web design: the use of scripts and Common Gateway Interface (CGI) programs. The first step was the use of special tags called Server-Side Includes (SSI) in each HTML file. These tags let web designers tell the web server to suck in the contents of another file (say, a standard copyright message or a list of the latest news stories) and include it in the current web page as if it were part of the HTML file itself. It made updating those bits much easier, as they were stored in only one place.

The second change was the use of simple databases to store pieces of similar content. All the news stories on ( are similar in structure, even if their content differs. The same is true of all the product pages on (http://, all the blog entries on (, and so on. Rather than storing each one as a separate HTML file, webmasters used a program running on the web server to look up the content of each article from the database and display it with all the HTML markup for the site's layout wrapped around it. URLs such as were replaced by something more like Rather than looking in the news directory, then in the 1997 directory, and returning the big_sale.html file to a user's web browser, the web server would run the news.cgi program, let it retrieve article number 10 from the database, and send back whatever text that program printed out.

All these differences required changes in the way that designers and developers approached the building of websites. But the benefits were more than worth it: dozens or even hundreds of files could be replaced with one or more database-driven scripts, as shown in Figure 1-3.

¡ndex.html includes

¡ndex.html includes about.shtml news.cgi about.shtml news.cgi database database

Figure 1-3. The move from individual files to database-driven scripts database database forums newssection contactform

Figure 1-4. The structure of an integrated, database-driven website

Even with those improvements, however, there were still serious challenges:

Where do I change that setting again?

Large sites with many different kinds of content (product information, employee bios, press releases, free downloads, and so on) were still juggling an assortment of scripts, separate databases, and other elements to keep everything running. Webmasters updating content had to figure out whether they needed to change an HTML file, an entry in a database, or the program code of the script. Too many little pieces were cobbled together

Dynamic content—such as discussion forums or guestbooks where visitors could interact—required their own infrastructure, and often each of these systems was designed separately. Stitching them together into a unified website was no simple task.

Was this article helpful?

0 0

Post a comment