[Zope-CMF] [dev] tools as utilities

[Charlie Clark]

Am 04.09.2012, 15:35 Uhr, schrieb Tres Seaver <tseaver at 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