ch05_01.htm

用perl编写CGI的好书。本书从解释CGI和底层HTTP协议如何工作开始

use CGI;

$CGI::DISABLE_UPLOADS = 1;
$CGI::POST_MAX        = 102_400; # 100 KB

my $q = new CGI;
.
.</pre></blockquote>


<p>Throughout our examples, we will assume that the module has been
patched and omit these lines.</p>
</div>




<a name="ch05-1-fm2xml" /><div class="sect2">
<h3 class="sect2">5.1.2. The Kitchen Sink</h3>


<p>
<a name="INDEX-945" />
<a name="INDEX-946" />CGI.pm is a big module. It provides
functions for accessing CGI environment variables and printing
outgoing headers. It automatically interprets form data submitted via
POST, via GET, and handles multipart-encoded file uploads. It
provides many utility functions to do common CGI-related tasks, and
it provides a simple <a name="INDEX-947" /> <a name="INDEX-948" />interface for
outputting HTML. This interface does not eliminate the need to
understand HTML, but it makes including HTML inside a Perl script
more natural and easier to validate.</p>


<p>Because CGI.pm is so large, some people consider it bloated and
complain that it wastes memory. In fact, it uses many creative ways
to increase the efficiency of CGI.pm including a custom
implementation of SelfLoader. This means that it loads only code that
you need. If you use CGI.pm only to parse input, but do not use it to
produce HTML, then CGI.pm does not load the code for producing HTML.</p>


<p>There have also been some alternative,
<a name="INDEX-949" />
<a name="INDEX-950" />lightweight CGI modules written.
One of the lightweight alternatives to CGI.pm was begun by David
James; he got together with Lincoln Stein and the result is a new and
improved version of CGI.pm that is even smaller, faster, and more
modular than the original. It should be available as CGI.pm 3.0 by
the time you read this book.</p>
</div>




<a name="ch05-48461" /><div class="sect2">
<h3 class="sect2">5.1.3. Standard and Object-Oriented Syntax</h3>


<p>
<a name="INDEX-951" />
<a name="INDEX-952" />
<a name="INDEX-953" />CGI.pm, like Perl, is powerful yet
flexible. It supports two styles of usage: a
<a name="INDEX-954" />standard interface and an object-oriented
interface. Internally, it is a fully object-oriented module. Not all
Perl programmers are comfortable with object-oriented notation,
however, so those developers can instead request that CGI.pm make its
subroutines available for the developer to call directly.</p>


<p>Here is an example. The object-oriented syntax looks like this:</p>


<blockquote><pre class="code">use strict;
use CGI;

my $q    = new CGI;
my $name = $q-&gt;param( "name" );

print $q-&gt;header( "text/html" ),
      $q-&gt;start_html( "Welcome" ),
      $q-&gt;p( "Hi $name!" ),
      $q-&gt;end_html;</pre></blockquote>


<p>The standard syntax looks like this:</p>


<blockquote><pre class="code">use strict;
use CGI qw( :standard );

my $name = param( "name" );

print header( "text/html" ),
      start_html( "Welcome" ),
      p( "Hi $name!" ),
      end_html;</pre></blockquote>


<p>Don't worry about the details of what the code does right now;
we will cover all of it during this chapter. The important thing to
notice is the different syntax. The first script creates a
<a name="INDEX-955" />CGI.pm object and stores it in
<tt class="literal">$q</tt>
<a name="INDEX-956" /> (<tt class="literal">$q</tt> is short for
<em class="emphasis">query</em> and is a common convention for CGI.pm
objects, although <tt class="literal">$cgi</tt> is used sometimes, too).
Thereafter, all the CGI.pm
<a name="INDEX-957" /> <a name="INDEX-958" />functions are preceded by
<tt class="literal">$q-&gt;</tt>. The second asks CGI.pm to export the
standard functions and simply uses them directly. CGI.pm provides
several predefined groups of functions, like <tt class="literal">:standard
</tt>, that can be exported into your CGI script.</p>


