yuppie 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 move on:

Scenario 1:

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.

Scenario 2:

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 correctly.

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

Reply via email to