On Fri, Oct 22, 2004 at 11:25:34AM -0400, Michael wrote:
> Well then, should I add this by trying to duplicate the C::A code if
> there is no $ENV{MOD_PERL} or should I just call
> $self->SUPER::cgiapp_get_query or $self->SUPER::_send_headers? Since the
> plugin exports these methods to the application class then it should
> work just fine and then C::A could actually change without me having to
> worry.
Thinking out loud here.... Would it be possible to avoid exporting these
functions if it's detected that we are not in a mod_perl environment?
Would a BEGIN block be sufficient (or even necessary)?
use vars qw(@EXPORT_OK %EXPORT_TAGS);
BEGIN {
if ($ENV{MOD_PERL}) {
@EXPORT_OK = qw(handler cgiapp_get_query _send_headers);
%EXPORT_TAGS = (all => [EMAIL PROTECTED]);
}
}
I'm not sure if this implementation would cause problems if some scripts
are run under mod_cgi and some under mod_perl on the same server. I
guess it depends on whether the module would be reloaded when run in the
different environments or whether the mod_cgi scripts would share the
same modules loaded by the mod_perl scripts. I would hope these
environments would be seperate.
> Also, should we look at making _send_headers into send_headers in case
> other modules want to subclass this behaviour as well?
If you referring to the sub in C::A, it does seem a bit unfriendly to be
overriding a private subroutine. I'd vote for making it public.
William
--
Knowmad Services Inc.
http://www.knowmad.com
---------------------------------------------------------------------
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]
