[Zope-CMF] [dev] tools as utilities

[Laurence Rowe]

On 5 September 2012 19:21, Laurence Rowe <l at lrowe.co.uk> wrote:
> On 5 September 2012 17:15, yuppie <y.2012 at wcm-solutions.de> wrote:
>> Laurence Rowe wrote:
>>>
>>> Maybe I'm missing something, but the various methods of IURLTool rely
>>> on portal.getPhysicalPath() returning the correct result. Take
>>> getRelativeContentPath for example:
>>>
>>> portal is at /folder/portal
>>> content is at /folder/portal/content
>>> getUtility(IURLTool).getPortalObject().getPhysicalPath() will be
>>> ['portal']
>>> getUtility(IURLTool).getRelativeContentPath(content) will be ['porta',
>>> 'content'] instead of ['content']
>>>
>>> You'd need to stop having any portals contained in folders, something
>>> that's fine for new sites but will prevent upgrades.
>>
>>
>> Not sure who is missing something and what. Just a wild guess:
>>
>> Are you aware of the fact that five.localsitemanager just removes the
>> RequestContainer, not the complete acquisition chain?
>>
>> And that CMF 2.3 adds a RequestContainer in getPortalObject()?
>
> Ok, I wasn't aware that five.localsitemanager restored a partial aq
> chain. The RequestContainer is removed to avoid caching old requests
> as part of the aq_chain of utilities.
>
> Instead of removing the RequestContainer, it could be replaced with a
> zope.globalrequest aware RequestContainer. That might be cleaner than
> rewrapping in individual utilities, and would work with Zope 2.13.

I gave this a go in
http://zope3.pov.lt/trac/changeset/127722/five.localsitemanager/branches/global-request-container

It seems to work fine with the CMF trunk tests even when I remove all
RequestContainer wrapping from both CMFCore and CMFDefault (the
CMFDefault tests then fail with five.localsitemanage trunk.)

http://zope3.pov.lt/trac/changeset/127724/Products.CMFCore/branches/global-request-container
http://zope3.pov.lt/trac/changeset/127726/Products.CMFDefault/branches/global-request-container

Laurence