but that's no great hardship. Even that could be made easier, e.g. enhance CGI::Application's import() method so that users can say
use CGI::Application qw(-apache_request);
to tell CGI::Application to load and use Apache::Request, rather than the CGI.
In other words, rather than detecting a mod_perl environment and always using Apache::Request in that case, let the user specify what query module to use. The default choice would obviously be CGI.pm for backwards compatibility.
This makes it more difficult to release applications for use in a dual enviroment. If I write a module that claims it can work as both CGI and mod_perl, then I can't expect the user to edit the source code to add the qw(-apache_request) in the use line.
The same arguement can be used against an 'Apache::Application' subclass that uses Apache::Request instead of CGI.
I think it makes more sense to have the app look at $ENV{MOD_PERL} to see if it is a mod_perl environent, and then see if Apache::Request is available for use. Maybe a feature that explicitly disallows Apache::Request to be used would work ( ie use CGI::Application qw(-no_apache_request); ), so by default Apache::Request is used if available.
- Cees
--------------------------------------------------------------------- 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]
