Hanno Schlichting wrote:
Maybe a compromise would be to only return those utilities back
acquisition wrapped that where registered as tools?
That sounds sensible to me; most "new" local utilities wouldn't really
behave the same way, I'm guessing.
Jens added a new function to CMFCore.utils called registerToolInterface
that registers a tools name and the interface that tool implements in a
global registry (a simple module level dict). The primary purpose is to
let getToolByName look up known tools by interface instead of using
While I'm not too proud of my persistent component registry proposed
earlier in this thread it could be extended easily to only return those
utilities back AQ-wrapped that are registered in the global tools registry.
See my attached aq-components.py file for a sample implementation.
Personally I think AQ-wrapping every utility is a bit too much as well.
I've written a number of new utilities for Plone 3.0 that while having
some persistent configuration don't need any Acquisition context.
Magically wrapping those might indeed lead to unexpected behavior.
That is my worry too. Worse, if people start *depending* on that aq
wrapping, we are going two steps forward and one step back. :)
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests