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

[yuppie]

Hi!


Godefroid Chapelle wrote:
> Tres Seaver wrote:
>> yuppie wrote:
>>> Godefroid Chapelle wrote:
>>>> 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.

I agree this is the cleaner solution *if* someone does the necessary 
work. But it's no useful approach if that means deferring the 
tools-as-utilities changes indefinitely.

>> 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),

We only can continue to use the deprecated API if caller *and* callee 
are no utilities.

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

The quick and dirty implementation would be adding basically the same 
methods with different names and an additional REQUEST argument or a 
required instead of an optional REQUEST argument. Is that what you 
propose and prefer over adding a required REQUEST argument to existing 
methods?

Or do you know any volunteers for reviewing each method, replacing them 
by better view or utility code and writing tests for those new 
implementations?

Or do you prefer to keep things as they are over a less clean switch to 
utilities?


Cheers,

	Yuppie