In Dynamic Behavior And Scripting, I said that server-side scripting was beyond the scope of this book—and it is. But I really should give the concept itself a rundown and introduce some of the more common languages.
Simply put, a server-side script is what the server uses to create—or at least assemble—the code for your webpage before sending it to a browser. Server-side scripting, then, is writing or using a server-side script.
Since a server-side script essentially writes the code for you, it is essential for you to have a knowledge of (X)HTML, CSS, or whatever language you want the server-side to write for you—you have to instruct the server-side script what to write!
File Extension: .shtml
The only server-side language I'll demonstrate at all is Server-Side Includes—SSI for short—since it's the simplest server-side scripting language I know of and it illustrates the concept of server-side scripts reasonably well.
SSI takes the contents of various text files and assembles them into a single HTML document. I say HTML
because that's about the only language SSI is used with—and if you use XHTML code with SSI, the page will still be read as HTML unless the server is instructed otherwise.
Because the browser is only sent the fully-assembled page, the page's elements do not have to begin or end in the same text files, they only need to be complete in the finished product.
So what would be put into these text files? Well, back in Procedures, I stated one reason procedures were used was so that code used repeatedly didn't need to be typed every time it was needed.
SSI uses the same concept; in this case the code is (X)HTML and used repeatedly
means used on multiple pages
.
The most common things to be repeated are:
Here's an example, showing a page with most of its head in one text file, its navigation in another file, and a footer
containing some script
elements and the end of the document. Note that the extensions of all these are .txt, which means they are plain text files. This is fine; when the page is sent, they will be read as HTML. The only time the extension matters is if a file to be included use SSI itself; then you have to use the .shtml
file extension.
html
lang
="en"
dir
="ltr"
>head
>meta
http-equiv
="Content-Type"
content
="text/html; charset=utf-8"
>meta
http-equiv
="Content-Style-Type"
content
="text/css"
>meta
http-equiv
="Content-Script-Type"
content
="text/javascript"
>base
href
="http://www.mywebsite.com"
>link
rel
="stylesheet"
type
="text/css"
href
="./Formatting/setup.css"
>link
rel
="stylesheet"
type
="text/css"
href
="./Formatting/screen.css"
media
="screen"
>link
rel
="stylesheet"
type
="text/css"
href
="./Formatting/print.css"
media
="print"
>ul
id
="Navigation"
>li
id
="Home_Link"
><a
href
="home.shtml"
>Home</a
></li
>li
id
="About_Link"
><a
href
="about.shtml"
>About</a
></li
>li
id
="Links_Link"
><a
href
="links.shtml"
>Links</a
></li
>ul
>script
src
="./hovers.js"
></script
>script
src
="./nav_hilites.js"
></script
>body
>html
>Important note: The demonstrated code above contains the entire contents of those files; I have left nothing out. If these look like incomplete HTML files, that's because they are.
Notice the use of the base
element in head.txt
. In Comments, HTML, Head and its Children, Body, I mentioned this element and said it established an absolute URI to calculate relative URIs. This is where it comes in really handy—head.txt
could be used in any document using server-side includes, so the link
elements would run the risk of pointing to the wrong file or a non-existant one—except the base
element establishes exactly what their URIs are relative to.
The command to include a file is fairly simple, and looks a cross between a start tag and a comment.
Below, I show what home.shtml
looks like.
home.shtml
Filetitle
>Home Page</title
>head
>body
>div
id
="Content"
>h1
>Home Page</h1
>p
>Welcome to my home page!</p
>div
>It appears a lot is missing here: the start tag for the head
element, the end tag for the body
element, both tags for html
, the Doctype itself...
Actually, they're there alright; they are simply in the files to be included instead of home.shtml
itself. The Doctype and the start tags for html
and head
are in header.txt
, while the end tags for html
and body
are in footer.txt
.
The diagram below shows how the server assembles the page according to the SSI commands, and the code below the diagram is the result.
html
lang
="en"
dir
="ltr"
>head
>meta
http-equiv
="Content-Type"
content
="text/html; charset=utf-8"
>meta
http-equiv
="Content-Style-Type"
content
="text/css"
>meta
http-equiv
="Content-Script-Type"
content
="text/javascript"
>base
href
="http://www.mywebsite.com"
>link
rel
="stylesheet"
type
="text/css"
href
="./Formatting/setup.css"
>link
rel
="stylesheet"
type
="text/css"
href
="./Formatting/screen.css"
media
="screen"
>link
rel
="stylesheet"
type
="text/css"
href
="./Formatting/print.css"
media
="print"
>title
>Home Page</title
>head
>body
>ul
id
="Navigation"
>li
id
="Home_Link"
><a
href
="home.shtml"
>Home</a
></li
>li
id
="About_Link"
><a
href
="about.shtml"
>About</a
></li
>li
id
="Links_Link"
><a
href
="links.shtml"
>Links</a
></li
>ul
>div
id
="Content"
>h1
>Home Page</h1
>p
>Welcome to my home page!</p
>div
>script
src
="./hovers.js"
></script
>script
src
="./nav_hilites.js"
></script
>body
>html
>And voilà: four incomplete HTML documents become a single complete one. In this case, there's no sign to tell where one file ends and the next begins—you have to compare this to the constituent files; since most users won't (and shouldn't) have access to those files, they won't be able to do that comparison.
You will also notice that the include
commands are nowhere to be seen in the final result. If they are, then something's amiss; a server's processing instructions should not appear in the browser.
Since the code for the header, navigation, and footer comes from a single file, you only need to edit that file; the server-side instructions will cause that to affect every page that uses that particular file, much like changing an external stylesheet will affect every page that uses that stylesheet.
It's important to remember that when a text file is included, all its contents end up in the final result. I remember seeing the code of a webpage created by someone who thought every file containing any HTML code required a Doctype; the home page ended up with eight of them scattered throughout the code...
It wasn't pretty.
Static content always remains the same, since it is based on the coding of an HTML document or its perephiral files (such as stylesheets or scripts). Even if you interact with a webpage through JavaScript, the code never changes; reload the page and it's all back to normal.
Dynamic content, on the other hand, can change; the very code the browser receives can be altered without the document's code being touched. One example (again used in SSI) is when a page was last modified. This particular instruction is:
File Last ModifiedCommand
When the server encounters this command, it will check the file (in this case, links.shtml
) to see when it was last changed. This might look like static content at first glance—particularly if the file hasn't been updated in a while. But when it is updated, the information from the server regarding this command will change. Thus, dynamic content. A very popular use of this command is:
File Last ModifiedCommand
p
>Links updated on <!--#flastmod file="links.shtml"-->.</p
>If the page was created at around a quarter after three in the morning on August 4, 2009, that paragraph would read something like Links updated on Tuesday, 04-Aug-2009 03:14:16 Mountain Daylight Time
. If it was updated on September 5, 2011 at 11:20 AM, the paragraph would then read Links updated on Monday, 05-Sep-2011 11:20:28 Mountain Daylight Time
.
A note here: Mountain Daylight Time
refers to the time zone I'm in as I use that command to get an SSI timestamp.
A look at the code sent to the browser would show the following:
File Last ModifiedCommand
p
>Links updated on Monday, 03-Aug-2009 03:14:16 Mountain Daylight Time.</p
>p
>Links updated on Monday, 05-Sep-2011 11:20:28 Mountain Daylight Time.</p
>But let's say that this bit of coding was in index.shtml
. It was links.shtml
that was edited, not index.shtml
, yet the content of index.shtml
has changed. This is because the server sent different information to the browser due to the SSI command pertaining to the last update of links.shtml
. That is an example of dynamic content.
While every server-side language I know of has a means of assembling files into a webpage as SSI does, other server-side languages are far more widely used for one simple reason: they are much more powerful than SSI. Not only can they assemble text files, they can read those files and interpret the contents, they can get information from sources that aren't text files (such as databases), and actually generate code rather than simply assembling it.
Here's an example: When I created this book's full outline, I wrote a PHP program that opened up Prologue.html
and read its code. From that code, it was instructed to:
meta
element that states which part of the book the chapter belonged to (for example, the beginning, Cascading Style Sheets, Appendices, etc.) and check if the part name had changed; if it had, the program was to start a new list of chapters.h1
element, create an li
element containing that title,h2
to h6
) to build an outline of the chapter by generating nested ordered lists, which are contained in the chapter's respective li
element.link
element that states which file was next in the sequence of chapters (that is, had the attribute rel="next"
) (if it didn't find such a link
, assume there were no more chapters).I then saved that webpage as an HTML document, saving myself a lot of tedious and error-risking work.
Just a note here: I know I clang on a lot about validation, but this time it was very important: Very often, a server-side script that processes a markup document will have to know its rules. If your document violates those rules, your script will run into trouble and may print out errors.
Common Gateway Interface, or CGI, is a way where the generation of code (not just (X)HTML, but also CSS, JavaScript, and even images) can be assigned to a program, which means virtually any programming language ((X)HTML is a markup language, not a programming language) can be used as a server-side language—the only question becomes which language should be used. Here are some of the more popular ones.
Most other languages are much less popular for several reasons ranging from proprietary status to the unlikelihood of ever being used to simply being unsuited for this (or in the case of esoteric languages, any) purpose.
I'm not going to go into server-side scripting any further than I already have (I've only brushed the basics of SSI), but this should give you a rough idea of how server-side scripting works.