On 5 September 2012 15:36, yuppie <y.2...@wcm-solutions.de> wrote:
> Hi!
> 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
>>> doesn't
>>> always return the portal object. And the fact it is stored with the
>>> request
>>> 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
>> of.
>> 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
> getUtility(ISiteRoot).
> - CMF 2.3 targets Zope 2.13 as primary platform. So we can't rely on Zope 4
> features.

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.

Zope-CMF maillist  -  Zope-CMF@zope.org

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Reply via email to