[Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
Martin Aspeli wrote: We believe that these recent changes have introduced implicit magic into a standard Zope3 api to fit Zope2 acquisition. There should be an explicit separate api if we want acquisition wrapped context-aware utilities. As an example of a symptom caused by the implicit implementation, KSS (which was developed as a pure zope 3 component) breaks when used with Plone, even though it is a perfectly valid z3 component. Once we return to using getToolByName for tool lookup, the KSS/Plone3 issue disappears, because the magic wrapping of things stops. This KSS/Plone3 issue arises because the five.lsm acquisition breaks down when you add in non five.lsm component registries. If you need Zope2 acquisition, you should use an accessor api to get things wrapped. In addition, getToolByName is the most fundamental and widely used api in all of CMF, and we're going to be issuing hundreds of deprecating warnings for every single cmf application extant. As a solution, we propose * The five.localsitemanager code should *NOT* be dealing with acquisition, it should be restricted to setting up a bases chain for persistent components that does parent lookup. * getToolByName deprecation should be reverted. Its internal mechanisms should be kept the same as in the current CMF 2.1 release, using getUtility, *AND* it should be the one doing acquisition wrapping. So instead of doing implicit magic in the getUtility call stack, let's be explicit, while still allowing the flexibility that registered components provide. Which in turn results in an untouched zope3 getUtility execution path for looking up utilities. getToolByName should return acquisition wrapped utilities via name mapping, and become un-deprecated. Context for wrapping would be the context passed as an argument to getToolByName, as it always has been. It would issue deprecation warnings when it has to lookup a tool via aq_get instead of getUtility. The mechanism for registering tool names would raise an error when anyone tries to register a component which does not support Acquisition. The getToolByInterfaceName method would no longer be necessary as getToolByName can be called from restricted code. However if needed it could remain and use the result of getSite() as the context for wrapping the tool resulting from the utility lookup. +1 The one thing I don't see here explicitly is the forward migration path. Make tools not depend on acquisition and you get can start looking them up using getUtility. This will take time, so I'd be ok if for now we can't use getUtility right away (unless you're willing to do manual __of__ing) I think it would be worthwhile to work towards a future where we have no tools or other programmer-support-mechanisms in content space. At least new stuff can be Zope 3-style already. I suspect that all context-less tools today could be rewritten to be regular global utilities, Absolutely. and all persitence-needing tools could be changed to be standard local utilities that if needed did getUtility(ISiteRoot) to get hold of the site root and acquire things from there (except, how does the site root then get an acquisition context? Maybe it doesn't need to?). Well, ideally we'll be able to model containment relationships using __parent__ in Zope 2 as well... However, if we still promote and use getToolByName() then people will not start using getUtility() and importing interfaces and we will find it more difficult to deprecate (eventually) and then move to a world where we can have real utilities (where possible/sensible). I can say from personal experience that deprecating less in more time is easier on the people and on yourself :). Going back to square one, the reason why we (and I'm very guilty in this) pushed for something at the framework level (spawning five.lsm) was that originally we ended up with calling code needing to do: >>> from Products.CMFCore.interfaces import IWorkflowTool >>> from zope.component import getUtility >>> wftool = getUtility(IWorkflowTool).__of__(context) Such explicit wrapping is black magic voodoo to most people and would probably lead to lots of hard-to-debug errors. (Welcome to Acquisition!) Requiring people to know *when* to wrap and when it's not necessary is tantamount to requiring them to know the implementation details of each tool. getToolByName sounds like a sensible abstraction, don't you think? We don't mean to belittle the hard work that anyone has put into this so far, and we hope this is received in the spirit that it is intended. We are willing to implement this if we can reach some consensus that this is the right thing to do. This is the part of the email I like the most :) It's a bit scary to have to revert the hundreds of changes that have been made to the Plone 3.0 codebase and probably hundreds more to the CMF codebase to move to getUtility, th
[Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
Kapil Thangavelu wrote: A few of us (Alec Mitchell, Godefroid Chapelle, Balazs Ree, Rocky Burt, Daniel Nouri, Rob Miller, Vincenzo Di Somma, and myself) have been discussing this in depth at the Sorrento Sprint. We've reached consensus on how we hope to resolve the issues arising from the recent introduction of five.localsitemanager and the deprecation of getToolByName. We believe that these recent changes have introduced implicit magic into a standard Zope3 api to fit Zope2 acquisition. There should be an explicit separate api if we want acquisition wrapped context-aware utilities. As an example of a symptom caused by the implicit implementation, KSS (which was developed as a pure zope 3 component) breaks when used with Plone, even though it is a perfectly valid z3 component. Once we return to using getToolByName for tool lookup, the KSS/Plone3 issue disappears, because the magic wrapping of things stops. This KSS/Plone3 issue arises because the five.lsm acquisition breaks down when you add in non five.lsm component registries. If you need Zope2 acquisition, you should use an accessor api to get things wrapped. In addition, getToolByName is the most fundamental and widely used api in all of CMF, and we're going to be issuing hundreds of deprecating warnings for every single cmf application extant. As a solution, we propose * The five.localsitemanager code should *NOT* be dealing with acquisition, it should be restricted to setting up a bases chain for persistent components that does parent lookup. * getToolByName deprecation should be reverted. Its internal mechanisms should be kept the same as in the current CMF 2.1 release, using getUtility, *AND* it should be the one doing acquisition wrapping. So instead of doing implicit magic in the getUtility call stack, let's be explicit, while still allowing the flexibility that registered components provide. Which in turn results in an untouched zope3 getUtility execution path for looking up utilities. getToolByName should return acquisition wrapped utilities via name mapping, and become un-deprecated. Context for wrapping would be the context passed as an argument to getToolByName, as it always has been. It would issue deprecation warnings when it has to lookup a tool via aq_get instead of getUtility. The mechanism for registering tool names would raise an error when anyone tries to register a component which does not support Acquisition. The getToolByInterfaceName method would no longer be necessary as getToolByName can be called from restricted code. However if needed it could remain and use the result of getSite() as the context for wrapping the tool resulting from the utility lookup. These are good arguments, I think. I'm not sure anyone quite could've predicted the trouble we had with five.lsm (is it even needed anymore if all of this is acted upon?), so it's good to get some fresh thinking on this. The one thing I don't see here explicitly is the forward migration path. I think it would be worthwhile to work towards a future where we have no tools or other programmer-support-mechanisms in content space. I suspect that all context-less tools today could be rewritten to be regular global utilities, and all persitence-needing tools could be changed to be standard local utilities that if needed did getUtility(ISiteRoot) to get hold of the site root and acquire things from there (except, how does the site root then get an acquisition context? Maybe it doesn't need to?). However, if we still promote and use getToolByName() then people will not start using getUtility() and importing interfaces and we will find it more difficult to deprecate (eventually) and then move to a world where we can have real utilities (where possible/sensible). Going back to square one, the reason why we (and I'm very guilty in this) pushed for something at the framework level (spawning five.lsm) was that originally we ended up with calling code needing to do: >>> from Products.CMFCore.interfaces import IWorkflowTool >>> from zope.component import getUtility >>> wftool = getUtility(IWorkflowTool).__of__(context) Such explicit wrapping is black magic voodoo to most people and would probably lead to lots of hard-to-debug errors. Requiring people to know *when* to wrap and when it's not necessary is tantamount to requiring them to know the implementation details of each tool. I would agree, though, that it's not worth "breaking" the way local component registries work in Zope 3 by imposing arbitrary acquisition on them if that is indeed what we're doing. I don't think it was anyone's intention to do so, and the five.lsm implementation was never 100% finished was it? One thing I'd like to ask, is that someone asks Philipp (I've CC'd him, since I know he's not reading lists in detail right now) for comment, since he as usual had various useful insights into the origina
[Zope-CMF] getToolByName depreciation, getUtility, and five.lsm
A few of us (Alec Mitchell, Godefroid Chapelle, Balazs Ree, Rocky Burt, Daniel Nouri, Rob Miller, Vincenzo Di Somma, and myself) have been discussing this in depth at the Sorrento Sprint. We've reached consensus on how we hope to resolve the issues arising from the recent introduction of five.localsitemanager and the deprecation of getToolByName. We believe that these recent changes have introduced implicit magic into a standard Zope3 api to fit Zope2 acquisition. There should be an explicit separate api if we want acquisition wrapped context-aware utilities. As an example of a symptom caused by the implicit implementation, KSS (which was developed as a pure zope 3 component) breaks when used with Plone, even though it is a perfectly valid z3 component. Once we return to using getToolByName for tool lookup, the KSS/Plone3 issue disappears, because the magic wrapping of things stops. This KSS/Plone3 issue arises because the five.lsm acquisition breaks down when you add in non five.lsm component registries. If you need Zope2 acquisition, you should use an accessor api to get things wrapped. In addition, getToolByName is the most fundamental and widely used api in all of CMF, and we're going to be issuing hundreds of deprecating warnings for every single cmf application extant. As a solution, we propose * The five.localsitemanager code should *NOT* be dealing with acquisition, it should be restricted to setting up a bases chain for persistent components that does parent lookup. * getToolByName deprecation should be reverted. Its internal mechanisms should be kept the same as in the current CMF 2.1 release, using getUtility, *AND* it should be the one doing acquisition wrapping. So instead of doing implicit magic in the getUtility call stack, let's be explicit, while still allowing the flexibility that registered components provide. Which in turn results in an untouched zope3 getUtility execution path for looking up utilities. getToolByName should return acquisition wrapped utilities via name mapping, and become un-deprecated. Context for wrapping would be the context passed as an argument to getToolByName, as it always has been. It would issue deprecation warnings when it has to lookup a tool via aq_get instead of getUtility. The mechanism for registering tool names would raise an error when anyone tries to register a component which does not support Acquisition. The getToolByInterfaceName method would no longer be necessary as getToolByName can be called from restricted code. However if needed it could remain and use the result of getSite() as the context for wrapping the tool resulting from the utility lookup. We don't mean to belittle the hard work that anyone has put into this so far, and we hope this is received in the spirit that it is intended. We are willing to implement this if we can reach some consensus that this is the right thing to do. -kapil ___ 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] getToolByName depreciation, getUtility, and five.lsm
A few of us (Alec Mitchell, Godefroid Chapelle, Balazs Ree, Rocky Burt, Daniel Nouri, Rob Miller, Vincenzo Di Somma, and myself) have been discussing this in depth at the Sorrento Sprint. We've reached consensus on how we hope to resolve the issues arising from the recent introduction of five.localsitemanager and the deprecation of getToolByName. We believe that these recent changes have introduced implicit magic into a standard Zope3 api to fit Zope2 acquisition. There should be an explicit separate api if we want acquisition wrapped context-aware utilities. As an example of a symptom caused by the implicit implementation, KSS (which was developed as a pure zope 3 component) breaks when used with Plone, even though it is a perfectly valid z3 component. Once we return to using getToolByName for tool lookup, the KSS/Plone3 issue disappears, because the magic wrapping of things stops. This KSS/Plone3 issue arises because the five.lsm acquisition breaks down when you add in non five.lsm component registries. If you need Zope2 acquisition, you should use an accessor api to get things wrapped. In addition, getToolByName is the most fundamental and widely used api in all of CMF, and we're going to be issuing hundreds of deprecating warnings for every single cmf application extant. As a solution, we propose * The five.localsitemanager code should *NOT* be dealing with acquisition, it should be restricted to setting up a bases chain for persistent components that does parent lookup. * getToolByName deprecation should be reverted. Its internal mechanisms should be kept the same as in the current CMF 2.1 release, using getUtility, *AND* it should be the one doing acquisition wrapping. So instead of doing implicit magic in the getUtility call stack, let's be explicit, while still allowing the flexibility that registered components provide. Which in turn results in an untouched zope3 getUtility execution path for looking up utilities. getToolByName should return acquisition wrapped utilities via name mapping, and become un-deprecated. Context for wrapping would be the context passed as an argument to getToolByName, as it always has been. It would issue deprecation warnings when it has to lookup a tool via aq_get instead of getUtility. The mechanism for registering tool names would raise an error when anyone tries to register a component which does not support Acquisition. The getToolByInterfaceName method would no longer be necessary as getToolByName can be called from restricted code. However if needed it could remain and use the result of getSite() as the context for wrapping the tool resulting from the utility lookup. We don't mean to belittle the hard work that anyone has put into this so far, and we hope this is received in the spirit that it is intended. We are willing to implement this if we can reach some consensus that this is the right thing to do. -kapil ___ 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] CMF Tests: 9 Failed, 2 Unknown
Much fun to be had with daylight-saving, eh? FWIW, I have double-checked the system time, timezone, and locale settings on the machine running the nightlies, and everything appears to be sane. I see the same failure on my Mac, so /me shrugs... Stefan On 28. Mär 2007, at 14:00, CMF Tests Summarizer wrote: Summary of messages to the cmf-tests list. Period Tue Mar 27 12:00:00 2007 UTC to Wed Mar 28 12:00:00 2007 UTC. There were 11 messages: 11 from CMF Unit Tests. Test failures - Subject: FAILED (failures=1) : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:23:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004465.html Subject: FAILED (failures=1) : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:25:08 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004466.html Subject: FAILED (failures=1) : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:26:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004467.html Subject: FAILED (failures=1) : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:28:08 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004468.html Subject: FAILED (failures=1) : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:29:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004469.html Subject: FAILED (failures=1) : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:31:09 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004470.html Subject: FAILED (failures=1) : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:32:39 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004471.html Subject: FAILED (failures=1) : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:34:09 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004472.html Subject: FAILED (failures=1) : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:37:09 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004474.html Unknown --- Subject: UNKNOWN : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:35:39 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004473.html Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:38:42 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004475.html ___ 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 -- It doesn't necessarily do it in chronological order, though. --Douglas Adams ___ 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: Derived Content Types & WebDAV
Am 28.03.2007 um 18:45 schrieb Tres Seaver: I would be quite surprised if these methods had much to do with WebDAV editing. Instead, I would look for "PROPPATCH" (and how it is implemented). The methods Charlie lays out are used to "crack" metadata from the body of a content object (Document, NewsItem, Event) during a PUT. PROPPATCH would indeed be the way to modify the values without re-uploading the body. I'm a bit confused! (Not for the first time!) The changes I've implemented are working for us: we're editing documents in the WebDAV file system using text/HTML editors. As it's not just the meta-data that may be changed I assume that we have to upload everything on saving. I am however, worried about the fact about possible encoding issues similar to what happens if you edit attributes such as description in the ZMI rather than in the CMF and use non-ascii get problems is this likely to happen here as well? 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
[Zope-CMF] Re: Derived Content Types & WebDAV
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: > Charlie Clark wrote at 2007-3-27 13:28 +0200: >> having made my own content type which is derived from Document with >> three additional attributes, I've moved onto the exciting world of >> editing content via webDAV. It seems some methods have to be extended/ >> overwritten for this to work so I have added customised versions of >> the following >> getMetadataHeaders() # Document.py >> setMetadata() # Document.py >> getMetadataHeaders() # DublinCore.py >> _editMetaData() # DublinCore.py >> >> Is this a correct assumption? > > I would be quite surprised if these methods had much to do > with WebDAV editing. Instead, I would look for "PROPPATCH" > (and how it is implemented). The methods Charlie lays out are used to "crack" metadata from the body of a content object (Document, NewsItem, Event) during a PUT. PROPPATCH would indeed be the way to modify the values without re-uploading the body. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCpuq+gerLs4ltQ4RAlHsAJ9Dy6nqW6UhZybFinGD4Gnr4/ix2ACeL1vw jD0Fx/MS1+1uXOjIsHhgHO8= =AXLZ -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: GenericSetup Toolset problem
Yup, that's all done too. I just realized I hadn't put in the entry in "import_steps.xml", but now that that's done, doesn't seem to help either. I think I ran into this before and just recreated the whole site ... But now I'd much rather not have to do that ... And in the long run, I have to find a way to add new components without recreating the whole thing! So: - Import/export is done - adapter is done - toolset.xml is done - import_steps.xml is done I guess maybe I'll have to go in through zopectl debug or something like that, see what's going on ... J.F. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Raphael Ritz Sent: March 28, 2007 03:55 To: [EMAIL PROTECTED] Subject: [Zope-CMF] Re: GenericSetup Toolset problem Doyon, Jean-Francois schrieb: > Hello, > > I've added a tool to my code base, and registered it in toolset.xml, > gave it import/export logic, etc ... > Did you also register the adapter for the tool to the setup environment? I have something like that in CMFBib's exportimport: http://namespaces.zope.org/zope"; xmlns:five="http://namespaces.zope.org/five"; i18n_domain="cmf" > where in exportimport/bibliographytool I declare: class BibliographyToolXMLAdapter(XMLAdapterBase, ObjectManagerHelpers, PropertyManagerHelpers): """XML im- and exporter for the BibliographyTool. """ adapts(IBibliographyTool, ISetupEnviron) See https://svn.plone.org/svn/collective/CMFBibliographyAT/trunk for the full example. Raphael ___ 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 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] CMF Tests: 9 Failed, 2 Unknown
Summary of messages to the cmf-tests list. Period Tue Mar 27 12:00:00 2007 UTC to Wed Mar 28 12:00:00 2007 UTC. There were 11 messages: 11 from CMF Unit Tests. Test failures - Subject: FAILED (failures=1) : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:23:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004465.html Subject: FAILED (failures=1) : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:25:08 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004466.html Subject: FAILED (failures=1) : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:26:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004467.html Subject: FAILED (failures=1) : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:28:08 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004468.html Subject: FAILED (failures=1) : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:29:38 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004469.html Subject: FAILED (failures=1) : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:31:09 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004470.html Subject: FAILED (failures=1) : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:32:39 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004471.html Subject: FAILED (failures=1) : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:34:09 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004472.html Subject: FAILED (failures=1) : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:37:09 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004474.html Unknown --- Subject: UNKNOWN : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:35:39 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004473.html Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Tue Mar 27 21:38:42 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-March/004475.html ___ 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: Delete trouble
Philipp von Weitershausen wrote:
Martin Aspeli wrote:
Traceback (innermost last):
Module ZPublisher.Publish, line 119, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 42, in call_object
Module OFS.ObjectManager, line 524, in manage_delObjects
Module OFS.ObjectManager, line 379, in _delObject
Module zope.event, line 23, in notify
Module zope.component.event, line 26, in dispatch
Module zope.component._api, line 130, in subscribers
Module zope.component.registry, line 290, in subscribers
Module zope.interface.adapter, line 535, in subscribers
Module zope.component.event, line 33, in objectEventNotify
Module zope.component._api, line 130, in subscribers
Module zope.component.registry, line 290, in subscribers
Module zope.interface.adapter, line 535, in subscribers
Module OFS.subscribers, line 108, in dispatchObjectWillBeMovedEvent
Module zope.app.container.contained, line 182, in
dispatchToSublocations
Module zope.component._api, line 130, in subscribers
Module zope.component.registry, line 290, in subscribers
Module zope.interface.adapter, line 535, in subscribers
Module OFS.subscribers, line 108, in dispatchObjectWillBeMovedEvent
Module zope.app.container.contained, line 182, in
dispatchToSublocations
Module zope.component._api, line 130, in subscribers
Module zope.component.registry, line 290, in subscribers
Module zope.interface.adapter, line 535, in subscribers
Module Products.CMFCore.CMFCatalogAware, line 285, in
dispatchToOpaqueItems
Module zope.component._api, line 130, in subscribers
Module zope.component.registry, line 290, in subscribers
Module zope.interface.adapter, line 535, in subscribers
Module Products.CMFCore.CMFCatalogAware, line 306, in
handleOpaqueItemEvent
Module Products.CMFUid.UniqueIdAnnotationTool, line 87, in
manage_beforeDelete
Module zope.component._api, line 207, in getUtility
ComponentLookupError: (Products.CMFUid.interfaces.IUniqueIdAnnotationManagement>, '')
The UniqueIDAnnotationTool should probably do a *query*Utility (which
will return None in case the utility can't be found) and simply not do
anything in such a case. The canonical way of expressing such fail-safe
routines is therefore:
component = query{Utility|Adapter|MultiAdapter}(...)
if component is not None:
...
I think I have a patch that will sort this out. The issue is that the
UID annotations define a manage_beforeDelete method that is called via
subscribers to the IOpaqueItemEvents interface, but, being "old zope",
doesn't know whether it is being deleted or moved and does some lookups
that are unnecessary when deleted.
Changing this so there is an event subscriber for UIDs that does not use
manage_beforeDelete will sort the problem, as nothing will be done when
the item is deleted.
I don't know whether there is a wider issue around BBB and the order
that events are fired though (manage_beforeDelete looks to have had a
'children first' approach, whereas it looks as if dispatchToSublocations
has a 'children last' approach)
Miles
___
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] 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 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 - "Proxy Roles not Working/Applied to Worflow Transition Scripts", [Pending] http://www.zope.org/Collectors/CMF/449 - "safe_html filters some tags which should probably not be filtered", [Pending] http://www.zope.org/Collectors/CMF/452 - "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 - "manage_doCustomize() : minor additions", [Pending] http://www.zope.org/Collectors/CMF/382 - "CMF needs View-based TypeInformation", [Pending] http://www.zope.org/Collectors/CMF/437 - "Marker attributes should be deprecated", [Pending] http://www.zope.org/Collectors/CMF/440 - "New getNextEvent Method", [Pending] http://www.zope.org/Collectors/CMF/462 ___ 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
