Hi Brett --
> Are you referring to the set of environment variables that are the
> essence of CGI? It is completely valid but I wouldn't go as far as to
> say it is preferable.
CGI is the environment variables plus the interaction with various IO
streams (STDOUT, STDERR). It is a fully-functional API which represents the
functionality which is common to all web servers and required for all
interactive web applications. There is not much you can't do with CGI. (I
can't think of anything off the top of my head!)
Unless you can think of something another API does that CGI doesn't do (some
feature you actually NEED!), then we agree CGI is equal in functionality.
If you agree that CGI is equal in functionality but greater in portability
and familiarity, then it may even be preferable.
> Native mod_perl allows you direct access to the web request as stored
> in memory by apache. I hear you saying "but that isn't portable
> across APIs" and you are right. So use a programmatic abstraction of
> CGI (custom API, essentially) which provides the required information
> from the available source, be it mod_perl Apache::Request object, CGI
> environment or whatever IIS uses.
>
> I feel that is the most flexible approach, and it allows you to do
> neat things like run a CGI::Application inside of another.
I use mod_perl everywhere, and I have written some pretty complex
Apache/mod_perl handlers, but I would not want to write the bulk of my code
as an Apache handler. There are no functions I need which are not
accessible using only the CGI API. (I'm not sure how you run a
CGI::Application inside of another, but I'd bet that can be done without
access to the Apache core.)
There is no performance advantage to Handlers, as Apache::Registry provides
the same performance benefits to CGI-style Perl applications. OTOH,
sticking to Pure CGI has the added benefit of allowing me to take my code to
another non-mod_perl server. This is a feature I have had to use in the
past.
My "programmatic abstraction" in this case is CGI.pm, which works great for
me. It also works great for the vast majority of programmers who know
CGI.pm but don't know beans about Apache's native API. And CGI.pm works on
different web servers. Did I mention portability? :-)
> Speaking of mod_perl, I was wondering if there is a generic
> PerlHandler for bootstrapping a CGI::Application.
Not quite generic, but pretty simple:
package My::CGIApp::Module;
use base qw/CGI::Application/;
use Apache::Constants ':response';
sub handler ($$) {
my ($pkg, $r) = @_;
# Instantiate and run() your CGI::Application module
my $self = $pkg->new();
$self->run();
return OK;
}
sub setup {
# Etc....
}
If you choose to do this, start thinking of your handler() as your "instance
script". I've done this in cases where I truly want the CGI-App to handle
all requests in a particular directory hierarchy.
TTYL,
-Jesse-
----
Jesse Erlbaum, CTO
Vanguard Media
212.242.5317 x115
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
