[Zope-CMF] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open dreamcatcher - setChainForPortalTypes doesn't allow to set default chain, [Accepted] http://www.zope.org/Collectors/CMF/475 mhammond - Windows DevelopmentMode penalty in CMFCore.DirectoryView, [Accepted] http://www.zope.org/Collectors/CMF/366 Pending / Deferred Issues - FSPropertiesObject.py cannot handle multiline input for lines, text attributes, [Deferred] http://www.zope.org/Collectors/CMF/271 - Can't invalidate skin items in a RAMCacheManager, [Pending] http://www.zope.org/Collectors/CMF/343 - workflow notify success should be after reindex, [Deferred] http://www.zope.org/Collectors/CMF/389 - Possible bug when using a BTreeFolder Member folder, [Pending] http://www.zope.org/Collectors/CMF/441 - purge_old in runAllImportSteps not working, [Pending] http://www.zope.org/Collectors/CMF/455 - Danger from Caching Policy Manager, [Pending] http://www.zope.org/Collectors/CMF/460 - properties setup handler: support for non-ascii strings, [Pending] http://www.zope.org/Collectors/CMF/468 - GenericSetup does not handle non-ascii data well, [Pending] http://www.zope.org/Collectors/CMF/471 - autocreation of catalog indexes, [Pending] http://www.zope.org/Collectors/CMF/472 - [GS] Error when choosing initial_configuration , [Pending] http://www.zope.org/Collectors/CMF/473 Pending / Deferred Features - Favorite.py: queries and anchors in remote_url, [Pending] http://www.zope.org/Collectors/CMF/26 - DefaultDublinCore should have Creator property, [Pending] http://www.zope.org/Collectors/CMF/61 - Document.py: universal newlines, [Pending] http://www.zope.org/Collectors/CMF/174 - portal_type is undefined in initialization code, [Pending] http://www.zope.org/Collectors/CMF/248 - CMFTopic Does Not Cache, [Deferred] http://www.zope.org/Collectors/CMF/295 - Wishlist: a flag that tags the selected action., [Pending] http://www.zope.org/Collectors/CMF/301 - CMFDefault should make use of allowCreate(), [Pending] http://www.zope.org/Collectors/CMF/340 - Nested Skins, [Deferred] http://www.zope.org/Collectors/CMF/377 - CatalogVariableProvider code + tests, [Pending] http://www.zope.org/Collectors/CMF/378 - CMF needs View-based TypeInformation, [Pending] http://www.zope.org/Collectors/CMF/437 - New getNextEvent Method, [Pending] http://www.zope.org/Collectors/CMF/462 - Support 'remove' attribute for skin-path/ nodes in skins.xml, [Pending] http://www.zope.org/Collectors/CMF/479 ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMF Tests:
Summary of messages to the cmf-tests list. Period Sat Apr 14 12:00:00 2007 UTC to Sun Apr 15 12:00:00 2007 UTC. There were no messages. ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] unresolved site manager related issues
Balazs Ree wrote: Acquisition is raping Zope3, it seems. That must surely be quotation of the month. :) Martin ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] unresolved site manager related issues
Dieter Maurer wrote: Alec Mitchell wrote at 2007-4-12 06:59 -0700: ... ... deprecation of getToolByName ... which is that there's no practical reason other than aesthetics to deprecate getToolByName at this point. A very good point: let's deprecate deprecations done just for aethetical reasons :-) Aesthetics were not the original reason for moving down this route, so it's a little unfair to cast it in that light. The main drivers, as I recall, were to encourage API usage that would allow us to move tools out of content space eventually, and to make code depending on CMF tools more consistent with newer code which may depend on new utilities (at least in the Plone world, there is a general consensus that we'd rather not have any more content-space tools from now on). Martin ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] unresolved site manager related issues
Rob Miller wrote: i'll add yet another me too to this chorus. removing getToolByName has become considerably more trouble than it's worth. currently, i see basically two options being suggested: - adding (and then living with) yet more code in Five, which changes the behaviour of clean, well established Z3 idioms in order to support Z2 components which require acquisition. - undeprecating an extremely widely used, intended-to-be-future-proof Z2 idiom, which would allow us to interact more simply and predictably with existing Z3 utility lookup code i guess it's pretty clear which one i support. ;-) For the record, my personal preference was to *not* deprecate getToolByName (yet), but to allow the use of getUtility and to have getToolByName use getUtility internally. This would encourage a more consistent API (as we develop new proper utilities) and eventually we'd be able to move tools out of content space, with getToolByName providing a (perhaps eventually deprecated) backwards compatible alias for older tools that graduated to utilities. When we first discussed this, no-one had thought about the acquisition dependency, I think. If it were so that no tools really dependent on acquiring things to function, I think that the above would have been a viable and forward-looking solution. It may yet be, but it seems the debate at this point is, can we make utilities be acquisition-independent and if not, do we go for a stopgap measure that may cause more problems than it solves, or do we need to wait. Also, having used the new API (import interface, use getUtility) I much prefer it to getToolByName. But that's just a personal preference. :) Martin ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] unresolved site manager related issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Kapil Thangavelu wrote: On Thu, 12 Apr 2007 06:16:23 -0400, yuppie [EMAIL PROTECTED] wrote: Hi! Philipp von Weitershausen wrote: yuppie wrote: Kapil's also right when he says that utilities by principle are context-less components. By principle all Zope 3 code might depend on setSite to work as expected. We just don't pass that 'site context' explicitly to the component as in Zope 2. contextual lookup is very a different notion, that context implementation dependence. utilities don't have context implementation dependencies in zope3, the majority of cmf tools do. Just so we are clear, can anyone point to a good example of a not-trivial-to-change place where CMF tools have inherent dependencies on acquisition? Security is inherently placeful in Zope2: it requires being able to verify that the logged-in user is authenticated in a user folder which is in the scope of the protected resource. As far as I'm concerned, Zope3's model is *not* intrinsically superior: it doesn't support the use cases of the Zope2 model at all. Let's just forget the Zoep3 is better mantra and find a workable near-term solution here: if we have to re-implement / tweak some Zope3 machinery to make it play nice in Zope2, then let us do so, rather than distorting both in a misguided effort at Zope3 purity. - If that means continuing to use 'getToolByName' for traditional tools which need Zope2 security, fine; folks who implement new utilities which don't need that compatibility can register them as pure utilities. - If it's easier to hack the LSM stuff to automagically wrap those returned utilities which implement IAcquisitionWhatever, fine; if that means in turn that folks must use the Zope2 LSM version in subsites, fine. This is not rape by any stretch of the imagination; this is adaptation at its best. Let's be pragmatic here, please. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGIml8+gerLs4ltQ4RAsw7AKCsq0mOeh5SVUHkln9qB81Hb7jyLgCggbC2 yQ225B+1CC4dHOXGj7F/Lvs= =yQEA -END PGP SIGNATURE- ___ Zope-CMF maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] unresolved site manager related issues
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Kapil Thangavelu wrote: On Thu, 12 Apr 2007 06:16:23 -0400, yuppie [EMAIL PROTECTED] wrote: Hi! Philipp von Weitershausen wrote: yuppie wrote: Kapil's also right when he says that utilities by principle are context-less components. By principle all Zope 3 code might depend on setSite to work as expected. We just don't pass that 'site context' explicitly to the component as in Zope 2. contextual lookup is very a different notion, that context implementation dependence. utilities don't have context implementation dependencies in zope3, the majority of cmf tools do. Just so we are clear, can anyone point to a good example of a not-trivial-to-change place where CMF tools have inherent dependencies on acquisition? Security is inherently placeful in Zope2: it requires being able to verify that the logged-in user is authenticated in a user folder which is in the scope of the protected resource. As far as I'm concerned, Zope3's model is *not* intrinsically superior: it doesn't support the use cases of the Zope2 model at all. Let's just forget the Zoep3 is better mantra and find a workable near-term solution here: if we have to re-implement / tweak some Zope3 machinery to make it play nice in Zope2, then let us do so, rather than distorting both in a misguided effort at Zope3 purity. - If that means continuing to use 'getToolByName' for traditional tools which need Zope2 security, fine; folks who implement new utilities which don't need that compatibility can register them as pure utilities. - If it's easier to hack the LSM stuff to automagically wrap those returned utilities which implement IAcquisitionWhatever, fine; if that means in turn that folks must use the Zope2 LSM version in subsites, fine. I guess the main worry is if we go down a route whereby we *always* need a zope 2 version and a zope 3 version of some piece of code. Of course, this is often the case anyway, but that doesn't mean we have to make the situation worse. KSS, for example, had a set of components that worked well across both zopes, and now needs conditional imports for its base classes. This is not rape by any stretch of the imagination; this is adaptation at its best. Let's be pragmatic here, please. The Hungarians have a colourful idea of language. :) Martin ___ Zope-CMF maillist - [EMAIL PROTECTED] 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] unresolved site manager related issues
Previously Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Kapil Thangavelu wrote: On Thu, 12 Apr 2007 06:16:23 -0400, yuppie [EMAIL PROTECTED] wrote: Hi! Philipp von Weitershausen wrote: yuppie wrote: Kapil's also right when he says that utilities by principle are context-less components. By principle all Zope 3 code might depend on setSite to work as expected. We just don't pass that 'site context' explicitly to the component as in Zope 2. contextual lookup is very a different notion, that context implementation dependence. utilities don't have context implementation dependencies in zope3, the majority of cmf tools do. Just so we are clear, can anyone point to a good example of a not-trivial-to-change place where CMF tools have inherent dependencies on acquisition? Security is inherently placeful in Zope2: it requires being able to verify that the logged-in user is authenticated in a user folder which is in the scope of the protected resource. As far as I'm concerned, Zope3's model is *not* intrinsically superior: it doesn't support the use cases of the Zope2 model at all. Let's just forget the Zoep3 is better mantra and find a workable near-term solution here: if we have to re-implement / tweak some Zope3 machinery to make it play nice in Zope2, then let us do so, rather than distorting both in a misguided effort at Zope3 purity. - If that means continuing to use 'getToolByName' for traditional tools which need Zope2 security, fine; folks who implement new utilities which don't need that compatibility can register them as pure utilities. - If it's easier to hack the LSM stuff to automagically wrap those returned utilities which implement IAcquisitionWhatever, fine; if that means in turn that folks must use the Zope2 LSM version in subsites, fine. My current preference would be to keep using getToolByName while we rewrite the tools to work as utilities. Once a tool works as a utility which does not need to be acquisition-wrapper we can deprecate use of getToolByName for just that utility. I have a suspicion that this will be easy for most utilities. We can put that framework in place for CMF 2.1 and start refactoring the tools into utilities on CMF trunk. 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] unresolved site manager related issues
Previously Wichert Akkerman wrote: I have a suspicion that this will be easy for most utilities. We can put that framework in place for CMF 2.1 and start refactoring the tools into utilities on CMF trunk. A quick look seems that there are a few common uses of acquisition in the tools: to get to the portal via tool.aq_inner.aq_parent, to get to the REQUEST object via self.REQUEST and use of absolute_URL. Some tools (URLTool, UndoTool) are already free of acquisition-use. This suggests that it should be quite doable to do a CMF 2.2 where tools can be proper acquisition-free utilities. 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] unresolved site manager related issues
On 4/15/07, Martin Aspeli [EMAIL PROTECTED] wrote: Dieter Maurer wrote: Alec Mitchell wrote at 2007-4-12 06:59 -0700: ... ... deprecation of getToolByName ... which is that there's no practical reason other than aesthetics to deprecate getToolByName at this point. A very good point: let's deprecate deprecations done just for aethetical reasons :-) Aesthetics were not the original reason for moving down this route, so it's a little unfair to cast it in that light. The main drivers, as I recall, were to encourage API usage that would allow us to move tools out of content space eventually, and to make code depending on CMF tools more consistent with newer code which may depend on new utilities (at least in the Plone world, there is a general consensus that we'd rather not have any more content-space tools from now on). What is it about getToolByName that implies that tools are in content space? Consistency with newer code is an aesthetic concern as far as I understand it. Alec Alec ___ 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
[Zope-CMF] Re: [dev] unresolved site manager related issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Mitchell wrote: On 4/15/07, Martin Aspeli [EMAIL PROTECTED] wrote: Dieter Maurer wrote: Alec Mitchell wrote at 2007-4-12 06:59 -0700: ... ... deprecation of getToolByName ... which is that there's no practical reason other than aesthetics to deprecate getToolByName at this point. A very good point: let's deprecate deprecations done just for aethetical reasons :-) Aesthetics were not the original reason for moving down this route, so it's a little unfair to cast it in that light. The main drivers, as I recall, were to encourage API usage that would allow us to move tools out of content space eventually, and to make code depending on CMF tools more consistent with newer code which may depend on new utilities (at least in the Plone world, there is a general consensus that we'd rather not have any more content-space tools from now on). What is it about getToolByName that implies that tools are in content space? Consistency with newer code is an aesthetic concern as far as I understand it. Agreed. I'm fine with having 'getToolByName' issue a deprecation warning if the tool can't be found using the component registry, and therefore the API has to fall back to acquisition to *find* the tool. That is a different problem than *wrapping* the returned tool to give it place (for security, for forward compatibility, whatever): if the tool implements 'Acquisition.interfaces.IAcquirer', then it *needs* wrapping, whether that is done via 'getToolByName', 'five.lsm', or some other voodoo-yet-to-be-written. Failing to wrap objects that expect to be wrapped is a major party foul: in fact, I would class that a showstopper for any final release of CMF 2.1. Utilities that don't expect to be wrapped had better fall into one of the following categories: - They shouldn't be used by untrusted code at all (i.e,, all their methods are declared private). Such a utilitiy might be registered as a policy hook for some other framework: note that it would *not* be possibile to *configure* such a utility TTW using stock Zope2 ZMI patterns. - Or they have no expectation that Zope2 protects them (i.e., all their methods are public). Such utilities would either perform their own security checks, *using a passed in context object*, or would provide services which did not require any protection. - Or some mixture of the two. Any use of 'security.declareProtected' in the class of the tool mandates that the tool be given place for Zope2 security purposes, even if nothing else needs wrapping. Trying to come up with an elegant way to avoid the necessity of wrapping is silly at this point: it isn't even better to try to make Zope3-style wrapping (the ILocation stuff) equivalent, because we will have to support implementations which don't know or care about Zope3 indefinitely. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGIv4a+gerLs4ltQ4RAhXAAJ9HPCBZL+YKdjZR40/RTG9oUy+yEQCeM6+l f6il2a1cqNgkaGmtVJVptyY= =rgN1 -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
[Zope-CMF] Re: [dev] unresolved site manager related issues
Alec Mitchell wrote: On 4/15/07, Martin Aspeli [EMAIL PROTECTED] wrote: Dieter Maurer wrote: Alec Mitchell wrote at 2007-4-12 06:59 -0700: ... ... deprecation of getToolByName ... which is that there's no practical reason other than aesthetics to deprecate getToolByName at this point. A very good point: let's deprecate deprecations done just for aethetical reasons :-) Aesthetics were not the original reason for moving down this route, so it's a little unfair to cast it in that light. The main drivers, as I recall, were to encourage API usage that would allow us to move tools out of content space eventually, and to make code depending on CMF tools more consistent with newer code which may depend on new utilities (at least in the Plone world, there is a general consensus that we'd rather not have any more content-space tools from now on). What is it about getToolByName that implies that tools are in content space? Consistency with newer code is an aesthetic concern as far as I understand it. I suppose it depends on how you look at it. If we agree that the way to get tools out of content space is to make them utilities, and we want to be able to promise the normal semantics for global and local utilities. In that case, moving to getUtility as the API and interfaces as keys seems to be a long term goal. As for consistency, call it aesthetics, but I know it's becoming quite hard to explain to new developers that various things are semantically similar, but there is an old way that applies to cases X, Y and Z, and then a new way that applies to all other cases. Anyway, the point here is the consistency/flexibility/ease of migration in the future benefit vs. the cost of time/complexity and indeed whether it's possible to achieve all the benefits with the current tool implementations. This was all nice and pretty when no-one had thought that tools-as-utilities needed to be wrapped at all. If that'd been the case, we'd just be having a deprecation warning discussion. :) Martin ___ 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] unresolved site manager related issues
On 4/15/07, Tres Seaver [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Mitchell wrote: On 4/15/07, Martin Aspeli [EMAIL PROTECTED] wrote: Dieter Maurer wrote: Alec Mitchell wrote at 2007-4-12 06:59 -0700: ... ... deprecation of getToolByName ... which is that there's no practical reason other than aesthetics to deprecate getToolByName at this point. A very good point: let's deprecate deprecations done just for aethetical reasons :-) Aesthetics were not the original reason for moving down this route, so it's a little unfair to cast it in that light. The main drivers, as I recall, were to encourage API usage that would allow us to move tools out of content space eventually, and to make code depending on CMF tools more consistent with newer code which may depend on new utilities (at least in the Plone world, there is a general consensus that we'd rather not have any more content-space tools from now on). What is it about getToolByName that implies that tools are in content space? Consistency with newer code is an aesthetic concern as far as I understand it. Agreed. I'm fine with having 'getToolByName' issue a deprecation warning if the tool can't be found using the component registry, and therefore the API has to fall back to acquisition to *find* the tool. That is a different problem than *wrapping* the returned tool to give it place (for security, for forward compatibility, whatever): if the tool implements 'Acquisition.interfaces.IAcquirer', then it *needs* wrapping, whether that is done via 'getToolByName', 'five.lsm', or some other voodoo-yet-to-be-written. Failing to wrap objects that expect to be wrapped is a major party foul: in fact, I would class that a showstopper for any final release of CMF 2.1. Yes tools need to be wrapped, because to a great extent their purpose is to allow use of methods from untrusted (ui) code. I'm not sure this pattern really maps well on to the use of utilities in Zope 3, but it's hard to say since Zope 3 doesn't really seem to have the same concept of untrusted code. However, there's Utilities that don't expect to be wrapped had better fall into one of the following categories: - They shouldn't be used by untrusted code at all (i.e,, all their methods are declared private). Such a utilitiy might be registered as a policy hook for some other framework: note that it would *not* be possibile to *configure* such a utility TTW using stock Zope2 ZMI patterns. Is there currently a way to access a utility from untrusted code? Aside from CMF's new getToolByInterfaceName method (which is about wrapped tools not utilities), there isn't AFAIK. My impression is that untrusted code should generally be using methods from views (which could themselves delegate to utilities), not utilities or non-view adapters which are currently inaccessible and insufficiently protected for untrusted code. Currently, Five doesn't support security declarations on utilities or adapters at all (I mean global utilities in this case), and I think the reason is that utilities are generally accessible only from trusted code. I understand that this limitation makes it quite hard to make use of utilities in the way that tools have traditionally been used. To me that's just another reason to consider the introduction of this tool = utility equivalence to have been premature. It may turn out that we need to wrap utilities generally (including the global ones), but that's something that would need to happen at a different level than five.lsm. Many people have made use of global utilities in Zope 2 and not missed the acquisition wrapping. Local utilities shouldn't be any different. In the end, if we need wrappers on the local ones, then we should have wrappers on the global ones too, and we need a solution that capable of providing wrapping for both. - Or they have no expectation that Zope2 protects them (i.e., all their methods are public). Such utilities would either perform their own security checks, *using a passed in context object*, or would provide services which did not require any protection. - Or some mixture of the two. Any use of 'security.declareProtected' in the class of the tool mandates that the tool be given place for Zope2 security purposes, even if nothing else needs wrapping. Trying to come up with an elegant way to avoid the necessity of wrapping is silly at this point: it isn't even better to try to make Zope3-style wrapping (the ILocation stuff) equivalent, because we will have to support implementations which don't know or care about Zope3 indefinitely. For content objects this is probably of dubious utility, because, as you say, there will always be implementations around which don't understand or expect the Zope 3 patterns. Other components like views, adapters, and utilities (none of which generally provide ILocation) would only be accessed from non-legacy code so this
