perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philippe M. Chiasson" <>
Subject Re: [Patch mp2] PerlSections namespace
Date Wed, 10 Dec 2003 20:49:57 GMT
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"};

Or something like that.

> __________________________________________________________________
> Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
>     mod_perl Guide --->
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)    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}'

View raw message