Fagyal Csongor skribis 2006-09-20 15:43 (+0200):
> 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.
Perl 6's Web toolkit, even with all these classes, is likely to be much
lighter than Perl 5's CGI.pm with :standard.
But note that especially if it is a well designed bundle of
classes/roles, you can pick exactly those things that you need, and
leave all others out. That's part of the reason why you should separate
things.
> 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.
That's an ideal world. Many programmers have to hack some HTML
themselves. I do think that they're far better off with raw HTML, but
there are people who prefer the generation methods, and we should try to
make everyone happy, not just ourselves.
> To me, <imho>it feels wrong that they are there</imho>.
It *is* wrong to have them in CGI.pm. It wouldn't be wrong to have them
in a Web toolkit. In any case, I think they should only be loaded on
request.
> 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.
I think CGI.pm, as in Perl 5, should not ever be written for Perl 6.
I think Web::CGI could handle CGI requests well, but not just parameter
parsing. It should also do ENV parsing. If you want to implement only
parameter parsing, don't ask for CGI, because CGI is more than that.
> generation stuff. CGI/Lite.pm is ~1200 lines. CGI.pm is ~7500 lines. And
Please don't measure things in lines. For starters, your line counts
include documentation. These numbers are meaningless.
> 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
s:g/CGI/Web/, please! mod_perl has nothing to do with CGI (except
perhaps for its compatibility syntax), and neither does HTTP::Daemon. We
should write generic code, suitable for any implementation.
I'm thinking of:
Web::Init::CGI # Initializer for CGI requests
Web::Init::FastCGI # Initializer for FastCGI requests
Web::Init::ModPerl # Initializer for ModPerl requests
Web::Request # Request objects
Web::Response # Response objects
Web::Session # Session objects
Web::HTML # HTML generation
Web::Util # HTML-entities, URI-encoding, etc
Web # utility module that mostly loads other modules
> - 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... :)
use Web <$web> :html;
$web.popup_menu(...);
implemented by something like
class Web {
has $.request;
...
}
role Web::HTML {
method popup_menu(...) {
# something with .request
}
}
> ...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.
That's a good idea, and I agree. But CGI.pm should only be a tiny part
of our web toolkit.
> You know... as the matter of fact, I think we are only arguing about
> namespace usage here :))
Yes. I'm talking about a web development toolkit, that does at least
what CGI.pm did, and not about CGI as a namespace, because I think
that's an incredibly bad thing anyway.
--
korajn salutojn,
juerd waalboer: perl hacker <[EMAIL PROTECTED]> <http://juerd.nl/sig>
convolution: ict solutions and consultancy <[EMAIL PROTECTED]>
