Am 04.09.2012, 15:35 Uhr, schrieb Tres Seaver <>:

I'd rather not add any cruft to support .zexp imports, which have seemed
fundamentally broken to me for a long time.

I'd agree on that. Occasionally, and on a strict, per object basis, they have their use but not at the same as updates. Or what do you have in mind?

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.

3.) Action providers: =====================

Action providers are still registered and looked up by ID.

Most Actions were moved to the Actions Tool. Only two 2 special Action
 providers are left: Types Tool and Workflow Tool.

I have no plans to convert that registry to something based on utility
 lookup. I guess it would be better to create specialized 'object' and
 'workflow' categories that are linked to the Types Tool and the
Workflow Tool. But that's a different story.

4.) Skins: ==========

The Skins Tool lookup is based on the getSkinsFolderName method.

If there are no objections, I'll replace that by
queryUtility(ISkinsTool) without providing any backward compatibility
 code for getSkinsFolderName.
+1.  Thanks for the analysis.


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