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
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;
especially when you take in to account that extra steps are needed for when
ordering is important (like rewrite rules).
>
> 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.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
