[Zope3-dev] Re: View lookup changes in Zope 3.2?

[Jeff Shell]

On 12/13/05, Jim Fulton <jim at zope.com> wrote:
> Jeff Shell wrote:
> > Is it related to this? "Bug in Multi Adapter Lookup"?
> > http://www.zope.org/Collectors/Zope3-dev/396
> > ('fixed' in Zope 3.2b1)
> >
> > That's my suspicion.
>
> That would be my suspicion too.  It should be easy to test.
> Just get a check out and merge out that change:
>
>    svn merge -r40385:40384 svn+ssh://svn.zope.org/repos/main/Zope3/trunk
>
> and see if you still have the problem.  If you don't, then you still have some
> digging to do.  If you do, then .... well, lets get into that if you
> verify that that is the problem.
>
> This was an honest-to-gosh bug.  It is also the case that there were
> registrations in Zope that depended on this bug and had to be changed.

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. I
haven't stepped through it in the debugger in Zope 3.1 yet, but I just
got finished doing it in Zope 3.2 and these are my results:


>>> from zope.app.component.hooks import setSite
>>> from zope.publisher.browser import TestRequest
>>> from zope.app import zapi
>>> from zope.publisher.interfaces.browser import ISkin, IDefaultSkin
>>> conman = zapi.getUtility(ISkin, name='br.cms.skin.ContentManagement')
>>> customer = debugger.root()['customer']
>>> setSite(customer)
>>> winter = customer['winter']
>>> contents = zapi.queryMultiAdapter((winter,
TestRequest(skin=conman)), name='contents.html')
>>> contents.__class__.__bases__
(<class 'zope.app.container.browser.contents.Contents'>, <class
'zope.app.publisher.browser.viewmeta.simple'>)

So then I do a pdb.run("zapi.queryMultiAdapter((winter,
TestRequest(skin=conman)), name='contents.html')") and it's inside
AdapterLookup that I get the following. When all of the adapters for
this container and the request with the name 'contents.html' are
looked up:

(Pdb) pp byname.get(name)
[((<InterfaceClass zope.app.folder.interfaces.IFolder>,
   <InterfaceClass zope.publisher.interfaces.browser.IDefaultBrowserLayer>),
  <class 'zope.app.publisher.browser.viewmeta.Contents'>),
 ((<InterfaceClass br.cms.interfaces.IContentContainer>,
   <InterfaceClass br.cms.skin.CMS>),
  <class 'zope.app.publisher.browser.viewmeta.contents.html'>),
 ((<InterfaceClass br.cms.interfaces.IContentFolder>,
   <InterfaceClass zope.publisher.interfaces.browser.IDefaultBrowserLayer>),
  <class 'zope.app.publisher.browser.viewmeta.Contents'>)]

The one the I want is the second set in this list, 'br.cms.skin.CMS'.
Unfortunately, that's the one that loses out in the ranking algorithm
that ranks based on interface's ranking in the spec resolution order.
(NOTE: The IContentContainer there is different than the Zope
IContentContainer! This has cause some confusion in house)

The first one (IFolder, IDefaultBrowserLayer) produces the rank: (4, 4)
The second one, which I want, (IContentContainer, CMS) produces the rank (12, 2)
The third one, which I'm suspecting is generated from a zcml
containerViews directive, wins with the rank (3, 4).

It wins because the 'best' tuple is kept around. A rank wins 'best' by
being less than the current 'best', and (3, 4) is less than all of
them.

I understand why this is happening, but it's (obviously) not what I
want to have happen. I want MY skin layer's declaration of
'contents.html' to win out. It actually works for all container types,
so maybe I need to declare it for a root Zope container interface for
my layer?

I've been living under the impression that the layer a view was
assigned to had higher precedence than may have been intended, and
maybe this is part of the discussion going on in the
'SimplifySkinning' proposal/thread which I should take a closer look
at.