Previously Charlie Clark wrote:
> Am 16.11.2008 um 16:17 schrieb yuppie:
> > Questions: Is there a good reason why Plone doesn't register
> > portal_setup as utility? Does the same reason apply to CMFDefault?
> > Do we
> > have to support registered and not registered portal_setup tools?
> Does this relate to the discussions (earlier this year? last year?) on
> which tools should be moved to utilities?
> I fully support Jens' justification of the utility approach. Things
> are a bit weird at the moment with some things still being tools and
> others utilities but once I got used to the utility approach I found
> it saner.
> I don't think that we can support both approaches and if Plone needs a
> wrapper around the utility with access to the request object then
> surely that is something for Plone?
The problem is not Plone: the problem is that the setup tool invokes
import and export steps, which themselves can do any random thing.
Unfortunately in the Zope 2 world a lot of those random things still
expect self.REQUEST to be available. If you get the GS setup tool
via getUtility that is not true and you see unexpected things breaking.
That is why for Plone we decided to not register the setup tool as a
utility until we can be sure that none of the standard tools need
self.REQUEST or have utility-based variant.
Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests