On 5 September 2012 19:21, Laurence Rowe <l...@lrowe.co.uk> wrote:
> On 5 September 2012 17:15, yuppie <y.2...@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

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.)


Zope-CMF maillist  -  Zope-CMF@zope.org

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Reply via email to