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.
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.
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.
Cool.
--
__________________________________________________________________ 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
