Right, any tool that now exists must directly map unto a local
utility, and that local utility must also have the same API.
If we in CMF 2.0 feel that most tools should be made into utilities,
we could register the utilities with a name, and use the old tool
name. getToolByName could then both try local acquicistion, and do a
query for a generic interface (ICMFTool?) with the name.
this is sort of what I'm thinking. I'd also like to backport whatever we
decide on to cmf1.6.
The other option is to keep the tools, but also register them as
utilities. That would probably need some changes in the utility
registration, though, from the primitive implementation that is in
I'm less for this. one of the big advantages that plone is looking
forward to is cleaning out the tool litter out of the portal root. I
think forward porting old tools to utilities is acceptable if we don't
force the change on developers.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests