Is it related to this? "Bug in Multi Adapter Lookup"?
('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 <[EMAIL PROTECTED]> 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
> 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 """
> <layer name="example.cms"
> <skin name="example.cms.ContentManagement"
> and the contents.html view starts with:
> <view name="contents.html" for="example.cms.interfaces.IContentContainer"
> 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"?
Zope3-dev mailing list