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

[Jeff Shell]

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. This is a major blocking / "freaking out" kind of
issue. I'm trying to figure out now how to crawl through the debugger
and test the 'getMultiAdapter' lookup for this skin + object to
compare the results and hopefully.. I don't know. I have a pretty
complex view declaration that's meant to replace 'contents.html' for a
lot of our containers, and I'm hoping that I don't have to re-declare
the view for each container type. I guess I should also learn more
about how everything collaborates to establish an objects interfaces
and in what order so I can ensure that the base Zope interfaces are
lower on the providedBy list?

On 12/12/05, Jeff Shell <eucci.group at gmail.com> wrote:
> Today I finally got around to installing Zope 3.2b1 and started
> testing one of our sites against it. I'm running into a few problems,
> some of which are my fault, some that I don't quite understand, and
> one that is really bad.
>
> We have been basically rolling a custom CMS in Zope 3, and the content
> management skin that we made has been working wonderfully in Zope 3.1.
>
> One of the key parts of our CMS's user interface is a custom contents
> view that uses MochiKit for javascript/DOM based table sorting (easy
> sorting on item name, title, and size), and uses MochiKit's AJAX
> support for inline renaming/retitling of items in the container.
> That's registered as 'contents.html' for our own base contentcontainer
> interface. We've also made a custom metadata view that allows editing
> of keywords (subjects).
>
> In Zope 3.1.0 both of those worked fine.
>
> In Zope 3.2b1, I'm getting the Rotterdam or default contents view,
> wrapped up in our template. The same goes for the custom '@@+' view
> I've made for the same objects, which is used to filter certain Zope
> entries out of the add menu. For our container objects, I'm also
> getting the Zope meta-data view, but on some of our custom content
> objects I get our replacement view.
>
> I use our own menu, 'cms_views', for tabs, and have contents and
> EditMetaData registered as actions.
>
> If I rename my 'contents.html' view to 'contentsplus.html', I can see it fine.
>
> Here's my skin setup:
>
> from zope.publisher.interfaces.browser import IBrowserRequest
> from zope.publisher.interfaces.browser import IDefaultBrowserLayer
> from zope.app.rotterdam import rotterdam
>
> class CMS(IBrowserRequest):
>     """The `cms` layer."""
>
> class ContentManagement(CMS, rotterdam, IDefaultBrowserLayer):
>     """ The Skin """
>
> configure:
>   <layer name="example.cms"
>       interface="example.cms.skin.CMS"/>
>   <skin name="example.cms.ContentManagement"
>       interface="example.cms.skin.ContentManagement"/>
>
> and the contents.html view starts with:
>   <view name="contents.html" for="example.cms.interfaces.IContentContainer"
>       permission="example.cms.ManageContent"
>       layer="example.cms.skin.CMS"
>
> I'm referring to the layer with its interface path in ZCML, always.
>
> If I moved 'rotterdam' out of the base interfaces for the
> ContentManagement skin and set it as the base for the CMS layer
> object, the same behavior still shows up.
>
> This setup works as I expected it to in Zope 3.1, but breaks in Zope 3.2.
>
> FWIW, I opened up a debugzope session in both Zope 3.1 and 3.2 in this
> same configuration just to check the list of providedBy(obj) for the
> same folder in each site, to see if the interface resolution order
> might have changed, but the lists appear to be identical.
>
> Bug? Or did I do something wrong in my Zope 3.1 implementation that
> Zope 3.2b1 has "fixed"?
>