[Zope3-dev] Interface implementation declaration weight (was Re: View lookup changes in Zope 3.2?)

Jeff Shell eucci.group at gmail.com
Tue Dec 13 22:34:39 EST 2005


On 12/13/05, Jim Fulton <jim at zope.com> wrote:
> Jeff Shell wrote:
> ...
> > Going through a lot of debugging, it looks as through it has to do
> > with how things are ranked in
> > zope.interface.adapter.AdapterLookup.lookup() for multi-adapters.
>
> Yup.
>
> I don't know enough about the relationshipd between your content
> interfaces, to comment directly, but I will note that the intent
> was that content interface would have precedence over skin.  This
> was not the case before due to a bug in  multi-adapter lookup.

I'm sure that's the issue here. The software worked "fine" in 3.1, or
basically worked in a way that I assumed was fine.

The situations where this is affecting us is in some of our oldest
major Zope 3 code, and it's code we've had issues with before. Those
issues, and this one, are likely due to it being early code and us
(namely me) still learning a lot of core concepts and maybe not
applying them so well.

So I have a new question: with the different ways that 'implements'
and 'provides' may be applied to an object, is there a document that
details how those affect the interface/spec resolution order?

I'm thinking of things like interface inheritance, class inheritance,
ZCML's 'implements' directive, 'zope.interface.implements(IFoo)' in a
Python class statement, and any interfaces said to be provided by a
particular instance - how much weight does each method provide?

A concrete example being: my content management system wants to
provide a new 'contents.html' view for the content management skin for
all of my different container types, most of which subclass core Zope
objects somewhere along the way. I thought that having a root
'IContentContainer' interface was the best way to go - but as
subobjects embrace and extend other container types, the
'IContentContainer' interface seems to be getting buried in the
resolution order - for the object that I debugged, it ranked 12, while
Zope's IFolder ranked 4th and a more specialized CMS content folder
interface ranked 3rd. But I want the specialized contents view, which
has a lot of sub-pages, so its not something I'd want to have to
duplicate in ZCML for every interface, to work for all of them. How
can I ensure that IContentContainer (or IManagedContent, or any of my
other core-core-core interfaces) DO take precedence over core Zope
interfaces for situations where I subclass core Zope objects?


More information about the Zope3-dev mailing list