WHAT IS CGI?

CGI stands for "Common Gateway Interface" and is a standard method (across all platforms and server types) to process input from HTML forms. A CGI script is either a (compiled) program or a script residing on a Web server which runs on demand when a form arrives from a user. It takes the data from the form, such as user's name, comments on a page or answer to a question and sends some response back to the user (like "Thanks for filling out our survey" or "Wrong again, dummy!") and can also save the data to a text file, send it to someone by e-mail or pass it along to somewhere else such as a database.

CGI has been around for a long time (actually since 1993, an eternity in Web time) and there are a good number of CGI scripts floating around as well as many books. It is an established standard and not likely to change (at least not in a way that will invalidate your existing scripts). In contrast JavaScript is more recent (first release in 1996) and is still evolving. Another new kid on the block are Server API's (API stands fro application program interface). These are (mainly) proprietary interfaces to specific kinds of servers, which offer enhanced performance and a direct tie-in to the server. Examples are NSAPI form Netscape, ISAPI from Microsoft and W*API from WebStar. The disadvantage to API's is that generally they must by written in the C programming language and they work on only one vendor's servers. Another server-side option is Java, which runs both locally on browsers and on Web servers. Java is discussed in the next section.

What language are CGIs written in? Almost any scripting or programming language, although of course the language has to be one which runs on your Web server's platform. The most common language for creating CGI scripts is Perl (stands for "Practical Extraction and Report Language" -- sound like something your dentist would enjoy?). Perl is a very flexible and powerful language and is especially good at handling text (doing sophisticated search and replace with wildcards, for example). It also has the advantage of running on all platforms (sometimes requires small modifications to port form one system to another). I like to try out new Perl scripts on my Mac Powerbook, where I can run both server and browser locally, then upload the script to the university Unix server once it's working. That way I can get the bugs out before crashing the university's server.

Another cross-platform option is C or C++, a complex programming language whose learning curve is probably prohibitive for folks who want to have a family life. However, if you have the time and ambition, C will offer the best performance in CGI's. On Windows Web servers Visual Basic (VB) is often used for CGI's. If you're worked in VB already, this is clearly the way to go, if not it may not be as good a choice as Perl if you're thinking in terms of educational use where you'll likely be doing a lot of text parsing and processing. There are a good number of VB scripts available off the Internet as well as scores of books. Microsoft is the patron of VB so it is likely to be around for a while. In fact Microsoft has introduced VBScript as a competitor to JavaScript. VB does not run on Unix or Mac servers.

On Mac servers a variety of languages are used, most commonly AppleScript and Frontier. Of all the possible CGI languages AppleScript is the easiest to learn. As compared to Perl or C you can actually read and understand most scripts written in AppleScript. The commands actually look like English (rather than cryptic geekspeak). By the way, there are versions of AppleScript for many different (human) languages. So you could write your AppleScript CGI in French or Spanish. You can pick up AppleScript especially quickly if you're worked at all in HyperCard or Toolbook -- the syntax is very similar. As matter of fact you can also use HyperCard to write your CGI's; versions 2.0 or higher allow you to write your scripts in Hypertalk or AppleScript.

Another popular CGI choice on Mac servers is Frontier. Frontier has a steeper learning curve than AppleScript, but it runs faster, has more built-in functionality, and is multi-threaded. Multi-threaded means that the CGI can service more than one user at the a time. Otherwise a new user must wait until the CGI is done with its current user. This is actually in most cases not as big an issue as it may sound. Most CGI's execute in a couple of seconds; the ones which take longer are probably writing data to a log file or database, operations which normally can only happen one user at a time. Frontier is also now available for Windows.

So which language is best to use for CGI's? It depends. You first need to know what platform your Web server is running on and, most importantly, which CGI language your Webmaster supports. This may limit your choices dramatically; in most university settings that will boil down to Perl. How do you win back your freedom of choice? Simple, set up your own Web server, an absolutely doable proposition. If you do have access to your own server (run by regular folks and not fierce Unix gatekeepers) there is the very real option of running CGI's written in a variety of languages. In contrast to humans, CGI's of different origins can co-exist peacefully in the same environment. Our departmental Web server, for example, runs Perl, AppleScript and Frontier scripts. This lets you take advantage of the particular strengths of each language and to accommodate individual choice in writing CGI's.

