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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

yuppie wrote:
> 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.

A caller which can't be modified to use the REQUEST-passing API *cannot*
be a utility method, period.

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

Yes.  I'd rather get 2.1 out, even with tools-which-can't-be-utilitiies
as they are, then delay.

Note that this problem is basically due to the desire to cache the
aq_chain for utilities:  if we punt on that, we can then defer this
whole issue.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGjVt2+gerLs4ltQ4RAhB5AKDFSkBdidQwPlAcy5l3eshZDQcJPACeNHr0
jOteDZZr1wQwds5PdhxcFtE=
=CVaU
-----END PGP SIGNATURE-----