CGI and Perl Scripts . CIS4930-AWD - 2/9/04
· http://cgi.resourceindex.com/Programs_and_Scripts/Perl/ .
· Perl is the most commonly used language for CGI programming on the www.The Common Gateway Interface (CGI) is an essential tool for creating and managing comprehensive web sites. With CGI, you can write scripts that create interactive, user-driven applications. .
· Rather than limiting the Web to documents written ahead of time, CGI enables web pages to be created on the fly, based upon the input of users. You can use CGI scripts to create a wide range of applications, from surveys to search tools, from Internet service gateways to quizzes and games. You can increment the number of users who access a document or let them sign an electronic guestbook. You can provide users with all types of information, collect their comments, and respond to them
· A Typical CGI Interaction - Suppose a guestbook is created for your website. The guestbook page asks users to submit their first name and last name using a fill-in form composed of two input text fields. Figure 9-1 shows the form you might see in your browser window.
Figure 9-1. HTML form
The HTML that produces this form might read as follows:
<HTML<HEAD<TITLE>Guestbook</TITLE</HEAD>
<BODY>
<H1>Fill in my guestbook!</H1>
<FORM METHOD="GET" ACTION="/cgi-bin/guestbook.pl">
<PRE>
First Name: <INPUT TYPE="TEXT" NAME="firstname">
Last Name: <INPUT TYPE="TEXT" NAME="lastname">
<INPUT TYPE="SUBMIT"> <INPUT TYPE="RESET">
</FORM>
The form is written using special "form" tags, as follows:
· The <form> tag defines the method used for the form (either GET or POST) and the action to take when the form is submitted—that is, the URL of the CGI program to pass the parameters to.
· The <input> tag can be used in many different ways. In its first two invocations, it creates a text input field and defines the variable name to associate with the field's contents when the form is submitted. The first field is given the variable name firstname and the second field is given the name lastname.
· In its last two invocations, the <input> tag creates a "submit" button and a "reset" button.
· The </form> tag indicates the end of the form.
When the user presses the "submit" button, data entered into the <input> text fields is passed to the CGI program specified by the action attribute of the <form> tag (in this case, the /cgi-bin/guestbook.pl program).
Transferring the Form Data
Parameters to a CGI program are transferred either in the URL or in the body text of the request. The method used to pass parameters is determined by the method attribute to the <form> tag. The GET method says to transfer the data within the URL itself; for example, under the GET method, the browser might initiate the HTTP transaction as follows:
GET /cgi-bin/guestbook.pl?firstname=Joe&lastname=Schmoe HTTP/1.0
The POST method says to use the body portion of the HTTP request to pass parameters. The same transaction with the POST method would read as follows:
POST /cgi-bin/guestbook.pl HTTP/1.0
... [More headers here]
firstname=Joe&lastname=Schmoe
In both of these examples, you should recognize the firstname and lastname variable names that were defined in the HTML form, coupled with the values entered by the user. An ampersand (&) is used to separate the variable=value pairs.
The server now passes the variable=value pairs to the CGI program. It does this either through Unix environment variables or in standard input (STDIN). If the CGI program is called with the GET method, then parameters are expected to be embedded into the URL of the request, and the server transfers them to the program by assigning them to theQUERY_STRING environment variable. The CGI program can then retrieve the parameters from QUERY_STRING as it would read any environment variable (for example, from the %ENV hash in Perl). If the CGI program is called with the POST method, parameters are expected to be embedded into the body of the request, and the server passes the body text to the program as standard input (STDIN).
Other environment variables defined by the server for CGI store such information as the format and length of the input, the remote host, the user, and various client information. They also store the server name, the communication protocol, and the name of the software running the server.
The CGI program needs to retrieve the information as appropriate and then process it. The sky's the limit on what the CGI program actually does with the information it retrieves. It might return an anagram of the user's name, or tell her how many times her name uses the letter "t," or it might just compile the name into a list that the programmer regularly sells to telemarketers. Only the programmer knows for sure.
A Simple Perl Program
· The perl executable is normally installed in /usr/bin or /usr/local/bin .
· Every Perl program must be passed through the Perl executable to be executed. The first line in many Perl programs is something like: #!/usr/bin/perl .
· Command-line options such as the -w switch, which produces warning messages. .
· For Unix systems, this #! (hash-bang or shebang) tells the shell to look for /usr/bin/perl program and pass the rest of the file to /usr/bin/perl for execution .
· Sometimes, different pathnames to Perl executable, such as /usr/local/bin/perl. Might see perl5 or perl6 instead of perl on sites with older versions of Perl.
the "Hello, world" program in Perl:
#!/usr/bin/perl
print "Hello, world!\n";
· The Perl executable compiles the program internally into a parse tree and executes it immediately. Because the program is not compiled and executed in separate steps, Perl is commonly known as an interpreted language, but this is not true. .
· Unlike strictly compiled languages, the compiled form of a Perl program is not stored as a separate file. However, Versions 5.6 and later give you the option of using a standalone Perl compiler that creates bytecode to be executed separately. .
· Perl "script" or Perl "program"? "Program" is used to describe something that is compiled into assembler or bytecode before executing, as in the C language. "Script" is used to describe something that runs through an executable on your system, such as the Bourne shell. For Perl, you can use either phrase .
· One performance hit for CGI programs is that the Perl interpreter needs to be started up each and every time a CGI script is called. For improving performance on Apache systems, the mod_perl Apache module embeds the Perl interpreter directly into the server, avoiding the startup overhead .
· When you write a Perl program on a UNIX system: #! line at the top of the script, make it executable with chmod +x, and run it. .
· On Win32 systems, you can associate an extension (e.g., .plx) with a file type and double-click on the icon for a Perl script with that file type. Or, do this:
(open a "DOS" window)
C:\> (edit your Perl program in your favorite editor)
C:\> pl2bat yourprog.plx
C:\> .\yourprog.bat
(program output here)
On Win32 systems, if you double-click on the icon for the Perl executable, you'll find yourself in a command-prompt window with a blinking cursor. You can enter your Perl commands, indicating the end of your input with Ctrl-Z, and Perl will compile and execute your script
Perl is arguably the most popular scripting language in use today. It is used for a wide variety of tasks, including file processing, system administration, web programming, and database connectivity. Early Perl users had to be content with command-line interfaces or full-screen interfaces using Curses or similar systems, but the splitting-off of the Tk widget library (graphical toolkit called Tk) from the Tcl (Tool Command Language) language opened a whole new world to Perl. Perl programmers could now easily create graphical interfaces for their programs using Tk's flexible and friendly widget set and, with little effort, those programs could be made to work across Windows and Unix platforms.
In our Hello World example, we'll have the title of our window say "Hello World" and create a Button that will dismiss the application:
#!/usr/bin/perl
use Tk;
my $mw = MainWindow->new;
$mw->title("Hello World");
$mw->Button(-text => "Done", -command => sub { exit })->pack;
MainLoop;
The first line invokes Perl.
The second line tells Perl to use the Tk module. On Unix, that is. In Win32 you have to type perl hello.pl
The third line:
my $mw = MainWindow->new;
is how we create a window. The window will have the same basic window manager decorations as all your other windows.
The title of our window is changed using the title method. If we hadn't used this method, the text across the top of the window would be the same as the name of the file containing the code, excluding any extension. Using the title method is not required, but it makes the application look more polished.
Any string we put as an argument becomes the title. This is akin to using the -title option when starting any standard X Windows application.
The next line creates a Button widget, sets basic properties, and packs the widget.
The Button is set to display the text "Done" and to perform the Perl command exit when pushed.
Finally, the last item of concern is the MainLoop command. This starts the event loop in motion, and from then on the application will do only what we have told it to do: if the user clicks on the Button, the application will exit. Anything else the user does—minimizing, resizing, changing to other applications—will be processed by the window manager and ignored by our application.
Figure 1-2. Hello World window
The sub { exit; } ( or its equivalent, \&exit) used to quit the Perl/Tk application. This works fine as long as you have done a use Tk; in the same file. Perl/Tk defines its own exit routine, which does some cleanup and various other things that are important to Tk. The program is then unconditionally terminated, and control returns to the operating system.
Another way to quit the Tk portion of the application is to call $mw->destroy, which destroys the MainWindow and returns to the code listed after MainLoop. This allows your program to do post-GUI processing before exiting.
Table 1-1 lists widget types and suggested naming conventions for them. Replace "blah" with a sensible description of the widget's purpose (e.g., exit). If you use this convention, you'll always know what type of widget you're working with.
Table 1-1. Naming conventions by widget type
Widget type / Suggested name / ExamplesButton / $blah_b, $blah_bttn, or $blahButton / $exit_b, $apply_b, $newButton
Canvas / $blah_canvas or $blahCanvas / $main_canvas, $tinyCanvas
Checkbutton / $blah_cb or $blahCheckbutton / $uppercase_cb, $lowercaseCheckbutton
Entry / $blah_e or $blahEntry / $name_e, $addressEntry
Frame / $blah_f or $blahFrame / $main_f, $left_f, $canvasFrame
Label / $blah_l or $blahLabel / $name_l, $addressLabel
Listbox / $blah_lb or $blahListbox / $teams_lb, $teamsListbox
Menu / $blah_m or $blahMenu / $file_m, $edit_m, $helpMenu
Radiobutton / $blah_rb or $blahRadiobutton / $blue_rb, $grey_rb, $redRadiobutton
Scale / $blah_scale or $blahScale / $age_scale, $incomeScale
Scrollbar / $blah_scroll, $blah_sbar, or $blahScroll / $x_scroll, $yScroll
Text / $blah_t or $blahText / $file_text, $commentText
Toplevel / $blah_w or $blahWindow / $main_w, $fileopenWindow
A GUI often makes the application look much more polished and purposeful than a command-line interface does, but it's easy to go overboard with a GUI and end up with something ugly, clunky, and impossible to navigate. So here are some things to consider when deciding how the GUI should look:
· Every widget should have a purpose that is intuitive and informative.
· Think about the way a user will use an application and design accordingly.
· Don't try to cram everything your application does into one window.
· Don't always try to separate everything into different windows. Sometimes the application is so simple that one window is all you need.
· Colors are great, but there are a lot of color-blind people out there. The same applies to fonts: many folks cannot read very small fonts. If you insist on using color and particular fonts, allow them to be customized via the resource database, through a file, or through the application itself.
· Some widgets do their jobs better than others. Use the proper widget for the job.
6