Re: [Zope-CMF] Re: [dev] tools-as-utilities roadmap
Am 06.07.2007 um 17:22 schrieb yuppie: 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. This makes a lot of sense to me. Did it get included in the last beta or is it roadmap stuff? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] Re: [dev] tools-as-utilities roadmap
Previously Charlie Clark wrote: Am 06.07.2007 um 17:22 schrieb yuppie: 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. This makes a lot of sense to me. Did it get included in the last beta or is it roadmap stuff? It is included. 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
Re: [Zope-CMF] Re: [dev] tools-as-utilities roadmap
Previously Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6 Jul 2007, at 17:22, yuppie wrote: Wichert Akkerman wrote: Previously Tres Seaver wrote: yuppie wrote: Tres Seaver wrote: yuppie wrote: 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. Speaking about roadmaps, we have had several mailing list discussions in the past where future plans or intentions get stuck in the list archives, but nowhere else. That makes it hard to keep track of actual development or bug fix tasks. Can I suggest that we also use the CMF collector to capture specific tasks? For example, knowing that tool FOO cannot be made a utility and the decision that we should go forward and create a new utility to replace the tool we should have a collector entry for the task develop FOO utility. Makes it much much easier to keep track of what's left to do to reach the more generic goals on the roadmap. +1 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
Re: [Zope-CMF] Re: [dev] tools-as-utilities roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6 Jul 2007, at 17:22, yuppie wrote: Wichert Akkerman wrote: Previously Tres Seaver wrote: yuppie wrote: Tres Seaver wrote: yuppie wrote: 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. Speaking about roadmaps, we have had several mailing list discussions in the past where future plans or intentions get stuck in the list archives, but nowhere else. That makes it hard to keep track of actual development or bug fix tasks. Can I suggest that we also use the CMF collector to capture specific tasks? For example, knowing that tool FOO cannot be made a utility and the decision that we should go forward and create a new utility to replace the tool we should have a collector entry for the task develop FOO utility. Makes it much much easier to keep track of what's left to do to reach the more generic goals on the roadmap. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGlzjBRAx5nvEhZLIRAsBUAKCh2Ka7MdlRKOUeOLaT897wYwj5SACfSkT8 ijQ06TdOOrSnxSm3LWMBrtI= =Q5Ol -END PGP SIGNATURE- ___ 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
Re: [Zope-CMF] Re: [dev] tools-as-utilities roadmap
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
Re: [Zope-CMF] Re: [dev] tools-as-utilities roadmap
Previously Tres Seaver wrote: -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. Aren't we talking about a post-2.1 roadmap now? 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
