Previously yuppie wrote: > 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.
+1 for Tres suggestion (door number 7? 8? ) > 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'm fine with that. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ 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