feature request: "Add-to" handlers instead of "Replace" handlers

["Randal L. Schwartz" <me...@stonehenge.com>]

It appears that for a given PerlMumbleHandler, the most specific scope
is used, like if a PerlFixupHandler is defined for a directory, it
supercedes any parent directory definition.  Certainly, if two
handlers are defined at the *same* "narrowness", we get both of them,
so the problem is not that it can't be done, but that it *isn't*
done. :)

What I'd like is an easy way to *push* an extra handler for a narrower
scope, so that I don't mess up a handler that's expected to be in
place for an entire area.  Maintenance is getting to be a headache
on all my specialized directories.

This is similar to what IndexOptions does.  If I say "IndexOptions
Foo" that overrides any "wider scoped" item.  But if I say
"IndexOptions +Foo", I get the outer scope *plus* the new item.

I *think* I can get what I want by putting a <Perl> section like:

    <Perl>
    Apache::Request->push_handler(PerlMumbleHandler => "Local::Thing");
    </Perl>

But that would seem to need to reparse and compile the <Perl> section
each pass through... can't be cheap.

Doug?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: feature request: "Add-to" handlers instead of "Replace" handlers

[Doug MacEachern <do...@pobox.com>]

On 16 Feb 2000, Randal L. Schwartz wrote:

> 
> It appears that for a given PerlMumbleHandler, the most specific scope
> is used, like if a PerlFixupHandler is defined for a directory, it
> supercedes any parent directory definition.  Certainly, if two
> handlers are defined at the *same* "narrowness", we get both of them,
> so the problem is not that it can't be done, but that it *isn't*
> done. :)
> 
> What I'd like is an easy way to *push* an extra handler for a narrower
> scope, so that I don't mess up a handler that's expected to be in
> place for an entire area.  Maintenance is getting to be a headache
> on all my specialized directories.

this has actually been in the ToDo for a few years, and was pushed to the
modperl-2.0/ToDo a year or so ago:
- improve the "stacked handlers" implementation, including:
  + config merging of AV*'s

you could actually pull it off today using a directive handler to override
Perl*Handler and merge the handlers, then use a PerlDispatchHandler to
call them.  but that's a bit too much effort.  another short-term option
would be you have your config generated in <Perl> sections, and handle the
merging there.