On Oct 21, 2004, at 7:38 PM, Cees Hek wrote:
If you are already checking to see which version of mod_perl is running, then I think it would probably also be useful to detect if mod_perl is NOT available! If it is not, maybe your plugin can gracefully get out of the way, and let the application work with the standard CGI.pm module. I think you can just look at $ENV{MOD_PERL} for whether mod_perl is running, and what version is being used.
This would allow app developers to put the C::A::P::Apache plugin in all their apps, and use it in a CGI and mod_perl environment without any code changes.
I was just catching up to today's conversation and was going to suggest exactly what Cees did. Good thing I read all of the messages before replying.
MT's support of mod_perl in its app framework is virtually transparent. Here is how it initializes the query object:
(MT supports file uploading whose max size is defined in its config. Just ignore those parts.)
if ($ENV{MOD_PERL}) {
require Apache::Request;
$app->{apache} = $param{ApacheObject} || Apache->request;
$app->{query} = Apache::Request->instance($app->{apache},
POST_MAX => $app->{cfg}->CGIMaxUpload);
} else {
require CGI;
$CGI::POST_MAX = $app->{cfg}->CGIMaxUpload;
$app->{query} = CGI->new( $app->{no_read_body} ? {} : () );
}Getting and setting headers along with cookies have similar code and in my experience makes things completely transparent as a developers. I'd really recommend applying a similar approach to the Apache plugin for C::A.
<tim/>
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
