>While CGI.pm is useful for doing quick and dirty scripts, or for use 
>when teaching someone how to do CGI programming with Perl in a 
>classroom, I find that it is too complicated and unflexible when I 
>want to do larger scripts and have a high degree of control over what 
>is going on.

Well, I never have needed to know what goes on under the hood if it works.
Encapsulation is such a stress-killer.  Still we know the curious among
us will like to take a look inside at the source.  I've had to ;o)  Still,
CGI works; it works on all platforms (even Mac) and it works in all
environments.  It works everywhere for everyone -- (or at least that
seems to be the design objective in that module, no?), and in order to
do so, it is complex.  This is exactly why it is not recommended that
everyone try to re-invent the wheel by creating all of what CGI.pm does
every time you write a new script.  CGI.pm is very flexible, and has more
configuration options than chickens have eggs.  Granted, I don't really
like the functionality that CGI.pm provides to build html code for you,
based on a bunch of obfuscated and really complicated routines that are
more cryptic and difficult to de-bug than the html code itself (imho).
I prefer to use a different Perl library of my own make that is based on
an template based paradigm, where embedded perl constructs and pre-defined
tokens in your script get evaluated and interpollated into your page as
if you were using PHP, Cold Fusion, JSP, or ASP for example.

>So I agree that CGI.pm is fast (despite its complexity), and a good 
>tool for beginners (who want everything in one place), but I find it 
>unwieldy for a large application.

Well I have, as we type, running applications accross corporate servers
world-wide reaching a scope of coding not normally ever seen by the
majority of Perl Hackers; several hundred-thousand lines of Perl in
hierarchal, modular, object oriented classes are used to build
enterprise applications which run as web services.  These programs
would often take years to write in Java or C by the most skilled
developers.  These programs take my team and I some months to complete,
and to do a project that big and important we can't take the chance
that an insecure or poorly developed CGI sub-system is holding it
all together.  What happens when we have clients changing servers from
Red Hat to BSD, to Solaris, to NT, on one hosting company's servers to
another?  The chances just don't justify the use of unsupported,
undocumented code in such cases.  CGI.pm is part of the Perl
distribution.  It comes with every Perl source and binary for as
long as I've ever used the language.  Your suggestion that CGI.pm is
too unwieldy and unaccomadating to use for big projects is quite
dissimilar to my experience, I must say.  In fact, I find it to be
quite the opposite in the applications I've developed over the past
few years.

>For example, I often want to read query string parameters and form 
>field input at the same time, but hold them as distinct/separate 
>values for processing in my web applications.  But CGI.pm will by 
>default ignore the query string if there is post data, so I will have

Eau Contraire.  For me, the query string is still parsed each time I
use a query string along with a POSTed form.  How old is your CGI
module?  In my installation you can still separate what came from
the query string and what didn't by using some of CGI.pm's other
methods.  No personal parsing required.

>to manually parse the query string if I want to use it in addition to 
>form data.  And yes, CGI.pm will fetch both sets of variables if you 
>uncomment a line inside CGI.pm, but these will be combined into one 
>variable list (accessible through param(), etc), and if there are 
>values with the same names then they are overwritten.  Either way,

Really? -- I haven't found this to be true.  My experience is that
it all depends on the way you call the param method.  Have you
looked at the source for the module in the way it handles this?  It
is completely polymorphic in this sense -- it knows what you want
based on the way it is called.  Retrieval of multiple fields with
the same name is not only possible, but demonstrated in the last
code example I posted to the list as a possible solution to the
question which started this thread.  If you find somehow that your
form values get lost or seem unretrievable, it might be possible
that you din't call the param method with the proper syntax and/or
in the proper context to retrieve the data you wanted.  Still, I
think it is rarely of use or even logically sound to name all your
form fields, or any number of them with the same name.  Now that
makes life simple!  That seems way too complicated for my taste,
and prone to strange behaviour due to the malformed and
unconventional use of html/xhtml based on standards the W3C
introduced back with HTML 3.0.

>Moreover, CGI.pm doesn't follow the good programming practices of
>separating distinct functionality into separate modules.  Rather, it
>does a variety of unrelated things in one module, making it harder to 
>update or extend, or to pick some functions and leave others.  For

Ah-hah.  Here we have it.  This is the big concern I have had myself
sooo many times, and one that even led me to create my own CGI
library at one time.  Still, the point I want to make here is that
you surely haven't been using the most recent version of CGI.pm,
because it has been completely modular-ized.  No more
MOTHER-OF-ALL-MODULES approach anymore.  Kind of nice.  I still
think I'll continue developing my own CGI code libraries, but that's
only because I've thoroughly researched and made every effort to
understand the complexities of truly platform independent, scalable,
SECURE programming for the CGI interface.  The endevor has been no
small project.  My work is still a 'work in progress', but will
hopefully form the basis for all of my coding over the CGI layer of
in my programming some day.  To undertake this kind of work is
certainly not my personal recommendation for the majority of those
who use Perl.  It is unnecessary, and accomplishes very little in
the way of code optimization.  My reasons for doing this are
strictly based on a personal need to develop a common object model
that encompasses all my coding, to form a new meta-language over
Perl, futher simplifying and speeding up the software development
process.  Even when I am confident that I've finally discovered the
cure-all-to-end-all CGI library of all time, I still won't have the
assurance that it has done its job and served its pupose reliably
and faithfully, securely and flexibly, on as many platforms and in
as many environments, and for the many years that CGI.pm has done.
Tried and true, though not my 'ideal' solution for CGI programming, it
is certainly as one of our list members put it so eloquently some
months ago, "kid tested, mother approved."

>example, it fetches various environment variables, parses query
>information, generates form html replicating old user input,
>generates miscellaneous html, creates http headers,  each of which
>should be a separate module.  Lincoln Stein thinks so too, in the
>CGI.pm appendix, but somehow he continues to work on it.

Hooray, we have what a lot of us been wanting and waiting for all
this time!  No more complaints about that from me.

>I have made my own replacements for its functionality, and various 
>other people have too; our counterparts are on CPAN and are used 
>quite thankfully.

And these are definately worth looking at -- lovely solutions for
specific purposes.  Unfortunately for those who host with web
servers that don't allow access to the innards of Perl, it's
difficult to use these because installation is quite often
impossible.  For this reason I try to use CGI; in my examples to
the list because it will work for everybody -- even if they host
with cheap yahoo web space.

Thanks for your comments.  I just wanted to address what I saw
as some discrepancies in our individual experiences with the
module.  Please regard my comments as general and directed to the
masses -- not personally directed to you at all.  In no way am I
trying to under-cut what you have shared with all of us.  I'm
sure there are great reasons behind each example you've considered
over the time it has taken you to form your overall viewpoint on
use of this module.  I have found lots of your posts to the list
to be helpful, informative, and really smart.  I'm glad you share
your expertise with us!  The contributions are deeply appreciated.


  - Tommy Butler,
    Internet Strategies, Inc. º ° º  Everything is Possible.

    web  http://istrat.com
            email   mailto:tommy@istrat.com
                     tel   2 1 4 . 3 9 3 . 1 0 0 0  ext207
                             fax   8 0 0 . 3 0 7 . 8 1 0 5

    2200 North Lamar, Suite 307   º ° º   Dallas, TX  75202