On 5 September 2012 15:36, yuppie <y.2...@wcm-solutions.de> wrote:
> Laurence Rowe wrote:
>> On 5 September 2012 13:26, yuppie
>> <y.2012-E2EsyBC0hj3+aS/vkh9...@public.gmane.org> wrote:
>>> I don't think relying on getSite() is a good idea. As you mention it
>>> always return the portal object. And the fact it is stored with the
>>> in its context is just an accidental side effect. What would be the
>>> advantage compared to using getUtility(ISiteRoot)?
>> While it's an accidental side effect, it is something we could make use
>> Once I merge my parent pointers branch into Zope 4 (hopefully soon),
>> RequestContainer wrapping is completely removed and all objects with
>> __parent__ pointers to the Application root will always have their
>> correct context (and be able to acquire the REQUEST.) This will allow
>> getUtility(ISiteRoot) to function correctly, along with any other
>> tools/utilities that have their __parent__ pointer set. The branch
>> lives on a temporary repository at
>> https://github.com/zopefoundation/Zope/tree/elro-parent-pointers, I
>> expect some problems with CMF trunk following the removal of
>> RequestContainer, but I hope to address these once I get it merged.
>> I'll try and post a proper writeup of its state and how to make it run
>> in the next few days.
> Great! Making the REQUEST attribute of the app object a shortcut for using
> globalrequest looks like a good BBB solution. But
> - this is still a Zope 2 (Zope 4) specific feature. I hope you don't plan to
> recommend using it in new code. A PendingDeprecationWarning might be useful
> to figure out which code is using that legacy feature.
> - that doesn't explain why you propose using getSite() instead of
> - CMF 2.3 targets Zope 2.13 as primary platform. So we can't rely on Zope 4
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.
Zope-CMF maillist - Zope-CMF@zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests