[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 jens - CachingPolicyManager: Support OFS.Cache.CacheManager, [Accepted] http://www.zope.org/Collectors/CMF/408 mhammond - Windows DevelopmentMode penalty in CMFCore.DirectoryView, [Accepted] http://www.zope.org/Collectors/CMF/366 Pending / Deferred Issues - Wrong cache association for FSObject, [Pending] http://www.zope.org/Collectors/CMF/255 - CMFSetup: Windows exports contain CR/LF, LF and even CR newlines, [Pending] http://www.zope.org/Collectors/CMF/266 - 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 - CMFSetup: Workflow Tool export fails with workflows which have scripts, [Pending] http://www.zope.org/Collectors/CMF/373 - CMFCore.Skinnable.SkinnableObjectManager can merge skin data, [Pending] http://www.zope.org/Collectors/CMF/375 - Proxy Roles does't work for a Script using portal_catalog.searchResults, [Pending] http://www.zope.org/Collectors/CMF/380 - workflow notify success should be after reindex, [Pending] http://www.zope.org/Collectors/CMF/389 - 'except ...: pass' in CMFCore/TypesTool.py:_queryFactoryMethod() nullifies VerboseSecurity, [Pending] http://www.zope.org/Collectors/CMF/410 - Logging broken, [Pending] http://www.zope.org/Collectors/CMF/439 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 - path criteria on Topic should honor VHM, [Pending] http://www.zope.org/Collectors/CMF/111 - Document.py: universal newlines, [Pending] http://www.zope.org/Collectors/CMF/174 - Add condition for transition's action like other action, [Pending] http://www.zope.org/Collectors/CMF/207 - Major action enhancement, [Pending] http://www.zope.org/Collectors/CMF/232 - 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 ___ 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] Products-less python package support for CMF 1.6
Hi all,
I currently have a product by the name of pythonproducts
(http://codespeak.net/svn/z3/pythonproducts/) that does its best to
patch Zope/Five and CMF so that regular python packages can be treated
as first-class Zope 2 products. The underlying problem being that
certain portions of Zope/CMF code assumes all assumes products found in
the control panel live at the toplevel package 'Products' when this
should not be necessity. A practical example of what this means is that
today usually when you need to import things you do from
Products.product1 import foo but since products can be regular packages
with the fixes, you can now do from product1 import foo as long as
your product is on PYTHONPATH (often this is $INSTANCE_HOME/lib/python).
As of Five 1.4, the Five specific functionality has been merged into
Five itself. As of Zope 2.10, the Zope specific functionality has been
merged into Zope itself. So all that remains now is CMF. The biggest
problem with CMF was CMFCore.TypesTool.listDefaultTypeInformation. As I
know this is no longer used in CMF2 this *should* mean CMF2 is safe
(although I'd have to do further tests to confirm this).
What I would like to do is get CMF1.6's listDefaultTypeInformation fixed
so that people stuck on CMF1.6 can reap all of these benefits without
having to include pythonproducts. One large beneficiary of this work
will be the Zope2.10 based Plone 2.5 combination which will be able to
do all of this without the need for pythonrproducts *if* CMF1.6 is
fixed.
Anyhow, I've included a patch that demonstrates what would need to be
done including some extra test logic that fails before my changes and of
course passes afterwards.
What do you all think? Something we can include in time for CMF1.6.1
beta2 ?
Regards,
Rocky
--
Rocky Burt
ServerZen Software -- http://www.serverzen.com
News About The Server (blog) -- http://www.serverzen.net
Index: CHANGES.txt
===
--- CHANGES.txt (revision 68481)
+++ CHANGES.txt (working copy)
@@ -1,3 +1,12 @@
+CMF 1.6.1-beta2 (unreleased)
+
+ Others
+
+- TypesTool is now capable of understanding types that don't
+ necessarily live in product pkgs beneath the toplevel Products/*
+ package. This makes productsless packages work with CMF.
+
+
CMF 1.6.1-beta (2006/06/03)
Bug Fixes
Index: CMFCore/TypesTool.py
===
--- CMFCore/TypesTool.py (revision 68481)
+++ CMFCore/TypesTool.py (working copy)
@@ -16,6 +16,7 @@
from sys import exc_info
+import types
from warnings import warn
from AccessControl import ClassSecurityInfo
@@ -55,7 +56,6 @@
_marker = [] # Create a new marker.
-
class TypeInformation(SimpleItemWithProperties, ActionProviderBase):
Base class for information about a content type.
@@ -693,6 +693,40 @@
if mt['name'] in allowedTypes ]
return tuple(all) + tuple(others)
+def _product_packages(self):
+Returns all product packages including the regularly defined
+zope2 packages and those without the Products namespace package.
+
+
+old_product_packages = {}
+for x in dir(Products):
+m = getattr(Products, x)
+if isinstance(m, types.ModuleType):
+old_product_packages[x] = m
+
+packages = {}
+app = self
+while hasattr(app, 'aq_parent'):
+app = app.aq_parent
+products = app.Control_Panel.Products
+
+for product_id in products.objectIds():
+product = products[product_id]
+if hasattr(product, 'package_name'):
+pos = product.package_name.rfind('.')
+if pos -1:
+packages[product_id] = __import__(product.package_name,
+ globals(), {},
+ product.package_name[pos+1:])
+else:
+packages[product_id] = __import__(product.package_name)
+elif old_product_packages.has_key(product_id):
+packages[product_id] = old_product_packages[product_id]
+
+return packages
+
+
+
#
# other methods
#
@@ -702,13 +736,14 @@
# of all products and factory dispatchers within products.
res = []
products = self.aq_acquire('_getProducts')()
+product_pkgs = self._product_packages()
for product in products.objectValues():
product_id = product.getId()
if hasattr(aq_base(product), 'factory_type_information'):
ftis = product.factory_type_information
else:
-package = getattr(Products, product_id, None)
+package = product_pkgs.get(product_id, None)
dispatcher = getattr(package,
[Zope-CMF] Re: Products-less python package support for CMF 1.6
Hi Rocky! Rocky Burt wrote: As of Five 1.4, the Five specific functionality has been merged into Five itself. As of Zope 2.10, the Zope specific functionality has been merged into Zope itself. So all that remains now is CMF. The biggest problem with CMF was CMFCore.TypesTool.listDefaultTypeInformation. As I know this is no longer used in CMF2 this *should* mean CMF2 is safe (although I'd have to do further tests to confirm this). AFAIK registerDirectory and registerProfile work only inside of Products. I'm currently working on a fix for registerProfile. What I would like to do is get CMF1.6's listDefaultTypeInformation fixed so that people stuck on CMF1.6 can reap all of these benefits without having to include pythonproducts. One large beneficiary of this work will be the Zope2.10 based Plone 2.5 combination which will be able to do all of this without the need for pythonrproducts *if* CMF1.6 is fixed. Anyhow, I've included a patch that demonstrates what would need to be done including some extra test logic that fails before my changes and of course passes afterwards. What do you all think? Something we can include in time for CMF1.6.1 beta2 ? I don't care much about CMF 1.6, but I wonder in which case your patch is useful. Are you suggesting that people write cutting-edge Products-less python packages and add deprecated fti data in those packages to make it available through the deprecated listDefaultTypeInformation method? Cheers, Yuppie ___ 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: Products-less python package support for CMF 1.6
Hi Rocky! Rocky Burt wrote: On Sun, 2006-04-06 at 18:12 +0200, yuppie wrote: Rocky Burt wrote: What do you all think? Something we can include in time for CMF1.6.1 beta2 ? I don't care much about CMF 1.6, but I wonder in which case your patch is useful. Are you suggesting that people write cutting-edge Products-less python packages and add deprecated fti data in those packages to make it available through the deprecated listDefaultTypeInformation method? All of this work I'm doing is geared towards having Zope 2 developers write code that is less Zope 2 specific and more python specific. Nothing about bleeding edge, etc. In the Zope 2 world I consider that bleeding edge. And there is going to be large community of third-party app developers writing products against the not-yet-released Plone 2.5. But my feeling was that Plone wsan't the only product based on CMF1.6 ... if it were then I could provide a monkey right in plone but this is the absolute wrong approach imho. I hope neither Plone 2.5 nor CPS 3.4 require oldstyle fti data. CMF 1.6 doesn't. Shipping Products-less python packages without profile based fti data sounds strange to me. And if the reason is that registering profiles doesn't work that should be fixed instead of falling back to oldstyle fti data. Ultimately Plone needs to get to CMF2 and that will happen with Plone 3.0, but there were simply too many changes in CMF to allow Plone to do that within the 2.5 timeframe. Anyhow, I'm trying to make compromises to keep as many people happy as possible. Originally I wanted to add this to CMF 1.5.x as well :) I'll shut up now. I don't use CMF 1.6 and I don't think your code will break CMF 1.6. Cheers, Yuppie ___ 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: Products-less python package support for CMF 1.6
yuppie wrote: Hi Rocky! Rocky Burt wrote: On Sun, 2006-04-06 at 18:12 +0200, yuppie wrote: Rocky Burt wrote: What do you all think? Something we can include in time for CMF1.6.1 beta2 ? I don't care much about CMF 1.6, but I wonder in which case your patch is useful. Are you suggesting that people write cutting-edge Products-less python packages and add deprecated fti data in those packages to make it available through the deprecated listDefaultTypeInformation method? All of this work I'm doing is geared towards having Zope 2 developers write code that is less Zope 2 specific and more python specific. Nothing about bleeding edge, etc. In the Zope 2 world I consider that bleeding edge. And there is going to be large community of third-party app developers writing products against the not-yet-released Plone 2.5. But my feeling was that Plone wsan't the only product based on CMF1.6 ... if it were then I could provide a monkey right in plone but this is the absolute wrong approach imho. I hope neither Plone 2.5 nor CPS 3.4 require oldstyle fti data. CMF 1.6 doesn't. Shipping Products-less python packages without profile based fti data sounds strange to me. And if the reason is that registering profiles doesn't work that should be fixed instead of falling back to oldstyle fti data. Ultimately Plone needs to get to CMF2 and that will happen with Plone 3.0, but there were simply too many changes in CMF to allow Plone to do that within the 2.5 timeframe. Anyhow, I'm trying to make compromises to keep as many people happy as possible. Originally I wanted to add this to CMF 1.5.x as well :) I'll shut up now. I don't use CMF 1.6 and I don't think your code will break CMF 1.6. I'm pretty sure that Plone is the only major user of CMF 1.6. That release wouldn't even have happened except to help out Plone's release cycle for 2.5 (which, as it turns out, would probably have been releasable against Zope 2.9 / CMF 2.0, but that is a different story). I'm -0 on including the product-less stuff in 1.6. I doubt that folks who are building Plone add-ons are going to be troubled by the need to have them installed in $INSTANCE_HOME/Products, myself. Tres. -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.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
Re: [Zope-CMF] Products-less python package support for CMF 1.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4 Jun 2006, at 16:04, Rocky Burt wrote: Anyhow, I've included a patch that demonstrates what would need to be done including some extra test logic that fails before my changes and of course passes afterwards. What do you all think? Something we can include in time for CMF1.6.1 beta2 ? There won't be any beta2 due to the short notice I had for the imminent Plone 2.5 release, I was glad I got in a single one-week beta. - -1 on including it in 1.6.1 I'm also not very keen on putting it in 1.6.2. As Yvo and Tres already implied, Plone is the single reason for having the CMF 1.6 release. It would have been better if ideas like these had come up earlier and not at the very last minute. I mean, we all knew when Plone 2.5 was going to land, they have a roadmap document. Furthermore, I'm of Tres' opinion when it comes to the actual need of such a patch. Personally I'd move that up to the next Plone feature release and CMF 2.1 (currently trunk). jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEgycFRAx5nvEhZLIRAnpVAJ99pQGkXQwK+jb8CS4dIoPxjXUu6QCeLcC9 kTdeLx2QNBQjQ+NJufRKlSM= =QDF6 -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] DCWorkflow: notifyBefore, notifySuccess and notifyException
Hello, yuppie a écrit : yuppie wrote: notifyBefore, notifySuccess and notifyException seem to be completely useless methods. [...] Oops! I did look in the wrong places. While these methods are doing nothing in DCWorkflow and the old DefaultWorkflow they are part of the interface expected by the WorkflowTool. So at least in theory third party workflows implement these methods. I wonder if they are used anywhere and what the use cases are. FWIW, I raise my hand. ;) CMFNotification [1] is a product which sends notification emails when specific events occur, which includes when a workflow transition is triggered. To do that, it monkey-patches 'DCWorkflow.notifySuccess()' (among others) to call an appropriate handler (see [2]). To me, this is the only (and less intrusive) way to be notified when any workflow transition occurs. However, I would be glad to hear about other (cleaner) implementations. Particularly, I know about Zope 3 events model, but there is no event for workflow transitions, is there? [1] http://plone.org/products/cmfnotification [2] http://dev.plone.org/collective/browser/CMFNotification/trunk/patches.py Regards, -- Damien Baty Pilot Systems - 9, rue Desargues - 75011 Paris Tél : +33 (0)1 44 53 05 55 - http://www.pilotsystems.net Free Zope Plone hosting - http://www.objectis.org ___ 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] DCWorkflow: notifyBefore, notifySuccess and notifyException
Damien Baty wrote: FWIW, I raise my hand. ;) CMFNotification [1] is a product which sends notification emails when specific events occur, which includes when a workflow transition is triggered. To do that, it monkey-patches 'DCWorkflow.notifySuccess()' (among others) to call an appropriate handler (see [2]). To me, this is the only (and less intrusive) way to be notified when any workflow transition occurs. However, I would be glad to hear about other (cleaner) implementations. Particularly, I know about Zope 3 events model, but there is no event for workflow transitions, is there? No there isn't yet, but that's the next logical step in event conversion in CMF. Would you like to work on that? It should be quite simple. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Products-less python package support for CMF 1.6
Tres Seaver wrote: yuppie wrote: Hi Rocky! Rocky Burt wrote: On Sun, 2006-04-06 at 18:12 +0200, yuppie wrote: Rocky Burt wrote: What do you all think? Something we can include in time for CMF1.6.1 beta2 ? I don't care much about CMF 1.6, but I wonder in which case your patch is useful. Are you suggesting that people write cutting-edge Products-less python packages and add deprecated fti data in those packages to make it available through the deprecated listDefaultTypeInformation method? All of this work I'm doing is geared towards having Zope 2 developers write code that is less Zope 2 specific and more python specific. Nothing about bleeding edge, etc. In the Zope 2 world I consider that bleeding edge. And there is going to be large community of third-party app developers writing products against the not-yet-released Plone 2.5. But my feeling was that Plone wsan't the only product based on CMF1.6 ... if it were then I could provide a monkey right in plone but this is the absolute wrong approach imho. I hope neither Plone 2.5 nor CPS 3.4 require oldstyle fti data. CMF 1.6 doesn't. Shipping Products-less python packages without profile based fti data sounds strange to me. And if the reason is that registering profiles doesn't work that should be fixed instead of falling back to oldstyle fti data. Ultimately Plone needs to get to CMF2 and that will happen with Plone 3.0, but there were simply too many changes in CMF to allow Plone to do that within the 2.5 timeframe. Anyhow, I'm trying to make compromises to keep as many people happy as possible. Originally I wanted to add this to CMF 1.5.x as well :) I'll shut up now. I don't use CMF 1.6 and I don't think your code will break CMF 1.6. I'm pretty sure that Plone is the only major user of CMF 1.6. That release wouldn't even have happened except to help out Plone's release cycle for 2.5 (which, as it turns out, would probably have been releasable against Zope 2.9 / CMF 2.0, but that is a different story). CPS 3.4 (which is in maintenance mode, 3.4.1 has been tagged) is using CMF 1.6 right now. Except for GenericSetup bugfixes, which we can always provide as monkey-patches from our CPSCompat product, we don't need specific evolutions from CMF 1.6 at the moment. We would only switch for the next maintenance release to CMF 1.6.1 if nothing breaks with it. CPS 4, scheduled for September, will use CMF 2.0 (and Zope 2.10). Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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
