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