CGI.pm versus Individual libwww Modules
CGI.pm and the modular WWW libraries are very similar in function but very different in purpose. CGI.pm includes all of the functionality of the individual modules, and in most cases, more. In fact, Lincoln Stein, the author of CGI.pm and the WWW modules, developed the CGI.pm module in parallel with the CGI, URL, and HTML modules. The individual modules are designed to provide a very optimized solution to about nine different aspects of programming with Perl for the Web. Modules exist for the Web functions listed in Table 5.4.
Table 5.4. Function of libwww modules.
|CGI::||Allows control over HTTP request and response headers. Mini HTTP server, CGI-based imagemapping, "smart" forms.|
|File::||Parsing of directory listings and a persistent counter.|
|Font::||Interface to Adobe Font Metrics Files.|
|HTML::||Creation and parsing of HTML elements. Format HTML as text or PostScript.|
|HTTP::||Generation of HTTP requests, responses, and headers. Content negotiation and status code processing.|
|LWP::||Low-level I/O, socket interface, file type recognition.|
|MIME::||Encoding and decoding Base64 and QP.|
|URI::||Filtering, processing of URIs, elimination of unsafe characters in strings.|
|WWW::||Parse robot.txt files.|
Anything your CGI prints to STDOUT gets sent back to the Web server and out to the browser, unless you are using nph-CGIs, in which case, STDOUT goes directly to the browser without being parsed by the server. Traditionally, before Perl5 and CGI.pm, HTML forms were created by CGI scripts by printing the HTML form elements to STDOUT. Traditionally, the name/value pairs would have to be URI-decoded from either the URI (
GET method) or STDIN (
POST method). Back in the days of Perl 4, include scripts such as cgi-lib.pl were written to deal with these nuisances. However, there were still problems. Using cgi-lib.pl, the state of a form (the
contents of the variables) was lost from invocation to invocation because neither the browser nor the server retained data from a previous transaction, debugging was difficult, namespace was trampled, and the code was messy and would emit errors before the HTTP response headers were printed if Perl was run in strict mode.
If you still aren't convinced, a complete rundown on all of the benefits of using CGI.pm and Perl5 over the old methods such as cgi-lib.pl can be found at the following URL:
CGI.pm was created to address these problems and build a wide and extensible bridge between your CGI Perl script and the CGI interface. With CGI.pm, HTML forms can be generated easily by making a few Perl function calls. When you use CGI.pm to generate HTML forms, the values of the input fields from previous queries (if there were any) are automatically used to initialize the form, so the state of the form is preserved from invocation to invocation. URI encoding and
decoding of special characters is handled transparently by CGI.pm.
POST methods are handled appropriately. If your script is run from the UNIX shell, the option of inputting variables from the command line is given. In short, CGI.pm takes care of almost all of the gory details of CGI and lets you focus on writing your program.
The easiest way to learn to use CGI.pm or any of the modules is to simply start using them in your scripts.