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.
Cheers,
Yuppie
_______________________________________________
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
