[Zope-CMF] Re: [dev] tools-as-utilities roadmap

[Godefroid Chapelle]

yuppie wrote:
> Hi!
> 
> 
> 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?
> 
> 
> Cheers,
> 
>     Yuppie
> 

PS: Sorry if my english is not accute enough to express all nuances 
correctly.

-- 
Godefroid Chapelle (aka __gotcha)- BubbleNet  http://bubblenet.be