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 Repozeemail@example.com http://lists.repoze.org/listinfo/repoze-dev