Am 05.09.2012, 11:48 Uhr, schrieb yuppie <>:

I use a single Zope instance for several small CMF sites and I use .zexp export and import for moving CMF sites from one Zope instance to an other. Works fine for me. Even with Plone sites.

Even if it works for you I'm not sure that this is a use case we should support.

The nastiest part of the bootstrapping issue is the fact that without the fallbacks currently in place you can't navigate to the Setup Tool of a CMF 2.2 instance and run the upgrades. The ZMI folder listing calls code that depends on CMF tools. But fixing these issues is not on the top of my list. I just mentioned them for the sake of completeness.

Which is fine and something we don't do often enough!

 2.) Site root lookup: =====================

 In several tools we still assume aq_parent(aq_inner(self)) is the
portal. Or other code uses the tool as context object, expecting root
 and request in its acquisition chain.
 These should be identified and replaced by
getUtility(IURLTool).getPortalObject() or other suitable code.
Maybe we could add a convenience API for that?
 getToolByName can be used instead as it does the lookups.
getToolByName is no option because it is part of the machinery that should become obsolete.

Not sure that is should actually ever become obsolete. Much as I am in favour of the interface-based lookup, these tools are an essential part of the CMF.

getUtility(IURLTool).getPortalObject() might be overkill because it adds the request to the context. All the code that needs the request should be fixed already. Using queryUtility(ISiteRoot) should be sufficient.

But AFAICS the only way to find all the places where this needs to be fixed is to set up a site with tools that are not stored in the site root.

That's a big ask.

Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to