[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 - CMFUid reindexes all fields unnecessarily, [Pending] http://www.zope.org/Collectors/CMF/469 - GenericSetup snapshot redirect does not work, [Pending] http://www.zope.org/Collectors/CMF/470 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
[Zope-CMF] CMF Tests: 8 OK, 1 Failed
Summary of messages to the cmf-tests list. Period Sun Feb 25 12:00:00 2007 UTC to Mon Feb 26 12:00:00 2007 UTC. There were 9 messages: 9 from CMF Unit Tests. Test failures - Subject: FAILED (failures=1) : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Sun Feb 25 21:51:37 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004184.html Tests passed OK --- Subject: OK : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Sun Feb 25 21:47:06 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004181.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Sun Feb 25 21:48:36 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004182.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Feb 25 21:50:06 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004183.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Feb 25 21:53:07 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004185.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Feb 25 21:54:37 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004186.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Feb 25 21:56:07 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004187.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Feb 25 21:57:37 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004188.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Sun Feb 25 21:59:07 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004189.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: Five's local sitemanager, CMF, etc
On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). - Rocky ___ 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: Five's local sitemanager, CMF, etc
Rocky wrote:
On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote:
yuppie wrote:
Maybe I'm missing something. But wasn't a major goal of
five.localsitemanager to return acquisition wrapped tools?
That was my understanding, too. I thought this would just mean
aq_base'ing the utility and aq-wrapping it back into the context (the
portal root). Without this, we start requiring users of the interface to
know when aq wrapping is needed and do it explicitly with __of__() which
I think we agreed was unacceptably detailed and ugly. :)
Alright, I've gone ahead and put code in place for this (albeit a bit
naively) with r72810. The next question is whether we should be doing
the same with adapters and subscribers as well (even though this
doesn't affect the whole tools-getting-acquired-properly issue).
I'm a bit uneasy about the implementation. With
Acquisition.ImplicitAcquisitionWrapper(base, parent) it seems you're
wrapping all utilities, even those that don't inherit from acquisition
and potentially don't want acquisition. Even worse, you give them an
*implicit* acquisition wrapper.
I think _wrap() should be changed to:
def _wrap(self, comp):
Return an aq wrapped component with the site as the parent.
if Acquisition.interfaces.IAcquirer.providedBy(comp)
parent = Acquisition.aq_parent(self)
if parent is None:
raise ValueError('Not enough context to acquire parent')
base = Acquisition.aq_base(comp)
comp = base.__of__(parent)
return comp
This way, only objects that inherit from one of the Acquisition base
classes will be wrapped at all.
--
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5
___
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: Five's local sitemanager, CMF, etc
Rocky wrote: On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). One more thing: This acquisition wrapping should clearly be marked (with comments) as something that's done to for BBB because some tools happen to want acquisition. I think in the future, it should be discouraged to expect acquisition in CMF tools. To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ 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] Five's local sitemanager, CMF, etc
Philipp von Weitershausen wrote: Rocky wrote: On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). One more thing: This acquisition wrapping should clearly be marked (with comments) as something that's done to for BBB because some tools happen to want acquisition. I think in the future, it should be discouraged to expect acquisition in CMF tools. To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. +1 - in fact, we already have Products.CMFCore.interfaces.ISiteRoot. I use it all the time. :) Martin -- View this message in context: http://www.nabble.com/Five%27s-local-sitemanager%2C-CMF%2C-etc-tf3219557.html#a9161398 Sent from the Zope - CMF list2 mailing list archive at Nabble.com. ___ 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: Five's local sitemanager, CMF, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Rocky wrote: On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). One more thing: This acquisition wrapping should clearly be marked (with comments) as something that's done to for BBB because some tools happen to want acquisition. I think in the future, it should be discouraged to expect acquisition in CMF tools. - -1. This is not *yet* BBB, until we require a version of Zope which no longer uses acquisition for anything crucial. Premature deprecation is crying wolf, IMNSHO. To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. They darn well better be able to get a wrapped context (which means that the event *must* have a wrapped attribute) or they will be less than useless. 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 iD8DBQFF4zvU+gerLs4ltQ4RAtZ0AJ9kK/GThZW9eTI1CXuFWHVnQRVDyQCfaTl+ OAZgpfhWGQmWU2rxT5l9pKg= =pW21 -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: Five's local sitemanager, CMF, etc
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Rocky wrote: On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). One more thing: This acquisition wrapping should clearly be marked (with comments) as something that's done to for BBB because some tools happen to want acquisition. I think in the future, it should be discouraged to expect acquisition in CMF tools. - -1. This is not *yet* BBB, until we require a version of Zope which no longer uses acquisition for anything crucial. Premature deprecation is crying wolf, IMNSHO. I nowhere said anything about deprecation. All meant was to discourage relying on acquisition when developing new tools. I think that deserves a comment (I suggested nothing more). No deprecation warning or anything necessary;. To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. They darn well better be able to get a wrapped context (which means that the event *must* have a wrapped attribute) or they will be less than useless. That's something else. Adapters and subscription adapters will get whatever they are looked up with. If that's wrapped, fine. E.g. if you do IWhatever(obj) and you got obj thru acquisition, then the IWhatever adapter will see obj with all its acquisition glory. But The adapter objects themselves shouldn't be wrapped. It would break, say, views which happen to be adapters. Note that subscription adapters != subscribers. Subscribers don't return objects upon lookup, they're just executed. Subscription adapters are more like adapters. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ 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: Five's local sitemanager, CMF, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Rocky wrote: On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). One more thing: This acquisition wrapping should clearly be marked (with comments) as something that's done to for BBB because some tools happen to want acquisition. I think in the future, it should be discouraged to expect acquisition in CMF tools. - -1. This is not *yet* BBB, until we require a version of Zope which no longer uses acquisition for anything crucial. Premature deprecation is crying wolf, IMNSHO. I nowhere said anything about deprecation. All meant was to discourage relying on acquisition when developing new tools. I think that deserves a comment (I suggested nothing more). No deprecation warning or anything necessary;. OK. I do think we need to have some resistance to the Zope2 is evil, Zope3 is wonderful fundamentalism which sometimes shows up around here. Frankly, Zope3 *is* a cool library, but it does not address a number of the scenarios Zope2 does, and maybe never will. To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. They darn well better be able to get a wrapped context (which means that the event *must* have a wrapped attribute) or they will be less than useless. That's something else. Adapters and subscription adapters will get whatever they are looked up with. If that's wrapped, fine. E.g. if you do IWhatever(obj) and you got obj thru acquisition, then the IWhatever adapter will see obj with all its acquisition glory. But The adapter objects themselves shouldn't be wrapped. It would break, say, views which happen to be adapters. I'll note that five views are already required to be acquisition wrapped if they use any objects protected by Zope2 security machinery. Note that subscription adapters != subscribers. Subscribers don't return objects upon lookup, they're just executed. Subscription adapters are more like adapters. I don't know of such a distinction. Please explain how one registers a subscription adapter. 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 iD8DBQFF42Ot+gerLs4ltQ4RAqPLAJ9vnHfe6tO7paPMhs8bPnmYxx4SqQCfciUd IUgd7g+CHTxhNXufTCbKKqk= =+R0J -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: Five's local sitemanager, CMF, etc
On 26 Feb 2007, at 23:48 , Tres Seaver wrote: I nowhere said anything about deprecation. All meant was to discourage relying on acquisition when developing new tools. I think that deserves a comment (I suggested nothing more). No deprecation warning or anything necessary;. OK. I do think we need to have some resistance to the Zope2 is evil, Zope3 is wonderful fundamentalism which sometimes shows up around here. Frankly, Zope3 *is* a cool library, but it does not address a number of the scenarios Zope2 does, and maybe never will. Yes. Zope 3 is can be seen as a set of libraries -- and a number of approaches. As far as acquisition (the concept) is concerned, I think the common perception is that Acquisition (the Zope 2 package) introduces pains, magic and unpredictability, whereas the way acquisition is implemented in Zope 3 (discrete places called sites from which you can acquire things after registering things explicitly) is a cleaner and more predictable concept. I see this whole effort (making CMF tools available as utilities, etc.) a way to move from Acquisition (the Zope 2 package) to a better form of acquisition (using the Zope 3 Component Architecture). Such a process needs to be accompanied by clear statements what's encouraged and what's discouraged. That doesn't mean that the old way is evil, but we can certainly give a clear recommandation as to what's better (not necessarily wonderful but better). To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. They darn well better be able to get a wrapped context (which means that the event *must* have a wrapped attribute) or they will be less than useless. That's something else. Adapters and subscription adapters will get whatever they are looked up with. If that's wrapped, fine. E.g. if you do IWhatever(obj) and you got obj thru acquisition, then the IWhatever adapter will see obj with all its acquisition glory. But The adapter objects themselves shouldn't be wrapped. It would break, say, views which happen to be adapters. I'll note that five views are already required to be acquisition wrapped if they use any objects protected by Zope2 security machinery. Yes, but their wrapping is a detail of the traversal and security machinery. Hence it happens during traversal, not during component lookup. Note that subscription adapters != subscribers. Subscribers don't return objects upon lookup, they're just executed. Subscription adapters are more like adapters. I don't know of such a distinction. Please explain how one registers a subscription adapter. registry.registerSubscriptionAdapter() More on subscribers vs. subscription adapters: * Subscribers are the event subscribers we know: simple callables. They don't return anything (well, they return None :)), hence there's nothing to wrap or anything. * Subscription adapters are like regular adapters (and they are implemented exactly like a regular adapter). The difference is in the lookup. Instead of getting exactly 0 or 1 adapter in the adaption, you get n adapters (where n=0,1,2,3...) with subscription adapters. Basically, instead of finding the most specific adapter, subscription adapters will return *all* applicable adapters. So their lookup is a bit like the one of subscribers, hence the name. ___ 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
