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

Reply via email to