4.0 Finishing Touches
4.1 Common Gateway Interface (CGI) Scripts
A Common Gateway Interface (CGI) script, stored on the server, allows the server to respond to input from the browser--thus allowing you to collect information from people browsing your site, or to produce customized documents based on your guests' needs, or on events like mouse movements or clicks. Forms, imagemaps, interactive animations, download links, and search functions all rely on these scripts.
Before you can employ a script in your document, you'll need to find out
- whether your server will support the scripts,
- if so, whether you'll have access to the cgi-bin, and
- which programming languages can operate on your server,
and to familiarize yourself with the fundamentals of programming in that language. Some popular languages: Perl, the Practical Extraction and Report Language, which is great for slicing and dicing data any which way, but may open up security holes (if you're new to programming, try the Leeds Perl tutorial before hitting the bare documentation); Java, which allows you to create fairly secure crossplatform applets (to supplement your HTML documents), customized user interfaces, or standalone applications (check out this excellent Java tutorial, or try to Teach Yourself Java in 21 Days with this handy book/CD combination); and Netscape's JavaScript, which provides some of the same interactive functions as Java applets, but is interpreted by the server, so it sucks up RAM but doesn't need to be compiled before it runs.
Depending on your platform and the configuration of your server, one of these resources might help you. NCSA provides some excellent documentation on using CGI scripts.
If you're not careful, unscrupulous people can worm their way into your server's files and create havoc, so familiarize yourself with some of the cracker moleholes and how to seal them. This Java applet security FAQ shows you how your browser responds to applets with attitude .
4.1.1 Imagemaps
When you just want to use an image as a "button" for a hypertext link, you know what to do: just put the <img src="url"> tag <a href="path/file.name">here, inside the anchor, instead of text</a>.
But if you want to link different parts of an image to different documents, you'll need to do four things:
- Select an image: The image you use as a map should have distinct sections; otherwise, people might not be able to tell where one link ends and another begins.
- Create an imagemap file:
- You'll need to decide which document each section of the map will conjure, and to measure the coordinates of those sections (using an image-editing program):
- For circles, record the radius (in pixels) and the coordinates of the center point.
- For rectangles, record the coordinates of the upper-left and lower-right corners.
- For other polygons, record the coordinates of each corner.
- For a single point, record the coordinates of that point.
- Once you've gathered this information, document it in a map file according to the conventions of your server. Some browsers now support client-side or internal imagemapping; that is, they allow you to include your map script in your main document. But since this isn't yet standard practice, your best bet is to back up your internal imagemaps with a script installed on your server. For more information, you can read about client-side imagemaps in HTML 3.0, or about server-side imagemapping with the NCSA and CERN servers.
- Link the inline image tag to the URL of the map file: place the <img> tag, with the ISMAP attribute (<img src="????.gif" ismap>) inside your anchor to the URL of your map file. The final result should look something like this:
<a href="../path/cgi-bin/directory (imagemap, for NCSA; for CERN, htimage)/mapfile.name"> <img src="????.gif" ismap></a>.
- Provide the same links somewhere in your text, for the benefit of visitors using text-only browsers.
For more information, visit Imagemap Resources or NCSA's Imagemapping Tutorial.
4.1.2 Forms
If you wanted to find out the names, ages, e-mail addresses, and three favorite flavors of visitors to your site, you'd need a form to collect and process all the different kinds of data.
Forms are bounded by the <form method=POST action="URL of script">...</form> tags. The method= attribute has a value of post (preferred) or get (the default), and the action= attribute indicates the URL of the script that will process the form data. Within the form tags, you may include a range of <input>:
- Text input fields will accept a single line (or a selected number of characters) of text, and are displayed as a box (the length of which you can specify);
<input type="text" name="[your name for this data]" size="[width of display, in characters]" maxlength="[maximum number of characters accepted]">
- Textarea fields accept multiple lines of text.
<textarea name="[name for data]" rows="[number of rows]" cols="[number of columns]"</textarea>
- Password fields mask the typed input with bullets or asterisks--but they are transmitted unmasked, so they offer only very limited security.
<input type="password" name="[your name for the data]">
- Hidden fields do not appear in the browser, so you can use them to carry information from one form to another.
<input type="hidden" name="[your name for the data]" value="[data]">
- Radio buttons require the visitor to choose only one of a number of options.
<input type="radio" name="[dataname1]" value="yes">
<input type="radio" name="[dataname1]" value="no">
- Checkboxes provide the visitor with a number of options, any number of which may be selected.
<input type="checkbox" name="[dataname2]">[Checkbox Label]
<input type="checkbox" name="[dataname3]">[Checkbox Label]
- Selections offer the viewer a scrolling menu of options:
<select name="[dataname4]">
<option>[option label]
<option> [option label 2]
<option> [option label3]
</select>
The multiple attribute (in the opening <select> tag) makes it possible to choose than one option.
The size="[#of options visible at once]" urges the browser to display a certain number of options in a scrolling list.
- Submit button sends the data to your server
<input type="submit" value="[button label]">
- a Reset button, surprisingly enough, returns the form to its original state.
<input type="reset" value="[button label]">
You can also set defaults for text fields, with the value= attribute; and automatically preselect checkboxes and radio buttons with the checked attribute; or the first item in a selection menu with the selected attribute.
For more on how to integrate forms into your site, see the Case Western Reserve University Forms Page, The Web Developer's Virtual Library Forms Page, and the BigNoseBird.com Forms Tutorial.
4.1.3 Server-Side Includes
If you have access to your server, your documents can be automatically modified--to show, for example, the date the document was modified, the contents of a file with your address, or the size of the file--with a Server-Side Include (SSI). Rather than reproduce all the information you'll need to use any include on any server, I'll just refer you to the tutorials on SSIs for Server Administrators and SSIs for the Rest of Us Mortals.
4.1.4 Feedback
Maybe you don't want to bother with scripts at all. You can still get feedback if your server supports the mailto URL--just by making an anchor using "mailto:them@example.org" as the URL of an anchor. For example, to allow your visitors to mail the President of the United States, you'd include this anchor:
<a href="mailto:president@whitehouse.gov">Mail the President</a>
4.2 Keywords and Other Metacontent
With the <META> tag, you can alert search engines to some basic information about your document, like keywords, copyright, and a description of the content--or even another resource (a soundtrack, for example) to load automatically after a specified number of seconds.
The HTTP-EQUIV=, NAME=, and CONTENT= attributes allow you to select different types of metainformation and then to assign a value to each type:
| <META NAME="resource-type" | CONTENT="document"> |
| <META NAME="copyright" | CONTENT="a few words detailing the copyright"> |
| <META NAME="description" | CONTENT="a sentence or brief paragraph describing your presentation"> |
| <META NAME="keywords" | CONTENT="categories in which one might logically expect to find your site "> |
| <META HTTP-EQUIV="Reply-to" | CONTENT="address"> |
| <META HTTP-EQUIV="Expires" | CONTENT="expiration date"> |
| <META HTTP-EQUIV="keywords" | CONTENT="keywords"> |
| <META HTTP-EQUIV="refresh" | CONTENT="#of seconds delay; URL=[URL of resource file]"> |
The HTML Survival Guide's Indexing Your Web Site page offers more detailed advice.
4.3 Copyright and Other Legal Issues
In this age of mechanical reproduction, it's easy to ignore other people's intellectual property rights, and to leave your own rights unprotected. Ten Big Myths About Copyright Explained, the U.S. Library of Congress Copyright Office page, the EFF Blue Ribbon site, and the San FranZiskGo! Freedom page will help keep you on the safe side of the law.
4.4 Putting Your Page Up
If you're not running your own server or receiving free access from work or school, you'll need to find a service provider. The following criteria might help you choose one:
- Cost: What are the monthly rates?
- How much disk space is included, and what surcharges apply for additional space?
- What bandwidth do they offer? Will you be able to choose your own domain name or will you be relegated to
http://www.them.com/yoursite.html?
- What kind of technical support is included? Are the folks there friendly and knowledgeable?
- Will you have direct or indirect access to the cgi-bin, so you can keep tabs on the volume of visitors and create forms or other interactive presentations?
If you are running your own server, the NCSA HTTPd Tutorial and the CERN (aka W3C) HTTPd Overview may help you with make some decisions about configuration and security.
Once you have access to a server, you'll need to check your HTML (with your editor or an automated validation service), arrange your documents into directories, and transfer them to the server via ftp. Then, before your elation wears off, check your links and graphics. Sometimes your beautiful GIFs will not load in the proper format; other times strange cyberbugs or a misplaced capital letter will stall your hypertext.
OK, it's on the server and everything works--now what? Well, you'll need to publicize it, or else it will just sit there, all coded up with noplace to go. Here's how:
- visit related sites--or sites you really like--and drop a note to the authors, perhaps asking if they'd like to trade links, or if they'd be willing to check out your pages and give you some feedback.
- some search engines offer a standard form you can fill out to add your site to their indices.
- organizations like Broadcaster and Submit It! will distribute (at no cost) a description of your site to a variety of search engines.
- Tell all your friends; put your URL in your signature file and on your business cards; and, most importantly, create and maintain an excellent site, so your URL makes it to your guests' bookmark lists.
Happy Spinning!
http://www.transaction.net/web/tutor/tutor4.html
zisk@well.com
