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

[Tres Seaver]

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

yuppie wrote:
> Hi Tres!
> 
> 
> Tres Seaver wrote:
>> yuppie wrote:
>>> 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.
> 
> I'm not just talking about CMF 2.1. I'm fine if the result of this 
> discussion is a roadmap that starts with CMF 2.2. But if there is no 
> realistic roadmap at all we might better revert all the 
> tools-as-utilities changes. The few utilities we have right now are not 
> worth the trouble. Starting the migration makes only sense if we have a 
> plan to finish it.
> 
>> 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.
> 
> Maybe that's your reason why you didn't argue against the proposal. I 
> consider the possibility to cache utilities just a side effect of 
> removing the REQUEST from the wrappers.

I thought that caching was the *reason* for removing the request;
otherwise, we could just re-wrap the tool in each 'getUtility' call and
it would have access to the request as it does today.

> This is not about making the implementation easier. This is about 
> defining what utilities are. If they provide self.REQUEST they become a 
> utility-view monster that has not much in common with Zope 3 utilities. 
> Reducing Zope 2 magic to a minimum if we use Zope 3 technology is a good 
> thing - even if that forces us to be more explicit about required 
> REQUEST arguments.

That's fine, but just means that we have to invent *new* utilities and
change application code to begin calling the new APIs:  right now,
nobody in the wild expects to pass a REQUEST to most of those methods.

Once the replacement utilities are available, we can start deprecating
the "tool-ish" APIs.  Note that such a change is *way* too late in the
release cycle for 2.1.



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

iD8DBQFGjlI4+gerLs4ltQ4RAp0wAJ9UsO4xpsRoAD/+AF4GluFtRgcO5QCfX5vz
4yZUy9yJzo6B2e6kUkH5sHg=
=R5uA
-----END PGP SIGNATURE-----