On Thu, 2003-12-11 at 10:11, Stas Bekman wrote:
> Geoffrey Young wrote:
> >
> > Stas Bekman wrote:
> >
> >>Philippe M. Chiasson wrote:
> >>
> >>
> >>>>so maybe at startup it's not a bad idea after all :)
> >>>
> >>>
> >>>
> >>>So, does this mean that you don't have a specific objection against
> >>>deprecating (or tossing) direct access to %Apache::ReadConfig:: in the
> >>>future in favor of ->add_config("User foo") ?
> >>
> >>
> >>The problem with add_config() is that it wants a string as if you've
> >>written it in httpd.conf language. Taking an access to
> >>%Apache::ReadConfig:: away takes away the ability to use perl structs to
> >>autovivify complex constructs. e.g. how do you build a complex vhost
> >>with nested containers using add_config?
> >
> >
> > well, it might be different than it was, but I guess it ends up being
> > similar to Apache->httpd_conf
>
> Yup
> http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache_E_gt_httpd_conf_
> (and I have a typo in it, will fix shortly)
>
> > Apache->server->add_config([ <<END ]);
> > <VirtualHost $vhost>
> > ServerName $name
> > ServerAlias $alias
> > </VirtualHost>
> > END
> >
> > in truth, now that I look at it, I'm not sure that's any more or less
> > difficult or flexible than
> >
> > %directives = (
> >
> > ServerName => $name,
> > ServerAlias => $alias,
> > );
> >
> > $VirtualHost{$vhost} = \%directives;
>
> but that's a simple example. If you want to have more complex config and if
> you have some engine that generates each component separately it's going to be
> harder to put them together. It's just so intuitive to use perl structs for
> that purpose.
Yes, and I am planning on writing 2 subclasses to Apache::PerlSections
to handle either a namespace name, or a hash ref, as in:
package My::Config;
$Location{'/foo'} = { [...] };
@Alias = qw(/this /that);
and
Apache::PerlSection->add_namespace("My::Config");
or
my %My::Config = (
'Location' => { '/foo' => { [...]}},
'Alias' => qw(/this /that),
);
and
Apache::PerlSection->add_hash(\%My::Config);
So, in the end, we can have it all ;-) (method names subject to change
though)
> > especially when you take in to account that extra steps are needed for when
> > ordering is important (like rewrite rules).
>
> True. One needs to use Tie::IxHash for this purpose.
Yes, I am aware of this problem, and will be fixing it as well.
> >>may be we could have an alternative method, accepting an SV (e.g. a hash
> >>ref which represents a container) which perl will then convert to a
> >>string and feed to add_config?
> >
> >
> > I suppose that could work too.
See above examples.
> Cool.
--
--------------------------------------------------------------------------------
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
