CGI.pm is a great piece of code, but its very monolithic. Lincoln/Doug's
libapreq module is probably much faster (I have never run benchmarks) than
CGI.pm, so it makes sense for those who like the Q->param type interface
(I do) for working with CGI environment variables, but don't need all the
handy html and cookie functions/methods the CGI.pm provides.
A lot of mod_perl shops have aready developed their own templating scheme,
or page object model, or are using one of Mason, ASP, embperl etc . . .
and don't have a lot of use for 85% of CGI.pm's library routines.
Again, there are c based modules now for HTTP utils and cookies as well,
which provide more speed.
The reason many prefer native Apache methods over wrapped cgi scripts is
not just speed, but coding style and maturity. Writing modules and setting
up objects requires more discipline that writing quick scripts and relying
on magic to reset your environment for the next execution run. I have
applications that now run as deep as 50,000 to 100,000 lines of code. I
don't want wrapped scripts. I want re-usable functions, objects, etc.
As developers learn to write native handlers they are starting down the
path that gets them ready for more serious action (namespace management,
using lexicals properly, etc . . . )
That being said perl is all about getting your job done before you get
fired. So an elegant registry solution should never be looked down upon
just because its a registry solution.
On Wed, 29 Mar 2000, Matt Arnold wrote:
> Many messages on this list perpetuate the notion that usage of CGI.pm and
> Apache::Registry is for beginners. Popular opinion is that you're not a
> leet mod_perl h@x0r until you wean yourself from CGI.pm and Apache::Registry
> and "graduate" to the Apache API. With this in mind, there have been many
> messages over the years making blanket statements along the lines of "CGI.pm
> is evil" and/or "Apache::Registry sux". I'm trying to identify the source
> of this disatisfaction. While it may seem that my intent is to start the
> ultimate, end-all CGI.pm/Apache::Registry flame war, please be assured that
> I am interested in ferreting out the real issues. :-)
>
> Anyway, in hope of generating some debate, I'll make some (potentially
> inflammatory) assertions:
>
> 1. An Apache handler doesn't mean CGI.pm *ISN'T* in use
>
> The "Apache::Registry sux" crowd claims I should forgo Apache::Registry and
> write handlers instead. Okay, here's my handler:
>
> # in httpd.conf
> <Location /foo>
> SetHandler perl-script
> PerlHandler Apache::Foo
> </Location>
>
> package Apache::Foo;
> use strict;
> use CGI ();
> sub handler {
> my $q = CGI->new;
> print $q->header;
> print "Hello World\n";
> 200;
> }
> 1;
>
> Satisfied? No Apache::Registry in use here. Am I a l33t h@x0r now? No?
> Why not? Oh, so when the zealots say, "Apache::Registry sux, write handlers
> instead" they really mean I should be using the Apache API instead of
> CGI.pm. I see.
>
> I have another beef with the "CGI emulation sux, avoid Apache::Registry"
> crowd. And that is:
>
> 2. Just because you don't use Apache::Registry doesn't mean you're not doing
> CGI emulation (*gasp*)
>
> What exactly is this "evil, bloated, slow CGI emulation" that everyone's
> trying to avoid? Is it the overheard of setting up all the environment
> variables? Well, gee whiz, regular handlers do this too unless you tell
> them not to. Try the following exercise:
>
> <Location /env>
> #PerlSetupEnv Off # try first without; then try with PerlSetupEnv Off
> SetHandler perl-script
> PerlHandler Apache::Env
> </Location>
>
> package Apache::Env;
> use strict;
> use Data::Dumper qw(Dumper);
> sub handler {
> my $r = shift;
> $r->content_type('text/plain');
> $r->send_http_header;
> $r->print(Dumper(\%ENV));
> 200;
> }
> 1;
>
> So let's not be so quick to curse Apache::Registry for it's "slow" CGI
> emulation. Your "fast" handlers are probably doing the same thing
> unbeknownst to you.
>
> Another assertion:
>
> 3. Using Apache::Registry doesn't necessarily mean CGI.pm is at use
>
> It seems the "Apache::Registry sux" crowd dislikes Apache::Registry because
> it implies that CGI.pm is in use. Perhaps their real gripe is one should
> use the Apache API instead of CGI.pm's methods. So how would they feel
> about this:
>
> # in httpd.conf
> <Location /bar>
> PerlSetupEnv Off # we don't need no stinking ENV
> SetHandler perl-script
> PerlHandler Apache::Registry # or Apache::RegistryNG->handler
> Options +ExecCGI
> </Location>
>
> #!/usr/local/bin/perl -w
> use strict;
> my $r = Apache->request;
> $r->content_type("text/html");
> $r->send_http_header;
> $r->print("Hi There!");
>
> Does this count? Am I a l33t h@x0r because I used the Apache API? Or am I
> still a lamer for using Apache::Registry?
>
> I can hear the hordes out there crying, "Why use Apache::Registry if you're
> not using CGI.pm?" Well, perhaps I have a couple hundred scripts and don't
> want to maintain several hundred <Location> directives in httpd.conf. Maybe
> I like Apache::Registry's convenient way of grabbing my script, wrapping it
> into a handler on-the-fly, and serving it up. Isn't this one of the handier
> features of Apache::Registry? (Note: I'd like to hear of alternatives to
> Apache::Registry[BB|NG] for doing this.)
>
> So maybe Apache::Registry isn't pure evil after all. So perhaps the zealots
> clarify their mantra to be simply "CGI.pm sux". That leads us to the next
> assertion.
>
> 4. Using CGI.pm is smart (aka don't reinvent CGI.pm's HTML methods)
>
> 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"?
>
> 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? 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?
>
> With all this in mind, we can finally arrive at...
>
> 5. Don't use CGI.pm for what can be done elsewhere, faster
>
> Perhaps this is what most of you performance mongers really mean. Don't use
> CGI.pm to do stuff the API can do -- use the Apache API or Apache::Request
> instead. And be sure to set "PerlSetupEnv Off" unless you need it. This
> seems like good advice. See how easy it is to give out good advice without
> any disparaging comments against CGI.pm or Apache::Registry. :-)
>
> So I'm hoping you'll agree that it's still possible to have a
> highly-efficient system and be a leet mod_perl h@x0r while still using
> CGI.pm and Apache::Registry. Leveraging CGI.pm's HTML functions is smarter
> than reinventing your own. And the use of Apache::Registry doesn't
> necessarily mean CGI.pm or "CGI emulation" are in use.
>
> Thanks in advance for your flames, er... replies.
>
> Matt
>
> P.S. The terms l33t h@x0r, zealot, performance monger, and code wanker are
> intended to be complimentary -- not inflammatory. (Well, okay, code wanker
> is intended to be inflammatory, but I never used that term.)
>
> P.P.S. I should have some benchmarks soon showing CGI.pm vs.
> Apache::Request, handler vs. Apache::Registry vs. Apache::RegistryBB,
> PerlSetupEnv Off vs. On, etc.
>
>
>
>
