Stuart Moulthrop
& Nancy Kaplan
University of Baltimore
School of Information Arts and Technologies ·
Revised 2008
Part 9: Server-Side Includes and Dynamic Pages
One of the many ways in which electronic text differs from print lies in its dynamic potential: Books and paper documents, once printed, are difficult and expensive to revise, but documents on the World Wide Web and other electronic systems can often be updated at will. Some consider this feature a weakness, since the dynamism of information on the Internet makes it more conversational or discursive than earlier forms of write-once, read-always encoding.
The point is open to debate. Developers of hypertext (Ted Nelson, for instance) have insisted that electronic documents should track their revision histories, enabling readers to check current claims against what was said before. Ordinary HTML does not automatically do this, so in today's imperfect world, the best advice is to distinguish between different contexts for information -- one that is more stable or lasting (the U.S. Constitution, for instance), and others that are more open to change (such as social networking sites, or blogs). Things that need to be said with relative permanence belong in print, but documents where change is an asset, such as product prices, catalogues, and stock reports, need the flexibility of digital media.
The idea of dynamic Web publishing emerged in the browser wars of the mid-90s, as companies like Microsoft and Netscape began to understand HTML as the leading edge of technologies requiring large-scale, enterprise-level strategies. These and other companies developed schemes for combining the familiar, static Web pages with which we've so far been dealing, with information extracted from organized memory stores, or databases. In most of these approaches, the contents of pages are assembled before the page leaves the Web server, so a common name for the product of this technology is Server-Side Include, often referred to as SSI.
SSIs come in many scales and flavors, from simple addition of standard, static page elements (navigation bars, copyright footers) to tables, forms, and other data-heavy elements featuring live data, updated on-the-fly over high-bandwidth connections.
More ambitious uses of server-side technology are beyond the scope of an introductory course, but we will consider some basic uses of SSI in order to introduce the concept.
- Solutions involving programming languages
-
In discussing Forms, we mentioned the Common Gateway Interface, which is a
structure allowing Web pages (and hence servers) to activate scripts and programs
written in common languages such as C, C++, and PERL. The popular scripting language
PHP (originally Personal Home Page, a way to customize pages for the Web)
approaches the same problem from a slightly different angle.
CGI and PHP scripts can perform
fairly complex manipulations of databases and information provided by the user.
- Middleware
- The middle in this name refers to the fact that these schemes typically
involve a second server program that creates composite pages.
This server stands between the user and the main Web server, hence in the
middle of the process.
The proprietary ColdFusion program (now owned by Adobe) is
a common form of middleware. Most major content management systems,
from developers like IBM/Lotus and Seybold, also contain or consist of middleware.
Open-source alternatives include implementations using the programming language
Java (not JavaScript) to manage the assembly of content.
Middleware servers such as Tomcat produce what are called
Java Server Pages.
- Plain and simple SSI
-
At its simplest, SSI involves nothing more than the name suggests: including
information from diverse sources in a virtual page, which is then
delivered by the server to the client. This basic approach is often preferable for individuals and small businesses,
because it makes the smallest demand on computational resources, and does not
require purchase of an expensive software suite.
The two most popular Web servers, Microsoft's .Net server and the open-source
Apache, both permit Web designers to work in this way.
- However, the most popular SSI solution for small and mid-size concerns is probably PHP. We'll discuss that one in some detail, as an example of what you can do with even modest server-side manipulation
The number of SSI schemes that have been developed over the years probably rivals the number of Web browsers (dozens, if not hundreds). Most fall into one of the following families:
9.3.1 · Code
Now for some good news: the code required to perform SSI on the author's level is just about as simple as can be. Here's a specimen:
<?php include("introLinks.htm"); ?>
This line tells a properly configured Web server to retrieve a Web page called introLinks.htm and insert it within the markup of the present page, in place of the instruction. (If you look at the markup for this page, you'll find something very similar, using a slightly different scheme, Apache SSI.)
The material in double quotes, within the parentheses, is a file path or URL. In the present example, the page to be included is within the same parent directory (folder) as the including page. However, we could do the usual business of file-path navigation to access pages stored elsewhere on our server.
In the example we're using, the source document -- the information that is to be included in the new, virtual page -- exists on the server as a separate file. It is named with the file extension .htm. This practice lets us include fully-formed Web pages if we like; but in our example, the source page is not fully-formed, but is instead only a fragment of a Web page. At one point early in the semester, the complete contents of introLinks.htm were the following:
<div id="linkText">
<a href="overview.shtml">Course overview</a>
<br />
<a href="syllabus.shtml">Syllabus</a>
</div>
This markup should be very familiar to you: it's an ordinary document division or DIV containing a series of outgoing link anchors. Each of these tags invokes a relationship to yet another document. The paths to these documents are written relative to the document in which the current fragment is included -- but since the source file for inclusion is on the same level of the file hierarchy as the including file, it's the same as if the source page were free-standing.
Notice what's not here: the HTML, HEAD, and BODY containers. Strictly speaking, the page introLinks.htm doesn't live up to its file extension. Though most forgiving Web browsers will display it, it is not a properly formatted Web page -- and so should more accurately have the file extension .txt. In fact, a simple include, containing basic HTML, will display properly even if its file extension is .txt; but in the interest of clarity, it's better to stick to .htm or .html if the included component is a Web page.
Now that you know how the source or included page is structured, you'll want to know something about the structure of the including page, specifically, where that magical include instruction goes. The honest answer is, just about anywhere you want. You can place an include in-line -- in the middle of a sentence -- if you like. If what you're including is a single item of data (a stock price, for instance), this may be desirable. In most cases, though, your include will probably constitute a block-level element, and so you'll place it wherever it logically belongs. The DIV in our example falls within the layout structure where it would be even if it did not contain a server-side element.
One more crucial detail needs mentioning. PHP actually has TWO conditions for performing a server-side include. The first is the occurrence of the include instruction. The second is a naming convention for the page in which the instruction occurs, or as we might call it, the base page.
THAT PAGE MUST BE NAMED WITH THE FILE EXTENSION .php.
If you forget this special consideration (as some of us do occasionally), your base page will render without any included material.
You'll recall that in our earlier discussion we said that SSI would work if the server is properly configured. The process of configuring a server differs with each software solution. Generally, though, certain instructions must be entered into the server's configuration file, and in some cases, plug-in modules may have to be copied into the runtime files.
We do not discuss these details because they belong to server managers, not Web designers and information architects, placing them outside the bounds of this class. Suffice it to say that the configuration details are relatively simple, and that many if not most server managers set them up as a matter of course.
In particular, most general-purpose Web servers support PHP, these days.
While server-side technologies allow you to create powerful and flexible suites of documents, there is also a down side, from an author's or editor's point of view.
Since PHP pages (or pages using any other sort of SSI technology) are composites, assembled by the Web server and some auxiliary program, they can't be viewed locally. That is, you can't begin writing an SSI page on your PC desktop, checking its progress by opening the file locally in your favorite browser. If you try this, you'll see only the base page without included material.
Workflow for SSI pages is therefore more complicated than for self-contained Web documents. You must upload your file to an active Web server -- ideally to a special directory on the server cordoned off for development, and not connected to the production domain -- in order to check your work.
Composition tools like Dreamweaver become very useful at this point, since they tend to automate the uploading process via File Transfer Protocol (FTP). Elsewhere in these notes, we take a dim view of Dreamweaver and programs like it, which offer to do your coding for you. If you're ready to work with SSI, however, then you're also ready for these more powerful tools.
So now you know how to work with Server-Side Inclusion using PHP. Why would you want to do this? What are some practical applications of the technology?
Have a look at the results of our example code -- after all, you've been looking at their first cousin (an Apache SSI) throughout the term:
This is the PBDS 660 main class page from Spring, 2004. As you might guess, the page is structured with two simple DIVs, left and right. The lefthand DIV (outlined in green above) holds the included element. As you've seen, this DIV contains a set of links.
We use this technique to build up a running list of links, adding more each week. By including the list of links from a single file, we can allow every class page to display the current, updated table of links at any point in the semester.
There are plenty of similar applications for SSI. Consider, for instance, how you might use this technique to create a current index for your Web log; and that's just the tip of the iceberg, really.
Index · Part 1 · Part 2 · Part 3 · Part 4 · Part 5 · Part 6 · Part 7 · Part 8 · Top
Course and Materials ©1997 - 2008 by Stuart Moulthrop
and Nancy Kaplan