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

[Godefroid Chapelle]

Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> yuppie wrote:
>> Hi!
>>
>>
>> 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 
>>>> 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).
>> 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.
> 
> Any method which already takes REQUEST as an argument can be left alone
> for now.

Right


> I think Godefroid was arguing that methods which expect to be able to
> acquire 'REQUEST' should be converted to view methods.  

Good : you clarify my thoughts.

> Some methods are
> "indirect" dependents (they call somthing which acquires REQUEST).  I
> think we'd handle those by turning them into view lookups (ideally), or
> by continuing to call the deprecated API (see below), perhaps
> suppressing the message.

suppressing which message ? the deprecation ?

> 
>>> 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.
> 
> I think we have to leave existing REQUEST-acquiring APIs alone, but
> deprecate them, and then implement them by calling *new* REQUEST-passing
> APIs.  I would rather add methods than add hackery around the default
> REQUEST argument, as it keeps the deprecation story cleaner.
> 

+1

> 
> Tres.

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