Tres Seaver wrote:
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.
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
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.
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
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests