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 for 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.
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 from one system to another).
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). 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 many 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. 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 compact 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.
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. The examples given here are written in Perl.
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.
WHY WOULD I WANT TO DO CGI SCRIPTING?
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 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 education 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 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 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, 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.
HOW DO I CREATE CGI SCRIPTS?
There are three requirements:
- Basic knowledge of HTML (to write the forms)
- The right editor or compiler for the CGI language you are using
- 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. Many 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 school, 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. The popular Apache server is also now available for Windows.
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 Internet Explorer), 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 Script Editor, which comes as part of the MaOS. You will need to save your scripts in the Script Editor 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 Links section.
CGI BASICS THROUGH EXAMPLES
We'll start with a minimal CGI which has a student fill in an answer to a question. Solve this tough problem: 2 + 2 =
Below is the HTML that creates the form. The form element, in this case a text field must be defined between form tags and that the opening from tag must also indicate the name and location of the CGI script which will process the form data. Note that after filling in the (1-character long) text field, the user clicks on the "submit" button to send the form data to the server; in this case, since there is only one form field, the user can also hit the return key to submit the form (after submitting the form, use the back button on the browser to return to this page). For other form elements (checkboxes, pull-down menus, radio buttons, large text boxes), see the sample evaluation form (select "view source" on your browser to see the HTML code).
Next, the Perl code for the CGI script. This script must reside on the Web server. This is the a generic script which is running on a Unix server, but will work under MacOS and Windows systems as well.
<html> <FORM name = "math_problem" ACTION="http://www.madduck.com/cgi-bin/checkanswer.cgi"> Solve this tough problem: 2 + 2 = <input type=text size = 1 name="answer"> <input type=submit value="Submit answer"> </form></html>The first line simply declares this to be a Perl script, The next indicates that 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". The next line calls on a built-in cgi-lib sub-routine (ReadParse) to feed the input to the script (the "&" character is used in Perl to indicate a sub-routine). The next line defines the variable "$answer" ($ in Perl precedes variables) as the data from the form element "answer" (which the ReadParse sub-routine extracts through "$in{'answer'}"). Next the &feedback sub-routine (defined in the next section) is evoked. This sub-routine sends feedback to the user through use of the "print" command. After defining the HTTP header in the first line, an if-then structure evaluates the answer variable to see if it contains the right answer (4) and provides appropriate feedback (in HTML). The last line (exit 0) terminates the CGI.
#!/usr/local/bin/perl require 'cgi-lib.pl'; &ReadParse; $answer = $in{'answer'}; &feedback; sub feedback { print "Content-type: text/html\n\n"; if ($answer eq "4") { print "</HEAD><title>Right</title>"; print "</head><body bgcolor=\"#FFFFFF\">"; print "<center>"; print "<br><br><h2>Right!</h2>"; } else { print "</HEAD><title>Wrong</title>"; print "</head><body bgcolor=\"#FFFFFF\">"; print "<center>"; print "<br><br><h2>Wrong! <br>Sorry, $answer is not correct; please try again.</h2>"; } exit 0; }
There are additional examples on the links page, most of which are a good bit more complex, but follow the same basic pattern. Most public scripts include extensive comments, which explain why the different elements of the script are there and what they do.
USING CGI WITHOUT PROGRAMMING
Yes, this is possible, by using existing CGI scripts which you can customize to your needs. There are actually three possibilities:
The first method is how must public CGI scripts on the Web are presented (see CGI links). 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:
- Heavily commented CGI script, clearly indicating what and where to make changes, essentially a template
- CGI scripts which create a CGI script
- Generic CGI which gets its values from an HTML page
What's created when an instructor fills out a form is a CGI-based discussion forum customized for that teacher's class (example).
[Figure 4-2]
The third option is to have the CGI write generic scripts which are configurable from a Web page, as in a personality profiler form. That is to say, that the CGI gets the appropriate values from hidden fields in the HTML and delivers a customized Web page or CGI.
To do this, 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.
Bob Godwin-Jones
