On 4/29/09 2:41 AM, Malthe Borch wrote:
> 2009/4/29 Chris McDonough<chr...@plope.com>:
>> When you do need it, the multiplexing is awful handy (e.g. when trying to
>> look up a view based on a context type and a request type).
>
> Except there's always this situation:
>
> View 1)
>
> for="IDocument IRequest"
>
> View 2)
>
> for="Interface IPostRequest"
>
> Let's say that you wanted always to do something special for POST
> requests. This won't work; you have to change (1) to
>
> for="IDocument IGetRequest"
I'll take your word for it. Who the hell knows how that works? This is due to
the "Interface" wildcard? I just never try to do anything this complicated.
I'd just do:
view 1)
for="IDocument IRequest"
view 2)
for="IDocument IPOSTRequest"
and I'd repeat that for any "context" type that I also wanted to adapt on.
If this really is due to the wildcard thing: IMO, zope.component should probably
try to match any lookup against wildcard registrations dead last. I'm sorta
surprised it doesn't.
But in general, interface inheritance seems pretty evil. I'd rather that it
just composed the "requires" interfaces by looking up the MRO of the instance
and its base classes rather than combining that with the concept of an "iro".
> I find that the ordering of multi-adaptation hinders me in using them
> in a clean way; perhaps the solution is to have some kind of priority
> token, e.g.
>
> for="Interface +IPostRequest"
>
> You can argue that anything more than we have now is too complex;
> still, for multiplexing, the default adaptation ordering isn't always
> desirable.
I think maybe the right thing to do there (if we can't fix it) is to just
repeat
ourselves in configuration.
- C
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
