[Zope-CMF] [dev] tools as utilities

yuppie y.2012 at wcm-solutions.de
Wed Sep 5 13:36:18 UTC 2012


Hi!


Laurence Rowe wrote:
> On 5 September 2012 13:26, yuppie <y.2012-E2EsyBC0hj3+aS/vkh9bjw at 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



More information about the Zope-CMF mailing list