On Thu, May 6, 2010 at 10:49 AM, Chris McDonough <chr...@plope.com> wrote:
> On Thu, 2010-05-06 at 10:36 -0400, Chris Rossi wrote:
>> On Thu, May 6, 2010 at 4:14 AM, Charlie Clark
>> <charlie.cl...@clark-consulting.eu> wrote:
>> > Am 06.05.2010, 10:10 Uhr, schrieb Chris Withers <ch...@simplistix.co.uk>:
>> >> This is spot on, and would, in theory, allow an app to override a
>> >> library that overrides a framework.
>> > Cue lots of Jim like "wooah!" comments and "it's all Chris' fault" in the
>> > code! ;-)
>> I hate to just make more work for Chris M. I'm happy to add this to
>> my todo list. I have a lot on my plate right now, so don't expect a
>> timely implementation, but I'll try to get to it . . . . sometime.
> I'm actually not 100% confident that I understand the syntax, so I don't
> think I could implement it yet anyway.
> With "ovverides='some.funcion.or.method'", is the function or method
> being overridden assumed to have a view configuration attached to it
> that matches the overriding view configuration? If so, that's a little
> weird. What if it has different view configuration arguments or or no
> view configuration arguments at all?
> A good number of view configuration overrides as performed via ZCML
> don't require creatign separate view callable (like changing the
> rendererer), so constructing one just to be able to decorate it, then
> delegating to the original, seems a little suspect.
> I'm also not sure that this can be advertised as an overrides strategy
> 100% comparable to ZCML unless all the various ZCML directives get
> Python declarative equivalents.
> So.. yeah, I think there's a cool idea lurking in here, but I'm not sure
> we found it yet.
Repoze-dev mailing list