On 5 September 2012 16:26, yuppie <y.2...@wcm-solutions.de> wrote:
> 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
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.
Zope-CMF maillist - Zope-CMF@zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests