Juerd wrote:
Fagyal Csongor skribis 2006-09-20 11:28 (+0200):
You rarely do real HTTP handling when you use CGI.
You may not, but many people do a lot of these things.
Actually me, too. Not with CGI.pm, though.
I tend to use CGI::Simple for form/param parsing, Template.pm for
template processing, LWP::Simple for... well, HTTP handling (kind of...)
and so on and so on.
And when you don't, the datastructures are currently parsed and filled
anyway, so I don't know why you say it'd be too inefficient.
Inefficient was probably a bad choice of word.
I would rather say: I would not like to see Perl6's CGI.pm as a monster
module, which has one part everyone uses, and one hundred other parts
that some uses, because I feel those parts should be put into other
modules.
I just feel quilty when I use (Perl5's) CGI.pm for such trivial tasks as
parameter parsing. Feels like... say, using MIME::Lite for *sending*
mail not *constructing*.
Or maybe... you know, I have a Windows XP installed at home. The one
thing I use it for is to run dvdsrhink :)) That's a big price for 10G of
discspace :)
As a side note I also have to add that I really dislike the
"html-functions" CGI.pm currently has. Creating the representation is
the task of the designer, not the programmer. It's almost like "echo" in
PHP :))) I used CGI.pm with simple cgi scripts, with Apache::ASP,
mod_perl and FCGI, I used CGI::Cookie, etc. yet I never needed those
HTML generating methods. To me, <imho>it feels wrong that they are
there</imho>.
A general, simple CGI handling module fits into 200 lines, including
POD. Imagine like
That's not "CGI handling", that's form parameter parsing. CGI, and web
programming, is much more than that.
That I know :) That's what I do for a living :), for almost like 10
years now. And I started with "cgi-lib.pl" :) ...which makes me think
"CGI.pm" should not do much more than that old horse.
But please see below.
You don't really need more.
I think you mean: "I don't really need more". Many people do need a
whole lot more, and CGI.pm does do a whole lot more.
My public domain framework's dispatcher class starts something like:
use strict;
use FCGI;
use Template;
use Template::Stash;
use CGI::Simple::Cookie;
use CGI::Simple;
use Config::General;
use Data::Dumper;
use Time::HiRes;
use Digest::MD5;
use PET::GCONF;
use HTML::FillInForm;
use LWP::Simple;
use MIME::Base64 qw/encode_base64/;
use PET::Filter;
use PET::Util;
use PET::Log;
use PET::CacheControl;
use Storable;
use Carp qw/croak cluck carp/;
use UNIVERSAL;
use BSD::Itimer;
use POSIX qw/setuid setgid/;
use BSD::Resource;
And that's just the dispatcher - the framework uses every third module
from CPAN, so to say :) So I am also between those people who need a lot
more - yet I think CGI.pm should only do parameter parsing.
But no, that is not correct. What I really want to say is that I have no
problem with any parts of the original CGI.pm, *except for* the HTML
generation stuff. CGI/Lite.pm is ~1200 lines. CGI.pm is ~7500 lines. And
what is missing? From the man page of CGI::Simple:
"
CGI::Simple provides a relatively lightweight drop in replacement
for CGI.pm. It shares an identical OO
interface to CGI.pm for parameter parsing, file upload, cookie
handling and header generation. This mod-
ule is entirely object oriented, however a complete functional
interface is available by using the
CGI::Simple::Standard module.
Essentially everything in CGI.pm that relates to the CGI (not
HTML) side of things is available. There
are even a few new methods and additions to old ones! If you are
interested in what has gone on under the
hood see the Compatibility with CGI.pm section at the end.
"
Just not in a
nicely organized set of classes.
If you put it that way, I can certanly agree.
It's unfortunate that it mostly lets the user handle headers that are
communicated through ENV, precisely because that's part of the CGI spec,
and not common to other kinds of web programming, so it's specifically a
job for a module called CGI.pm
It might give some useful other routines (e.g. url encoding /
decoding, various ways to mix GET+POST, set content types more easily,
etc.), but other than that, it should be very lightweight and easy to
use.
I agree that things should be lightweight and easy to use. But in Perl
6, that doesn't mean that you should avoid nicely structured OO.
If we talk about nicely structured OO, I can see a few ways:
- CGI.pm include something like "CGI::HTML", to get rid of the HTML
generating part, or maybe even separating CGI::HTML and CGI::Request
- now that I write it down, for me it feels more natural to have
something like "HTML::CGI" :
# imagine something like:
$cgi = new CGI;
$html = HTML::CGI->new($cgi);
$html->popup_menu( ... ); # I won't do this, but others might... :)
...and still I think that a module named CGI should handle the CGI 1.1
(1.2) specification (read *STDIN, write to *STDOUT, parse %ENV , that
is) and do nothing more. To stuff CGI::* with CGI::HTML, CGI::Whatever
is another story. As the matter of fact, I would rather rename the
current CGI::Simple to CGI, and CGI to Web::CGI or CGI::HTML or
something like that.
You know... as the matter of fact, I think we are only arguing about
namespace usage here :))
- Fagzal
