Wichert Akkerman wrote:
Previously Tres Seaver wrote:
Tres Seaver wrote:
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.
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.
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.
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
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
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.
Aren't we talking about a post-2.1 roadmap now?
Well. The 2.1 changes are based one the assumption that we switch
quickly and completely to utilities, making all tools work as utilities.
The roadmap proposed by Tres means it will take several years and we'll
have to work with tools and utilities side by side for a long time.
I can live with that approach, but would like to see CMF 2.1 adjusted:
'getToolByInterfaceName' is a completely misleading method name if tools
will not become utilities. This method has no 'context' (or 'REQUEST')
argument, so it can't return tools. It returns utilities.
'getUtilityByInterfaceName' would be a much better name for a
'getUtility' replacement used in untrusted code.
I propose to run a search 'n' replace *before* the next beta.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests