>Except that (and I have to check this to be ABSOLUTELY shure but)
>PerlModule
>Apache::DBI happens first, THEN startup.pl.
only if you code it the way you did below, which isn't terribly portable.
see http://perl.apache.org/guide/perl.html#use_require_do_INC_and
basically, it's a bad programming practice not to use() modules in the code
that needs them. it works if you call PerlModule before you use() the
module, but again, it requires you to pay better attention to your
httpd.conf than you ought to.
consider writing an Apache module for CPAN, relying on, say, Apache::Log
calls, but failing to use Apache::Log in your module. If you have a
PerlModule Apache::Log everything works - until somebody else tries to run
your code with a different configuration. There's what works and then
there's how you ought to do things.
>
>I just checked, and it works exactly that way when the httpd.conf
>directives
>are in the following order:
>
>PerlModule Apache::DBI
>PerlRequire /etc/httpd/perl/lib/startup.pl
>
>Since Apache::DBI is now loaded into the (single) perl interpreter's
>symbol
>table, and since the above call to connect_on_init() is a method call
>(vs an
>exported symbol), calling methods on it are valid, and can be easily
>wrapped
>as I suggested in an "if($ENV{MOD_PERL}) {}" block. Explicitly, it is
>*NOT*
>required to 'use Apache::DBI ();' in startup.pl to do this.
this is just a particular gripe of mine, but I think we ought to be past the
$ENV{MOD_PERL} thing by now... startup.pl is a mod_perl idiom. if you are
designing web applications that depend on things like the mod_perl API,
Apache::DBI, and using the hooks into the Apache request cycle then you are
already way beyond making a startup.pl script portable between mod_perl and
other web environments.
--Geoff
