Stas Bekman wrote:
I'm trying to take care of this todo item:
-Apache::perl_hook: -should have this or something check if PerlOptions allows the given -handler/feature to be used.
It works, though since the hooks implemenation is very different in 2.0, we can't just call Apache::perl_hook($r) at least because there are overlapping
hooks (e.g. Unset)
So first of all I've called the method: is_hook_enabled
and it checks srv config flags when called as $s->is_hook_enabled($hook_name) or dir config flags if called as $r->is_hook_enabled($hook_name).
Is that a healthy API? Or should we use:
my $dir_cfg = $self->get_config($s, $r->per_dir_config); my $srv_cfg = $self->get_config($s);
add call:
$dir_cfg->is_hook_enabled($hook_name); $srv_cfg->is_hook_enabled($hook_name);
anyways, here is the patch of the current implementation and tests:
Thinking more about it, and since we already change the API, it should probably be called is_option_enabled, or even is_perl_option_enabled so not to confuse with native Options, which we may provide an api for later on, now that we have a parsed config tree. So we will have:
is_perl_option_enabled('ParseHeaders'); # for PerlOptions +ParseHeaders is_option_enabled('FollowSymlinks'); # for Options FollowSymlinks
Any comments on this API change/extending?
__________________________________________________________________ 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]
