-----BEGIN PGP SIGNED MESSAGE-----
> 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.
>>> 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
>>>> 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.
> 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
> Or do you know any volunteers for reviewing each method, replacing them
> by better view or utility code and writing tests for those new
> Or do you prefer to keep things as they are over a less clean switch to
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
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
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
-----END PGP SIGNATURE-----
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests