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
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.
Zope-CMF maillist - Zope-CMF@zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests