[Zope-CMF] [dev] tools as utilities

[yuppie]

Hi!


Charlie Clark wrote:
> 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?

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.

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.

>>> 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.

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.


Cheers,

	Yuppie