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

[Tres Seaver]

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

I think Godefroid was arguing that methods which expect to be able to
acquire 'REQUEST' should be converted to view methods.  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.

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


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

iD8DBQFGjQpl+gerLs4ltQ4RAvpBAKCmwGizx1DWyFShVMGpHiy8LiO5aQCfb3Oe
k3SV4euN0N2U8AkgXKqu0tM=
=SOKU
-----END PGP SIGNATURE-----