On Wed, 2003-12-10 at 12:06, Stas Bekman wrote:
> Geoffrey Young wrote:
> >>Am I
> >>correct to say that people don't need to work directly with
> >>Apache::ReadConfig? I think the only place this is needed when people
> >>mix config with non-config perl code in <Perl>, so that they need to
> >>switch 'package Apache::ReadConfig;' to start feeding things into the
> >>config.
> >
> >
> > no, you can also add entries directly to the Apache::ReadConfig namespace in
> > order to add configuration data.
> >
> > package Apache::Foo;
> > $Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
> > sub handler { };
> >
> > now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
> > there are a few modules on CPAN that do this, IIRC.
> >
> > it's similar to Apache->server->add_config() in mp2, but I've found that
> > method really not worth the trouble - it's goverened by overrides, so you
> > can never really trust that it will add the configuration data you pipe into it.
>
> That's exactly why people do *not* need to work directly with
> Apache::ReadConfig - they have Apache->server->add_config() (and we are
> talking about mp2). If people can achieve the same thing without using
> Apache::ReadConfig, I think it should be completely deprecated, which avoids
> the problem altogether. That's why I wanted to know if there are cases where
> it's absolutely needed and you can't go without it.
Like I just said, one problem is that from within a <Perl> block, you
would possibly need to have access to the current server object.
Otherwise you'll be adding your configuration to the topmost server, and
not the current VHost your <Perl> section is in.
But if that's the only issue preventing getting rid of
Apache::ReadConfig alltogether, I would be more than happy to make the
right server object accessible from within <Perl> sections in a global
variable or sth similar.
> I think this case:
>
> <Perl>
> package Foo;
> my $whatever = whatever();
> package Apache::ReadConfig;
> $User = $whatever;
> </Perl>
>
> can now become:
>
> <Perl>
> package Foo;
> my $whatever = whatever();
> Apache->server->add_config("$User $whatever");
> </Perl>
>
> Though it's probably not going to be simple for creating more complex config
> directives, e.g complex containers. Can you think of a good solution for that
> case?
Could probably make use of a subclass of Apache::PerlSections for this.
PerlModule Foo
package Foo;
use Apache::PerlSections::Processor;
$User = 'gozer';
$Location{"/this"} = { "Options" => "+ExecCGI"};
Apache::PerlSections::Processor->readnamespace("Foo");
Or something like that.
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
--------------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
