Godefroid Chapelle wrote:
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 utilities.
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).
There are many tool methods that depend on REQUEST, but most of them
take it as argument, not from the acquisition context. Separating all
these methods cleanly in utility methods and views will mean replacing
the tools by something new, not converting them to utilities.
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.
I'm afraid we don't have enough volunteers to implement this scenario.
Tools depend on each other and if your tool depends on a non-utility
tool you can't make it a utility. The quick fix I propose makes it easy
to start the migration - we can split off views later. And the pattern
is very simple: Adding REQUEST arguments where REQUEST is used.
A bird in the hand is worth two in the bush.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests