Am 04.09.2012, 15:35 Uhr, schrieb Tres Seaver <tsea...@palladion.com>:
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.
+1
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
