Stas Bekman wrote:
I'm trying to take care of this todo item: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:
-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:
is_perl_option_enabled('ParseHeaders'); # for PerlOptions +ParseHeaders
is_option_enabled('FollowSymlinks'); # for Options FollowSymlinks
Comments?
__________________________________________________________________
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]
