Hi!

Wichert Akkerman wrote:
Previously Tres Seaver wrote:
yuppie wrote:
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.

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.


Cheers,

        Yuppie


_______________________________________________
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to