After some back and forth CMF 2.1 will just mark the first step of the
tools-as-utilities refactoring. We now have a working
five.localsitemanager that adjusts the persistent components registries
to Zope 2, but right now only a few CMF tools can be used as utilities.
Many tool methods depend on self.REQUEST, which is not available in
The current state makes things more complex, not easier. So we need to
We declare all tool methods that use self.REQUEST instead of an explicit
REQUEST argument as broken. And fix the tools by adding new REQUEST
arguments. I guess one or two dozen methods would need that change in
CMF, many more in third party products.
We can add these arguments as optional arguments in CMF 2.1 and make
them required after a deprecation period. If you use only tools shipped
with CMF or adjusted to the new policy, you can start using getUtility
in CMF 2.1. If not, CMF 2.3 will be the first release that allows to use
getUtility for all tools.
Pros: The changes are simple, in CMF 2.3 we are done.
Cons: A lot of code needs to be modified. Especially third party code.
Scenario 1+2 :
The methods that depend on REQUEST are moved to browser views as below
instead of quickly fixed as in the scenario above. They can then be
deprecated on the tool.
Once a tool has been fixed as utility and views, we should deprecate its
use as tool (this might be implicit in the scenario above).
Pros: migration achieves better separtion of concerns
Cons: longer time to migrate away from tools (which will be long anyway,
as so many 3rd party products have some of those and the understanding
of the patterns will take time to percolate in the community.
We make dual use of tools. Each tool provides a tool interface (e.g.
IMembershipTool) and an utility interface (e.g. IMembershipUtility). In
most cases the utility interface will be a subset of the tool interface.
In the long run, tool methods that are not valid utility methods need to
be replaced by new utility methods or browser views.
We should add these new utility interfaces for all tools in CMF 2.1 and
use these instead of the tool interfaces for registering utilities. And
'getToolByInterfaceName' should be renamed to 'getUtilityByInterfaceName'.
getUtilityByInterfaceName('IMembershipUtility') would return the same
object as getToolByName(context, 'portal_membership'), but with a
different wrapper and less methods available.
Pros: No deprecation warnings, nobody is forced to switch to utilities.
Cons: This will take much longer, everybody has to work with tools and
utilities side by side for a long time. Might be confusing.
If as a community, we think utilities are the way, we should express it
clearly (even with deprecation warnings) : I think it would be wrong to
have coexisting calls to utilities and tools without deprecation warnings.
Iow, once the effort to fix/migrate a tool has been done, it should be
advertised so that we can learn it and stop asap to use it as a tool.
If, otoh, we are not sure the migration to utilities is the way, we
should not even begin it.
Opinions? Questions? Other scenarios?
PS: Sorry if my english is not accute enough to express all nuances
Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests