[Zope-CMF] [dev] tools as utilities

[Laurence Rowe]

On 5 September 2012 13:26, yuppie <y.2012 at wcm-solutions.de> wrote:
> Hi Laurence!
>
>
> Laurence Rowe wrote:
>
>> On 5 September 2012 11:48, yuppie
>> <y.2012-E2EsyBC0hj3+aS/vkh9bjw at public.gmane.org> wrote:
>>>>>>
>>>>>> 2.) Site root lookup: =====================
>>>>>>
>>>>>> In several tools we still assume aq_parent(aq_inner(self)) is the
>>>>>> portal. Or other code uses the tool as context object, expecting root
>>>>>>   and request in its acquisition chain.
>>>>>>
>>>>>> These should be identified and replaced by
>>>>>> getUtility(IURLTool).getPortalObject() or other suitable code.
>>>>>
>>>>>
>>>>> Maybe we could add a convenience API for that?
>>>>
>>>>
>>>>
>>>> getToolByName can be used instead as it does the lookups.
>>>
>>>
>>>
>>> getToolByName is no option because it is part of the machinery that
>>> should
>>> become obsolete.
>>>
>>> getUtility(IURLTool).getPortalObject() might be overkill because it adds
>>> the
>>> request to the context. All the code that needs the request should be
>>> fixed
>>> already. Using queryUtility(ISiteRoot) should be sufficient.
>>>
>>> But AFAICS the only way to find all the places where this needs to be
>>> fixed
>>> is to set up a site with tools that are not stored in the site root.
>>
>>
>> How about introducing a new getPortal() function? It could simply use
>> getSite() then walk back down the acquisition chain until finding an
>> object that directlyProvides ISiteRoot. In Plone KSS can introduce
>> another 'component site' between its view and the portal itself.
>
>
> Not sure why the discussion takes this direction. My point was that several
> CMF tools/utilities might not work correctly if the site root is not their
> parent. The difficult part is not to look up the site root. The difficult
> part is to figure out where a lookup is required.
>
> 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.

Laurence