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