[EMAIL PROTECTED] (Matt Arnold) wrote:
>1. An Apache handler doesn't mean CGI.pm *ISN'T* in use
>2. Just because you don't use Apache::Registry doesn't mean you're not doing
>CGI emulation (*gasp*)
>3. Using Apache::Registry doesn't necessarily mean CGI.pm is at use
>4. Using CGI.pm is smart (aka don't reinvent CGI.pm's HTML methods)
I think somewhere you got confused about the relationship between
Apache::Registry and CGI.pm, and now you're starting to get unconfused. But
that doesn't mean that everyone else was confused the same way you were.
CGI.pm and Apache::Registry are independent. You can use one without the other
very easily. No need to associate them in this email.
>Somewhere along the line, CGI.pm became "bad, evil, and bloated". Many of
>you don't want to use CGI.pm for anything. While some of CGI.pm's
>functionality can be done more efficiently by other means (i.e.
>Apache::Request), CGI.pm's HTML methods have no such high-efficiency
>equivalents. Since laziness is one of the primary Perl virtues, isn't it
>smart to leverage the work already done in CGI.pm rather than rolling your
>own HTML methods? Can't using CGI.pm's HTML methods be considered a "good
>thing"?
Of course, a lot of people like them. I don't use them, though. HTML is a
perfectly valid language, and I don't see why I should use Perl to create HTML.
It feels like using Java to write C. If you're using one of the embedded Perl
solutions like HTML::Mason & friends, one of the goals is to let HTML be HTML
and let Perl be Perl.
>The recent thread "[ot] How to crypt the way htpasswd does..." serves as an
>example of how one can get chastised for failure to use existing code. (See
>http://forum.swarthmore.edu/epigone/modperl/nengahker for the thread.) Why
>are so many of you quick to ignore this advice? Why is this particular
>wheel one so many of you are willing to reinvent?
Well, one could make the argument that CGI.pm reinvented the wheel too - the
HTML wheel.
>Would the anti-CGI.pm crowd be more likely to use these HTML functions
>if they were in their own (presumably leaner) module unbundled from the
>"bloated, monolithic" CGI.pm?
No, I doubt it. At least, I wouldn't. There's nothing wrong with the
HTML-generation side of CGI.pm, it just does things that I don't need to do, so
I don't tend to use it.
>Perhaps this is what most of you performance mongers really mean.
It's not helpful to call people names like that. People are just trying to get
things done.
By the way, you haven't mentioned the biggest reasons that people might want to
avoid Apache::Registry. It will do a stat() on your script to see if it's
changed, and set up several things (including %ENV, which you mentioned) just
to emulate the CGI environment. There's no real reason to set these things up,
it's just for CGI compatibility. So if you don't need CGI compatibility,
doesn't it make sense that you shouldn't waste effort setting these things up?
Apache::Registry makes a lot of sense for people who need to keep their scripts
portable and CGI-compatible. Same with CGI.pm. No reason to couch things in
your black/white good/bad terms, as there is a time to use all of these very
popular tools and a time to choose other tools.
------------------- -------------------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED] The Math Forum