<p>The standard CGI.pm syntax certainly has less noise. It doesn't
have all those <tt class="literal">$q-&gt;</tt> prefixes. Aesthetics aside,
however, there are good arguments for using the object oriented
syntax with CGI.pm.</p>


<p>Exporting functions has its costs. Perl maintains a separate
<a name="INDEX-959" />namespace for
different chunks of code referred to as <a name="INDEX-960" />
<a name="INDEX-961" />packages. Most modules, like CGI.pm, load
themselves into their own package. Thus, the
<a name="INDEX-962" />
<a name="INDEX-963" />functions and variables that modules
see are different from the modules and variables you see in your
scripts. This is a good thing, because it prevents collisions between
variables and functions in different packages that happen to have the
same name. When
a<a name="INDEX-964" /> <a name="INDEX-965" /> <a name="INDEX-966" /> module exports symbols
(whether they are variables or functions), Perl has to create and
maintain an alias of each of the these symbols in your
program's namespace, the <em class="emphasis">main</em> namespace.
These aliases consume <a name="INDEX-967" />memory. This memory usage
becomes especially critical if you decide to use your CGI scripts
with FastCGI or <em class="emphasis">mod_perl</em>.</p>


<p>The object-oriented syntax also helps you avoid any possible
collisions that would occur if you create a
<a name="INDEX-968" />subroutine with the same name as one of
CGI.pm's exported subroutines. Also, from a maintenance
standpoint, it is clear from looking at the object-oriented script
where the code for the <a name="INDEX-969" />header
function is: it's a method of a CGI.pm object, so it must be in
the CGI.pm module (or one of its associated modules). Knowing where
to look for the header function in the second example is much more
difficult, especially if your CGI scripts grow large and complex.</p>


<p>Some people avoid the object-oriented syntax because they believe it
is slower. In Perl, <a name="INDEX-970" />
<a name="INDEX-971" />
<a name="INDEX-972" />methods typically are slower than
functions. However, CGI.pm is truly an object-oriented module at
heart, and in order to provide the function syntax, it must do some
fancy footwork to manage an object for you internally. Thus with
CGI.pm, the object-oriented syntax is not any slower than the
function syntax. In fact, it can be slightly faster.</p>


<p>We will use CGI.pm's object-oriented syntax in most of our
examples.</p>
</div>
</div>










































<hr align="left" width="515" />
<div class="navbar"><table border="0" width="515"><tr><td width="172" valign="top" align="left"><a href="ch04_03.htm"><img src="../gifs/txtpreva.gif" alt="Previous" border="0" /></a></td><td width="171" valign="top" align="center"><a href="index.htm"><img src="../gifs/txthome.gif" alt="Home" border="0" /></a></td><td width="172" valign="top" align="right"><a href="ch05_02.htm"><img src="../gifs/txtnexta.gif" alt="Next" border="0" /></a></td></tr><tr><td width="172" valign="top" align="left">4.3. Decoding Form Input</td><td width="171" valign="top" align="center"><a href="index/index.htm"><img src="../gifs/index.gif" alt="Book Index" border="0" /></a></td><td width="172" valign="top" align="right">5.2. Handling Input with CGI.pm</td></tr></table></div>
<hr align="left" width="515" />

<img src="../gifs/navbar.gif" alt="Library Navigation Links" usemap="#library-map" border="0" />
<p><font size="-1"><a href="copyrght.htm">Copyright &copy; 2001</a> O'Reilly &amp; Associates. All rights reserved.</font></p>

<map name="library-map"><area href="../index.htm" coords="1,1,83,102" shape="rect" /><area href="../lnut/index.htm" coords="81,0,152,95" shape="rect" /><area href="../run/index.htm" coords="172,2,252,105" shape="rect" /><area href="../apache/index.htm" coords="238,2,334,95" shape="rect" /><area href="../sql/index.htm" coords="336,0,412,104" shape="rect" /><area href="../dbi/index.htm" coords="415,0,507,101" shape="rect" /><area href="../cgi/index.htm" coords="511,0,601,99" shape="rect" /></map>

</body></html>