My recommendation? Perl, if you're willing to take some time to learn the syntax. It's said that Perl scripts are easy to write but hard to read. This is because there are so many syntactical shortcuts in Perl, which make it comp[act and efficient, but also makes scripts read like hieroglyphics. It's best in starting out not to spend your time staring at complex scripts, trying to decipher what's going on. One of the strengths of Perl is that there are many possible ways to reach the same goal. In fact, Perl is astonishingly flexible and forgiving (for a programming language). The text handling tools are first-rate and will allow manipulation of text in about any way you can think of. An excellent starting point for learning Perl is Randal Schwartz's wonderfully short and concise Learning Perl. By the way, Perl was created by a linguist (Larry Wall) - no wonder it's good!

The exception to the above recommendation concerns folks running a Mac Web server, or interested in setting one up, for whom AppleScript makes the most sense, at least as a starting point. It's by far the easiest CGI language to learn. As with Perl, there are a number of scripts available on the Internet, as well as an excellent on-line tutorial (see Trailmarkers). The examples in this trail guide are written in Perl and AppleScript.

What if you change later to a different language? All is not lost, by any means. If you use a different language -- or even a different platform -- much can be transferred. The syntax will be different but the basic principles will be the same. The hard part is actually not how to write the scripts, but conceptualizing what is going on, understanding the interaction between server and browser, getting a grasp on how to structure the user's interaction through the use of control structures (such as "if...then" or "for...each") and finding out what's doable in terms of user interactions. These aspects of creating and using CGI's are common to all possible languages. This will be the emphasis in my discussion of sample CGI scripts on this page. I'm not going to try to teach the rules of syntax -- there are plenty of books where you can get that information.

Good question and one to consider seriously before jumping into learning Perl or any other CGI environment. CGI scripting isn't rocket science, but it does necessitate delving deeper into technology than most language teachers every dreamed of going. Do you have the time to devote to something that isn't going to bring any immediate professional rewards? Do you have the patience and gumption (and lack of common sense) to keep banging your head against a wall in trying and trying to get your CGI script to run right (only to find you left off a semi-colon in line 199)? Most importantly, do you own a pocket protector?

Writing CGI scripts clearly does put you in the nerd camp, but that's not all bad. It can be an immensely satisfying, even thrilling experience to see your little program run successfully across the Internet! Writing computer code can be an isolating experience (and usually is) but it can also be intellectually stimulating -- coding thrives on logical thought and ingenious problem-solving. There are usually many different possible solutions or work-arounds to program roadblocks, it's just a matter of thinking the process through and experimenting. Finally, as the Web becomes more and more a ubiquitous presence, it's nice, not to mention useful, to know what's going on behind the scenes, to get a sense of what the possibilities of the technology are. If we as language teachers have no idea of the basic rules of the road in what's become the information (and education) superhighway, we'll likely to be left behind (or run over).

So what can I use CGI for in my teaching? I'm hesitant to answer that question in concrete terms (although of course I will) because in suggesting specific CGI applications, I'm pigeon-holing the technology in a way that may discourage finding new paradigms. In fact, most of the CGI uses you'll see on the Web are generic and predictable (guestbooks, e-mail to Webmaster, site registration) and don't begin to tap the power inherent in the Web server-browser relationship. Some of the more evident uses of CGI in language learning include on-line comprehension testing, collaborative writing or automatic creation of student home pages.

But there are potentially many more uses. Integrating CGI and multimedia could be of obvious interest to language teachers, for example, using audio feedback in response to student input. Tracking student performance on Web-based activities could also be done with CGI's; a monitoring system could then automatically trigger recommendations (for review, further study, additional help) based on certain performance criteria. Using a database to store and access the student information offers a very powerful information retrieval system. Combining the powerful hypertext navigation of the Web with the flexibility of CGI scripts to deliver customized information based on user choices could enable a truly student-centered learning environment, one in which students discover their own best learning style and are able to apply it in working with the material they are to learn. One concrete example is a comprehension testing environment in which students decide on their feedback options, rather than being strait-jacketed to the generic feedback usually used in such programs.

Another issue to consider is whether the kind of interactions you have in mind are best accomplished using CGI or perhaps could be done better and more easily in other ways. An interactive grammar exercise constructed with a CGI will be no match in speed or functionality for one written in Toolbook or HyperCard. On the other hand, the CGI version would be more readily accessible, from any kind of computer and from any Internet connection. If those issues are important for you, of if you want to keep a centralized record of access to certain course materials, CGI is something to consider. But if you know students will only be doing the exercises in your PC lab, then Toolbook would be a better way to go. Of course, as discussed in a previous page, it makes sense to consider integrating when possible external applications into your Web pages, a process that's becoming easier all the time. There are in fact browser plug-ins for both HyperCard and Toolbook.

Another interactive option to consider, which is less demanding to learn, is JavaScript. JavaScript can provide feedback in a greater variety of ways than CGI and it's faster because all the interaction is local. The fact that it's local also means it can bypass the fickleness of a network connection. On the other hand, JavaScript does not allow for the submission of student work. It is also not secure -- the source code can be easily viewed. If you want to do any kind of formal assessment over the Web, CGI's are the best choice. Probably the best configuration is a combination of JavaScript and CGI. JavaScript could be used to do preliminary (local) processing of student input and then a CGI could save or record the student's work on the Web server. You could also use a CGI to serve up a user-customized JavaScript to the student.

There are three requirements:

1. Basic knowledge of HTML (to write the forms)
   
2. The right editor or compiler for the CGI language you are using
   
3. Access to a Web server, which will allow you to upload and run your scripts

You may find that the last item represents the greatest stumbling block. Web servers, or more properly HTTP (Hypertext Transfer Protocol) servers run on a variety of platforms, but most commonly on Unix computers, whose administrators are notoriously leery of allowing plain folks to run scripts on their systems. It's not just paranoia or territorial protection, a misbehaving CGI can wreak havoc on a system (going into an endless loop, for example, and eating up all the system resources). This is no big deal if it happens on your own PC -- you just reboot -- but if it means everyone's Web and e-mail server has come to a screeching halt, you won't win any popularity contests on campus. It's a big advantage if you have a local machine you can try your scripts out on before posting them to a Web server in production. There are many different servers which will run under Unix, the most popular being the NCSA and Apache servers. Both are free, as are, to educational institutions the Netscape servers. The latter are particularly easy to set up and run (if you consider anything on Unix easy).

More user-friendly platforms like Windows and Macintosh also have high performance Web servers. You'll probably see your university computing folks sneer at the mention of a non-Unix Web server, but that's just because they're Unix bigots and are judging something they know nothing about, or are basing their views on the early versions of Web servers for Windows and Macs, which did not come close to matching the performance of Unix servers. If you're expecting 10,000 hits a day on your system (say, for example, you're running bootlegged French versions of Playboy), then you're best off with a Unix server. But if you're thinking of setting up a server for your department or unit, a Mac or Windows server will serve you well and will be significantly easier to set up and administer.

Windows95 and WindowsNT are viable Web server options with NT gaining fast in popularity. I would recommend an NT machine, even though that means a higher-end machine than you might have available; the operating system, like Unix, is designed to be multi-user and so lends itself very well to being used as a Web server. The latest version of NT is nearly identical to the Windows95 interface so for Windows users will be easier to learn. Many of the Unix servers have NT versions, including Netscape. Microsoft includes the Internet Information Server (IIS>) with WindowsNT.

If you want to run a Mac-based Web server, I would recommend a PowerMac with 32 MB of Ram. There are not as many servers which run on a Mac but one excellent choice is WebStar, the commercial successor to MacHTTP, which is still available as shareware, as is QuidProQuo. WebTen implements the popular Apache server on the Macintosh operating system. Of all the systems, a Mac Web server is the easiest to install and operate. Surprisingly, it is also the most secure. The Macintosh is meant to be a single-user computer and as a result does not have some of the potential security problems of Unix and NT servers.

What does it take to set up your own Web server? This is not nearly the daunting task it may seem or that it used to be. In fact, the most recent Web servers on all platforms are user-friendly to install and operate; most can be administered over the Web. Contrary to popular belief (and to what job-seeking information technology professionals would like to have you believe) you do not need a dedicated professional to run your Web site. It's honestly not that hard. It does require that you have a computer with a permanent Internet connection (modem access is not a good solution) which you leave on. That machine initially does not even have to be a dedicated server -- you can continue to run your own programs while it quietly dishes out Web pages in the background. In fact, I envision that in the not-too-distant future many of us will be operating personal Web servers on our regular PC's and that this will be as common as running your own word processing program. In fact, several personal Web servers are now available; Microsoft's FrontPage HTML editor has a built-in Web server, as does Apple's MacOS 8.

Assuming you have server access, the first step is to write your form. This is the easy part. The syntax for constructing forms and form fields is no different than it is for other HTML elements. Since this is covered in all HTML on-line guides and books, I won't go into detail on form elements here -- much of the syntax will be readily apparent in the examples later on this page. I'll just mention a few essentials. All the parts (elements) of your form must be between "<form>" tags; form elements outside those tags -- like a checkbox -- won't be recognized properly. At a minimum your form must contain a form element (a text box, radio buttons or a checkbox) and a submit button. You must also specify in the opening form tag the name of the script which will process the data from the form. If the script is in a different directory from the HTML files containing the form, you will also have to give the path to that script.

How do you actually write the script? You need to have an appropriate editor or compiler for the CGI language you're using. If you're running Perl, use any text editor or word processor, as long as you save the file in text (ASCII) format. For AppleScript you will need to have the ScriptEditor, which comes as part of the MaOS. You will need to save your scripts in the ScriptEditor as "applications" and check "stay open" and "never show" -- this allows them to run inconspicuously in the background. On Macs, you should give your scripts either a ".cgi" or ".acgi" file extension. The latter designate an "asynchronous" CGI which simply means that the server continues to do other things as it's processing the CGI request. Otherwise (with ".cgi") the server processes the CGI before doing anything else. The best way to get started is simply to look at some scripts to see how the processing works. In addition to the examples here, I would recommend that you browse some of the collections listed in the Trailmarkers section.

We'll start with a minimal CGI which has a student fill in an answer to a question.

[Figure 4-1]

The idea is that the student reads the story and then writes in the answer to the question as to the relationship between the boy and the woman (she's his aunt). The HTML looks like this:

<title>Hans Huckebein Lesekontrolle</title>
<center><h1>Hans Huckebein Lesekontrolle</h1>
<form method=post action="testquiz.cgi">
<img src=hans10.jpg><br>
Was ist das Verh&auml;ltnis der Frau in der Geschichte zu dem Jungen?<p>
<input name="answer"><p>
<input type=submit value="Antwort einsenden"> <input type=reset value="Neu anfangen"><p>
</form></center><hr>

The name of the script that processes this form is "testquiz.cgi", as indicated in the opening form tag. The script does two things -- checks the student's answer for the correct response "Tante" (aunt) and save the results to a log file (in this case an HTML file). If the student answers correctly, positive feedback is given, if not, the student is asked to try again. Here's an AppleScript version of the script:

 on <<event WWW sdoc>> path_args  
   given <<class kfor>>:http_search_args, <<class post>>:post_args, 
     <<class meth>>:method, <<class addr>>:client_address, <<
     class user>>:username, <<class pass>>:|password|, <<class 
     frmu>>:from_user, <<class svnm>>:server_name, <<class svpt>>:
     server_port, <<class scnm>>:script_name, <<class ctyp>>:content_type
   set crlf to (ASCII character 13) & (ASCII character 10)
   set http_10_header to "HTTP/1.0 200 OK" & crlf & "Server: WebStar" & crlf &
     "MIME-Version: 1.0" & crlf & "Content-type: text/html" & crlf & crlf
   set formData to parse CGI arguments post_args
   set answer to CGI field "answer" from formData default value "(no answer)"
	
   set f to open file alias "Macintosh HD:WWW:Huckebein:testquizlog.html"
   position file f at (get file length f)
   write file f text ("<b>Name:</b>   " & username &
     "<br>" & "<b>Your answer:  </b>" & 
     answer & "<br><B>Date:</b>  " & (current date) & "<hr>")
   close file f
	
   if answer contains "Tante" then
     return http_10_header & "<title>Huckebein Lesekontrolle 1</title>" &
    "<body bgcolor=FFFFFF><center><h2>Huckebein Lesekontrolle 1</h2>" & 
    "<font size = +1>JAWOHL, sie haben Recht!</font>"
   else	
     return http_10_header & "<title>Huckebein Lesekontrolle 1</title>" & 
     "<body bgcolor=FFFFFF><center><h2>Huckebein Lesekontrolle 1</h2>" & 
     "<font size = +1>Nein; versuchen Sie es nochmals!</font>"
   end if	
 end <<event WWW[Omega]sdoc>>

The script is framed by an "on..." and "end..." statements which simply tell the script to activate (or stop) when an action takes place, in this case when a CGI request ("event WWWsdoc") is received. The first two paragraphs are standard across all AppleScript CGI's and can simply be copied and pasted to any new script (they tell the script what kind of data to expect from the user and what HTTP header to include in responding to the user). The next paragraph uses an AppleScript "scripting addition" called "ParseCGI" to take the data sent from the browser and extract from it what the student typed in the field "answer". Normally a form submission will include data from a number of fields, each of which will have to be parsed (sifted) to extract the value the user entered. A nice feature of "ParseCGI" is that it automatically hands 8-bit characters, so has no trouble dealing with accented characters (or Japanese, for that matter).

The next paragraph opens a log file, goes to the end of that file and records the data sent by the student (i.e., the "answer"), as well as the student's name ("username") and the time and date ("current date"). The student's name will only be recorded if this file is in a protected "realm" on the server, that is, if it requires a login and password to gain access. If you're using CGI's in instruction, this is an option you'll probably want to use. It allows you to control access to your page as well as to record, as here, student activity.

The next part of the script between "if" and "end if" ascertains whether the student has answered the question correctly (actually if the word "Tante" appears anywhere in the response) and returns appropriate feedback to the user. A CGI must always return something to the user, even if it's just a confirmation that the data was received.

Here's the same CGI in Perl:

#! perl
require 'cgi-lib.pl';

&ReadParse;

$header = <<HTTP_HEADER;
HTTP/1.0 200 OK
Server: Webstar
MIME-Version: 1.0
Content-type: text/html
HTTP_HEADER

print $header;

$username=$ENV{'REMOTE_USER'}; 
$answer = $in{'answer'};
$logfile = "Macintosh HD:WWW:HUckebein:testquizlog.html";

open(LOGFILE,">$logfile")
print LOGFILE "<b>Name</b> $username <br><b>Your answer: </b>$answer";
print LOGFILE "<br><b>Date:</b> &Date <hr>";
close LOGFILE;

print <<"header";
<HTML><HEAD><Title>Huckebein Lesekontrolle 1</Title></HEAD>

header

print "<BODY BGCOLOR = FFFFFF><center><H2>Huckebein
Lesekontrolle 1</H2>";
if ($answer eq "Tante") {
	print "<font size = +1>JAWOHL, Sie haben Recht!</font>\n";
} else {
	print	"<font size = +1>Nein, versuchen Sie es nochmals!</font>\n";
}

The first line simply declares this to be a Perl script, The next indicates that here, too, we are drawing on an external helper, in this case the Perl "library" called "cgi-lib". There are a number of Perl libraries or modules specifically written to make creating CGI's easier. Other good Perl module are "cgi.pm" and "libwww". Both "cgi.pm" and "cgi-lib.pl" handle 8-bit characters. The next line calls on a built-in Perl sub-routine (ReadParse) to feed the input to the script. After the header is defined, the "answer" field is parsed, the answer evaluated and feedback returned.

Not bad, is it? There are additional examples in the Li Scripts, most of which are a good bit more complex, but follow the same basic pattern. The scripts include extensive comments, which explain why the different elements of the script are there and what they do. The "makepage" and "revisepage" scripts (AppleScript) allows students to create home pages without learning HTML. The three WebChat scripts create a bulletin-board style discussion forum.

Yes, this is possible, by using existing CGI scripts which you can customize to your needs. There are actually three possibilities:

1. Heavily commented CGI script, clearly indicating what and where to make changes, essentially a template
   
2. CGI scripts which create a CGI script
   
3. Generic CGI which gets its values from an HTML page

The first method is actually what I had in mind with the scripts included in the archive. This actually still takes a good bit of knowledge of CGI and access to the appropriate editor/compiler. The second option is one I've been working on for a project called Web Course in a Box. One of the features is a CGI form which allows instructors to create a discussion forum. It looks like this:

[Figure 4-2]

What's created when an instructor fills out a form is a CGI-based discussion forum customized for that teacher's class (example).

The third option is to have the CGI write generic scripts which are configurable from a Web page. That is to say, that the CGI gets the appropriate values from hidden files in the HTML and delivers a customized Web page or CGI. In the example below is another customizable discussion form -- this time the customization is done by changing values to hidden HTML fields.

<! -- Customizable WebChat -- enter your data only where indicated>
<html><title>WebChat</title>

<! -- Enter your course info>
<center><h2><i>WebChat</i> for Klingon 101 - Fall, 1996</h2>

</center><form method=post action=webchat.acgi>
<p><b>Brief title for message:
<br><INPUT TYPE=text name=studenttitle size=40 maxlength=40>
<br>Message:</b>
<br><textarea name=studentstuff rows=5 cols=65></textarea>
<br><input type=submit value="Post message">
<hr>

<! -- Enter the name of the log file for your class>
<INPUT TYPE = hidden NAME = commentlist value = "webchat.html">

<! -- Enter the path to the file>
<INPUT TYPE = hidden NAME = filepath value = "Macintosh HD:WWW:wc:">

<! -- Enter the URL of your Web server>
<INPUT TYPE = hidden NAME = pageToReturnPath value = "http://www.fln.vcu.edu/wc/">

<! -- Enter your course info below>
<INPUT TYPE = hidden NAME = relativePathToStudentPage value = "../gj/201/">

<! -- Enter the path to your students' pictures>
<INPUT TYPE = hidden NAME = relativePathToStudentGifs value = "/gj/201/"></form>

<! 0>
</html>

To use this form, the instructor still needs some basic information about file locations, but that shouldn't be too difficult to ascertain. Using templates like these offers a great deal of functionality and a good starting point at the cost of not having any say in the design or functionality of the pages. Keep in mind, however, that the cookie-cutter approach to CGI's may provide useful functionality but it doesn't begin to tap into the potential of CGI's for creatively using the Web in teaching.

There are now a multitude of ways to create Web animations:

1. GIF files, either played one time or looped (Gif89a format)
   
2. Plug-ins such as Shockwave Flash
   
3. JavaScript
   
4. Java
   

The simplest method is the first. There are a number of freeware tools which allow you to designate a series of GIF files to constitute an animation. This method is known as animated gifs and does not allow you to pace the animation -- how fast it runs depends on the network connection and speed of the server. The other options give you more control but at the price of learning how to do animations with those programs. Java has a template tool called "Animator" which is easy to use and allows you to designate a group of files to animate. Don't overdo animations; they can spruce up a page, but can also get tiresome very fast. There are some interesting possibilities for using animations in language learning -- animating sentences being constructed or illustrating other structural points.

Information/Tutorials/Tools

Common Gateway Interface
The CGI FAQ
CGI Extensive list from Yahoo
CGI Annotated links to CGI info from WWW virtual library
Common Gateway Interface Basic info from NCSA
Windows CGI 1.1 Description Info on using Visual Basic
Perl for Windows NT
Extending WebStar with AppleScript Good tutorial from Jon Widerspan
Diana Oswald's tutorials on CGIs for Mac servers (AppleScript, Frontier)
Felipe's AppleScript CGI Examples
CGI Library C library from EIT
Pierre's Web Tips authoring tools and links to CGI tutorials

Examples/Collections/Demos

Jeu de "Qui suis-je ?" Découvrez quel animal vous êtes en posant des questions.
Self-Study Quizzes for ESL Students Large collection of quizzes
Scripts of Forms/Scripts for Langauge Learning The companion page to this Guide
Scripts using MaxAuthor Windows-based authoring system from the University of Arizona
Fluency through fables ESL exercises

Animations

GIF89a-based Animation for the WWW
Java animator
Clipart.com
AndyArt
Yahoo Clip Art
GifBuilder
Gif Construction Kit