[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: Filter.pm errors
From:       Doug MacEachern <dougm () cp ! net>
Date:       1999-03-31 22:07:03
[Download RAW message or body]

At 06:48 PM 3/17/99 +0000, Ken Williams wrote:
>Joshua Chamas's message:
>>
>>> I mentioned that I had modified Apache::ePerl and Apache::Registry to
>>> work with Apache::Filter but Doug MacEachern (I think) said that this
>>> isn't the way to go: I should subclass Apache::Registry and create an
>>> Apache::FilterRegistry. It seems to me that this is exactly what
>>> Apache::Filter is trying to avoid, namely having two modules, one
>>> normal and one for Apache::Filter (as is the case with
>>> OutputChain). Ken, what's your view?
>>> 
>>
>>I agree with this perspective.  For only one dir_config call and 
>>a couple conditional checks on what could be a global $FILTER, 
>>Registry can be made filter aware.  Thats what Apache::ASP did. 
>>You might argue against code bloat, but I think that Filter
>>is a great advance, and should be integrated with Registry
>>if possible.  
>
>Forgot to say: I can see a good reason for not incorporating this
>functionality into Apache.pm (thus the need for Filter.pm), but I think that
>Apache::Registry is exactly the kind of thing that will benefit from being
>Filter-aware, and will make people's lives easier by being so.
>
>If the subclass code can be absolutely TINY, then perhaps a subclass makes
>sense.  But if any of the Registry code has to be duplicated in the
>subclass, I'm against it.

have a look at Apache::RegistryNG, if you see a good way to subclass or add
filter support directly, that's cool.  but the current Apache::Registry is
a mess, no more new features there.  once NG is tested well enough, it can
replace the existing Registry.pm

-Doug

[prev in list] [next in list] [prev in thread] [next in thread]