[Zope-CMF] [dev] tools as utilities

[Laurence Rowe]

On 5 September 2012 16:26, yuppie <y.2012 at wcm-solutions.de> wrote:
> Hi!
>
>
>
> Laurence Rowe wrote:
>>
>> Precisely because CMF 2.3 targets Zope 2.13 - persistent local
>> utilities returned by getUtility lack any sort of acquisition context
>> in Zope2, so the result of getUtility(ISiteRoot) will return
>> aq_base(portal), which is unlikely to be useful. getSite() instead
>> returns the component site set as a thread local during traversal.
>> Assuming that has an acquisition context including the portal then we
>> have the portal object with its correct acquisition context so can
>> call portal.absolute_url().
>>
>> Another alternative would be to set the portal directly as a thread
>> local during the traversal (just as setSite() is called) and clear it
>> at the end of the request.
>
>
> Now I see your point. But
>
> - getUtility(IURLTool).getPortalObject() also returns the portal with a
> complete acquisition chain.
>
> - if tools are looked up as utilities, they don't have the request in their
> acquisition chain. That might cause trouble if Plone switches to CMF 2.3,
> but in CMF itself all code that tries to get the request by acquisition from
> a tool was fixed. That also means that tools depending on the portal as
> parent *don't* depend on a portal with request in the acquisition chain. So
> if this has to be fixed inside the tools, getUtility(ISiteRoot) is
> sufficient.

Maybe I'm missing something, but the various methods of IURLTool rely
on portal.getPhysicalPath() returning the correct result. Take
getRelativeContentPath for example:

portal is at /folder/portal
content is at /folder/portal/content
getUtility(IURLTool).getPortalObject().getPhysicalPath() will be ['portal']
getUtility(IURLTool).getRelativeContentPath(content) will be ['porta',
'content'] instead of ['content']

You'd need to stop having any portals contained in folders, something
that's fine for new sites but will prevent upgrades.

Laurence