[Zope-CMF] Re: Tools as local utilities
On Feb 2, 4:41 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: OK, sounds good, I misunderstood your email. I suppose the last bit left to do now is the custom site manager. Rocky? :) Yep, looks like I'll be starting on five.localsitemanager pretty soon. Although I didn't see if we decided anywhere how that would get included with CMF (with plone it's pretty simple as we already distribute python/lib stuff). ___ 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] List available on groups.google.com
Just dropping a note to say that since I couldn't find an already registered groups.google.com archive of the cmf mailing list I went ahead and created one. You can see it here: http://groups.google.com/group/zope-cmf-dev - 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: Adding python packages to ProductsPath
Wichert Akkerman wrote: The patch below fixes this by adding $INSTANCE_HOME/lib/python to the ProductsPaths list. This allows minimalpath to find python packages installed there. Are there any objections to commiting this to trunk? I know we've had some larger discussions on this list regarding doing something with GenericSetup so it could handle things like this but it never really got anywhere. This seems like a very minimal change ... while I don't have a full handle out the far outreaching effects of this I would certainly give it a +1 knowing what it accomplishes. - 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: [CMF 2.1] PersistentComponents is not enough
On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote: Since Five is feature-frozen and new stuff should be added in Python packages anyway, my suggestion is to put this thing into a five.localsitemanager package which would then be used by CMF 2.1, Plone 3, etc.. It could possibly be included into the Zope 2.11 release. If no one else has started this I'll probably pick up this work sometime this week with the aim of at least having it included in Plone 3.0 - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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: [CMF 2.1] PersistentComponents is not enough
While I don't have time at this very moment to address this in great detail, I will mention a few comments. On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote: Using PersistentComponents() as the component registry (a.k.a. site manager) for local sites isn't enough. That's because it doesn't understand about containment hierarchies. Imagine this folder hierarchy: /root_site/ + cmf_site/ + somefolder/ + anotherfolder/ + sitefolder/ + + stuff_in_here cmf_site is obviously a site. Let's say root_site and sitefolder are also sites (yes, Zope3-style sites can be nested). That's not to say that sitefolder is another CMF Site, it's just a Zope3-style ISite (regular zope 2 folders can be sites in Zope 2.10). You would expect component lookup at stuff_in_here to * first lookup stuff in sitefolder, * then in cmf_site, * then in root_site, * and finally in the global registry If you use PersistentComponents() this won't automatically happen! This is a major problem. This means that if someone is traversing to sitefolder and some view code calls getUtility(ICatalog) (instead of the deprecated getToolByName(context, 'portal_catalog') then the lookup will fail if sitefolder doesn't provide the utility (and it probably won't provide it). We need a LocalSiteManager implementation for Zope 2 (mostly because of the __bases__ thing, but perhaps also because we then have a designated place for local components instead of the portal root). Indeed. As a bonus, the Zope 2 LocalSiteManager could also mix in ObjectManager. Right, would be nice as well. Since Five is feature-frozen and new stuff should be added in Python packages anyway, my suggestion is to put this thing into a five.localsitemanager package which would then be used by CMF 2.1, Plone 3, etc.. It could possibly be included into the Zope 2.11 release. This would be the best approach (creating five.localsitemanager) in my opinion. But, this means CMF will either require (or distribute) five.localsitemanager. (Plone will have the same issue) I'm not sure where we stand on this. I'd like to avoid making a Five 1.6. +1 Regards, Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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: Re: Zope 3 events from workflow
On Wed, 2006-27-12 at 11:46 +0100, Jens Vagelpohl wrote: P.S.: I _hate hate hate_ doctests ;) Why? -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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: Tools as local utilities
On Sun, 2006-19-11 at 14:37 +0100, Jens Vagelpohl wrote: Using just the ActionsTool right now in order to get that all set up and then move to the other tools, I've gotten almost always there, but there is one set of tests that refuse to run right now, the ones in CMFCore.exportimport.tests.test_actions which derive from class _ActionSetup. Here's the change I have made in the actions importer code so far: snipping some code... Export actions tool. site = context.getSite() - -tool = getToolByName(site, 'portal_actions', None) +tool = getUtility(IActionsTool, context=site) This looks like it will be the new way of looking up CMF tools? Looks great. But we shouldn't have to specify ``context=site`` should we? getUtility should automatically figure out what the nearest chain of sites should be and look for local utilities in each one of them automatically no? - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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: Tools as local utilities
On Sun, 2006-19-11 at 12:59 -0500, Tres Seaver wrote: Rocky Burt wrote: But we shouldn't have to specify ``context=site`` should we? getUtility should automatically figure out what the nearest chain of sites should be and look for local utilities in each one of them automatically no? That won't work unless the tests set up the thread-local site in the same way that the publisher does. Right, but the code mentioned earlier was in code that is expected to run in testing and non-testing environments alike. So it definitely shouldn't use the context parameter and the tests should accommodate accordingly (by setting up the thread-local site or whatever). - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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: Tools as local utilities
On Sun, 2006-10-09 at 12:57 +0200, Jens Vagelpohl wrote: On 9 Sep 2006, at 22:57, Martin Aspeli wrote: philiKON pointed out something interesting to me the other day - we could actually register the existing tools as local utilities as of Zope 2.10. That way, you could do this: This sounds fine, but we'd probably want to wait until we have a CMF version that does require 2.10, right? HEAD says Zope = 2.9. Unless we want to work with indirections that know how to do the right thing. I guess as far as the Plone community is concerned having CMF 2.1 require Zope 2.10 would be no problem since the next release of Plone will require Zope 2.10. Of course I'm not going to be naive enough to think just because it's ok for the Plone community it's good enough for all other CMF consumers :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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: Tools as local utilities
On Sat, 2006-09-09 at 21:57 +0100, Martin Aspeli wrote: Hi guys, philiKON pointed out something interesting to me the other day - we could actually register the existing tools as local utilities as of Zope 2.10. That way, you could do this: actions = getUtility(IActionsTool) as another spelling for actions = getToolByName(context, 'portal_actions') But now we're being more consistent with Zope 3, we are using a proper interface and not just a string to check, we don't have to worry about passing a context parameter (though tests have to do a setSite() call), and we can let the registration be overridden with the component registry operations. +10 on this idea from me. The important thing would be to make sure the getToolByName deprecation message is smart enough to describe the exact necessary getUtility call. In other words use getToolByName(context, 'portal_properties') has been deprecated, please use getUtility(IPropertiesTool) instead rather than the confusing getToolByName has been deprecated, please use getUtility instead. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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: DirectoryView, GenericSetup/skins, CMF 2.1
Hi Yuppie, Just checking in to see if you got any of this put in place yet. Also hoping you can identify anything I need to do to ensure I can use skins with productless products :) - Rocky On Sun, 2006-09-07 at 21:59 +0200, yuppie wrote: Hi Rocky! Rocky Burt wrote: On Sun, 2006-09-07 at 13:46 +0200, yuppie wrote: The keys generated by 'utils.minimalpath' currently look like this: MyProduct/skins/my_skin full/path/to/MyPackage/skins/my_skin But we could change 'utils.minimalpath' to generate keys like these: Products/MyProduct/skins/my_skin MyPackage/skins/my_skin If we're changing how the keys look, why not simply use full package names in front with relative paths after the first slash (although I might prefer a colon or something in place of the first slash). So the new keys would be: Products.MyProduct/skins/my_skin some.long.package/skins/my_skin No need to make exception for Products in my opinion. And the retrieval logic would convert the first portion (before the first slash, or as I mentioned earlier, perhaps a colon) into an absolute path based on the actual package filesystem location. I did not want to make an exception for Products. For 'some.long.package' this would be the registry key: some/long/package/skins/my_skin But after looking again at the code I see why you propose to separate the module from the module-relative path: The FS* objects store minimal_fp in _filepath. This makes it necessary to convert minimal_fp back to the full path. AFAICS the code is unnecessary complex, we can store the full path in _filepath instead. The platform independent minimal_fp is only necessary for persistent objects. If there are no objections I'll change that on the trunk. With that change 'minimal_fp' becomes just a simple registry key without any need to convert it back to a real path. We can use the same pattern as for GenericSetup's registerProfile: Omitting 'Products/' would become deprecated. For backwards compatibility DirectoryInformations are first looked up with a Products/ prefix and if no DirectoryInformation is registered for that key the plain 'DirectoryView._dirpath' is looked up. With this lookup order MyPackage/skins/my_skin is masked by Products/MyPackage/skins/my_skin, but I guess we can live without support for that rare case until we remove the BBB code. Well, if we switch to colon's to separate package from relative path then we could still support the old and new way with no masking necessary (ie Products.MyProduct:skins/my_skin) I see your point, but if I change the value stored in _filepath we no longer need to know which part of minimal_fp represents the module. And I'd prefer the same format as in GenericSetup's registerProfile because it avoids confusion. As I mentioned already I think we can live with the masking issue for a while. And since you understand the problem so well and it only took me about 20min yesterday to come up with my initial patch... any chance you could implement the changes necessary for this? Otherwise I'll have to flounder about until I understand the minimal_fp thing a bit more :/ If I have fixed the _filepath issue there is not much left you need to understand. minimal_fp is a simple dictionary key based on the directory path. The keys you proposed make sense to me, I just would prefer to keep this in sync with registerProfile. 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 -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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: DirectoryView, GenericSetup/skins, CMF 2.1
Hi Yuppie! On Sun, 2006-09-07 at 13:46 +0200, yuppie wrote: +1 for fixing this, but may I suggest another approach? 'minimal_fp' is a registry key created by 'utils.minimalpath'. Right now 'DirectoryView._dirpath' contains this registry key and I'd prefer to keep it like that. This is fine. I'd have to admit I don't totally grok all of the implementation details for DirectoryView and the registry at this point. So anything that more properly fits the current design gets a +1 from me. The keys generated by 'utils.minimalpath' currently look like this: MyProduct/skins/my_skin full/path/to/MyPackage/skins/my_skin But we could change 'utils.minimalpath' to generate keys like these: Products/MyProduct/skins/my_skin MyPackage/skins/my_skin If we're changing how the keys look, why not simply use full package names in front with relative paths after the first slash (although I might prefer a colon or something in place of the first slash). So the new keys would be: Products.MyProduct/skins/my_skin some.long.package/skins/my_skin No need to make exception for Products in my opinion. And the retrieval logic would convert the first portion (before the first slash, or as I mentioned earlier, perhaps a colon) into an absolute path based on the actual package filesystem location. While it doesn't make sense to store full/path/to/MyPackage/skins/my_skin in 'DirectoryView._dirpath' MyPackage/skins/my_skin would work fine. All we need is a migration path. Indeed. But given my little knowledge at this point I'm not sure what the migration path would look like. We can use the same pattern as for GenericSetup's registerProfile: Omitting 'Products/' would become deprecated. For backwards compatibility DirectoryInformations are first looked up with a Products/ prefix and if no DirectoryInformation is registered for that key the plain 'DirectoryView._dirpath' is looked up. With this lookup order MyPackage/skins/my_skin is masked by Products/MyPackage/skins/my_skin, but I guess we can live without support for that rare case until we remove the BBB code. Well, if we switch to colon's to separate package from relative path then we could still support the old and new way with no masking necessary (ie Products.MyProduct:skins/my_skin) And since you understand the problem so well and it only took me about 20min yesterday to come up with my initial patch... any chance you could implement the changes necessary for this? Otherwise I'll have to flounder about until I understand the minimal_fp thing a bit more :/ Thanks, Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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] DirectoryView, GenericSetup/skins, CMF 2.1
Hi all, I'm currently investigating registering DirectoryView's from regular python packages with GenericSetup+skins.xml. After debugging through this somewhat I have discovered that minimal paths described in skins.xml are made relative to $INSTANCE_HOME/Products. Obviously in a regular python package (living outside of Products) this means using minimal paths won't work. And of course since the actual location of the py package will vary from deployment to deployment, the logical approach would be to make the minimal path relative to the package home. Does anyone have any idea's on this? So far it looks like all other major cmf functionality can be used outside in a regular python package (living outside of Products). Perhaps I'm missing something? If this is indeed the case ... would you all entertain a proposal/patch from me providing a way to use skins from py packages that is b/w compatible with the current approach? Thanks, Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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: DirectoryView, GenericSetup/skins, CMF 2.1
On Sat, 2006-08-07 at 15:30 -0400, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky Burt wrote: I'm currently investigating registering DirectoryView's from regular python packages with GenericSetup+skins.xml. After debugging through this somewhat I have discovered that minimal paths described in skins.xml are made relative to $INSTANCE_HOME/Products. Obviously in a regular python package (living outside of Products) this means using minimal paths won't work. And of course since the actual location of the py package will vary from deployment to deployment, the logical approach would be to make the minimal path relative to the package home. Does anyone have any idea's on this? So far it looks like all other major cmf functionality can be used outside in a regular python package (living outside of Products). Perhaps I'm missing something? If this is indeed the case ... would you all entertain a proposal/patch from me providing a way to use skins from py packages that is b/w compatible with the current approach? Hmmm, I thought this was landed already: I worked that out back in November / December, I think, on the 'tseaver-pkg_resources' branch. I just briefly inspected the tseaver-pkg_resources branch and I have a few questions/comments: 1. was this ever merged into trunk for cmf2.1 inclusion (my brief comparisons leads me to believe it was not) ? 2. it looks like the branch was put in place to make it so the cmf files themselves uses pkg_resources so they can be loaded from eggs and the like -- not that the paths pointed to by DirectoryViews could exist outside of Products (relative paths I mean) Perhaps I'm missing something? I'd welcome a technical explanation as to what exactly the branch tried to do and the ETA on inclusion into trunk. Thanks, Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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: zLOG - logging
On Wed, 2006-07-06 at 18:26 +0200, Florent Guillaume wrote: Is it ok if I change CMF 1.6 (currently in beta) to use the logging module instead of zLOG? zLOG spouts lots of warnings under Zope 2.10 and this sucks. +1 -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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] CMF providing support for add forms?
Hi all, I was wondering if CMF does or is planning on implementing support for add forms for content. If so, would someone mind explaining how it works? If not, why not? :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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] adding items to the TALES namespace for actions
Hi all, I'd like to add a new variable to the TALES namespace for all actions (for all existing action providers) on a CMF 1.6.0 site. We basically have a view that provides some global vars that we'd like to expose. Does anyone know of a sensible way to do this without monkey patching CMFCore.Expression.createExprContext ? Or perhaps suggest a different way of accomplishing what we need? Thanks, Rocky -- Rocky Burt AdaptiveWave - Content Management as a Service http://www.adaptivewave.com Content Management Made 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
[Zope-CMF] bug on CMFonFive trunk
Hi all (Lennart), I've been using CMFonFive 1.3.0 + Zope 2.9.0 + Plone 2.1.2 (svn up until recently) quite successfully lately. Due to work I need to do on my CMFonFive branch I switched to the CMFonFive trunk (which will be 1.3.1) and tried installing CMFonFive into my (new) Plone sites. I'm getting a problem (this error *does not* occur with the released version of CMFonFive 1.3.1). See the traceback of the error below. The only difference I'm able to see between CMFonFive trunk and CMF 1.3.0 was a change made by Lennart which was in fiveactionstool.py and of the effect: -if isinstance(title, unicode): +# Having bits of unicode here can make rendering very confused, +# so we convert it to plain strings, but NOT if it is a +# messageID. In Zope 3.2 there are two types of messages, +# Message and MessageID, where MessageID is depracated. We can +# type-check for both but that provokes a deprecation warning, +# so we check for the domain attribute instead. +if not hasattr(title, 'domain'): title = str(title) act = ActionInformation(id=act_id, title=title, So I'm guessing this problem has to do with the new checking? Any chance you could take a look, Lennart? Traceback (innermost last): * Module ZPublisher.Publish, line 113, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 40, in call_object * Module Shared.DC.Scripts.Bindings, line 311, in __call__ * Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec * Module Products.CMFCore.FSPageTemplate, line 195, in _exec * Module Products.CMFCore.FSPageTemplate, line 134, in pt_render * Module Products.PageTemplates.PageTemplate, line 104, in pt_render FSPageTemplate at /sites/site1/document_view used for /sites/site1/front-page * Module TAL.TALInterpreter, line 238, in __call__ * Module TAL.TALInterpreter, line 281, in interpret * Module TAL.TALInterpreter, line 749, in do_useMacro * Module TAL.TALInterpreter, line 281, in interpret * Module TAL.TALInterpreter, line 457, in do_optTag_tal * Module TAL.TALInterpreter, line 442, in do_optTag * Module TAL.TALInterpreter, line 437, in no_tag * Module TAL.TALInterpreter, line 281, in interpret * Module TAL.TALInterpreter, line 749, in do_useMacro * Module TAL.TALInterpreter, line 281, in interpret * Module TAL.TALInterpreter, line 455, in do_optTag_tal * Module TAL.TALInterpreter, line 437, in no_tag * Module TAL.TALInterpreter, line 281, in interpret * Module TAL.TALInterpreter, line 691, in do_loop_tal * Module TAL.TALInterpreter, line 281, in interpret * Module TAL.TALInterpreter, line 457, in do_optTag_tal * Module TAL.TALInterpreter, line 442, in do_optTag * Module TAL.TALInterpreter, line 437, in no_tag * Module TAL.TALInterpreter, line 281, in interpret * Module TAL.TALInterpreter, line 457, in do_optTag_tal * Module TAL.TALInterpreter, line 442, in do_optTag * Module TAL.TALInterpreter, line 437, in no_tag * Module TAL.TALInterpreter, line 281, in interpret * Module TAL.TALInterpreter, line 617, in do_insertTranslation * Module TAL.TALInterpreter, line 281, in interpret * Module TAL.TALInterpreter, line 541, in do_insertText_tal * Module cgi, line 1039, in escape AttributeError: 'NoneType' object has no attribute 'replace' - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: bug on CMFonFive trunk
Rocky Burt wrote: ... I'm getting a problem (this error *does not* occur with the released version of CMFonFive 1.3.1)... Whoops, I meant released version of 1.3.0 - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: Move GenericSetup out of CMF
Jens Vagelpohl wrote: OK, all done now. jens Hmm... I think you forgot to do the svn:externals for CMF 1.6 branch too? (was GenericSetup removed from there as well?) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: Okay, I read CMF 2.0 is targetting Zope 2.9 now, but Plone is, as of yet, still targeting CMF 1.6. Whether they really will I guess also depends on Plone's commitment to release this spring and suppress changing things around. I think there are two reasons Plone 2.5 is targetting CMF 1.6 (instead of just going to CMF 2.0) 1) the risk that CMF 2.0 wouldn't be ready when plone -- and I'm pretty sure the 6 month release rule has already been adopted for Plone with Plone 2.1 - 2.5 trying to be the first 6 month interval 2) CMF 2.0 changes too many things -- because of the plethora of existing plone products out there and the pains that people are going through porting them from Plone 2.0 - 2.1, the Plone community is striving to not do the same thing going from Plone 2.1 - 2.5 - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
Philipp von Weitershausen wrote: Fair enough. It seems to several people, though, that explaining to people how Python packages are installed and then how you hook up these packages into your instances is easier than explaining all the magic that revolves around Products to them. Because in the end you won't have to explain how to install Python packages at all because it's the same all the time... Indeed, its time for Zope developers to think less like zope developers and think more like python developers :) How urgent is it that all of this works with Zope 2.8? I guess it's urgent if you want to sell it to the Plone community, which will only switch to Zope 2.9 or beyond by next year or so, I expect. How much more often is this kind of thing therefore going to happen? Given Plone hasn't adopted time-based releases yet, I'm not sure. AFAIK they want time-based releases, 6 months apart like Zope. Just yesterday I suggested they make them 3 months off to the Zope releases. That way they can keep on track with Zope releases and not lag behind all the time. My understanding is that Plone 2.1 - 2.5 was meant to be the first time based release. But Alec Mitchel would have to answer that one, being the release manager. I do support sync'ing these plone 6 month release cycles with zope's releases (being 3 months off) and I think I heard a few plone people second the sentiment. You can turn that around; for consistency of installation experience in Zope 2.8, it's important that people don't get a new way of installing products, confusing innocent individuals installing Zope software. For the cutting edge, Zope 2.9, that argument is slightly different. Well, any non-familiar zope2 sys admin who's installed plugins has almost certainly had to install python code in site-packages as well. Telling them oh, you can just stick this on site-packages as well, or put it in INSTANCE_HOME/lib/python if you need different versions with different zope instances I think won't confuse innocent individuals. I want to identify the reasons why it is so important that this change happens with Zope 2.8. The main reason I can identify is Plone, correct? Single biggest reason is so that people developing products within the next 6-12 months can develop using this new style. Of course we can say that as a consultant we just require our clients to upgrade to Zope 2.9, but the reality is we all have plenty of clients who won't be able or willing to make the upgrade from Zope 2.8 to 2.9 especially with the leap of going from py2.3 to py2.4. This has the biggest bearing on Plone because even though Plone 2.5 will support zope 2.8 and 2.9 both (I actually tried to convince them to drop support for 2.8, but that didn't work out), the majority will use zope 2.8 -- based on experience with Plone 2.1 supporting Zope 2.7 and 2.8 where most Plone 2.1 installs still seem to use Zope 2.7. I'm not a great debater by any means so I'll finish this with one more reason as to why and make Zope 2.8 support this functionality -- because it will make my life a great deal easier :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
Philipp von Weitershausen wrote: Yes. In fact, if one exists, it's automatically put on your PYTHONPATH for that instance. I think we should make Zope 2.8+ instance skeleta grow a lib/python directory. This can hardly be considered a feature, so we should be able to sneak it into the next bugfix releases of 2.8 and 2.9. +1 I was discussing this with someone a while back asking why we shouldn't just add this directory to the standard instance structure. A lot of zope2 developers still don't realize that INSTANCE_HOME/lib/python can exist and will get used if it does exist. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: GenericSetup zcml registration of profiles
Tres Seaver wrote: Florent Guillaume wrote: I propose to add a new directive registerProfile in GenericSetup so that profile registration can be done through zcml. What namespace should I use? How about 'http://namespaces.zope.org/genericsetup'? Ohh, could I state the obvious and suggest the default namespace prefix for genericsetup should be setup ? :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
Florent Guillaume wrote: Rocky how does your effort relate to Basket by the way? ISTR that Basket aims at answering a similar use case. Basket is for distributing zope2 products in egg form. I've been working with Chris closely on it. In fact I added the support that allows people to write zope2 products without the toplevel Products namespace package with eggs for Basket. Its there where I discovered the more prominent area's that needed to be monkey patched and reused that knowledge when adding similar work to Five. Once everything lands in Zope 2.10, there will be no need for the monkies in Basket (or possibly even Basket itself) or this Five work. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: future of getToolByName
whit wrote: I remember some discussion of this in the past. Transitionally, it would be helpful to be able to register local utilities to a tool name, and then have getToolByName spit out a deprecation warning and return an appropriate object. thoughts? comments? does this exist somewhere already? Hmm... I'm not sure this is useful unless we map standard utilities to the equivalently functioning tool (which I don't think is a good idea). So if thats not the case, and developers need to learn all the new names, I'd suggest they use the standard zope3 way of looking up utilities. Just my opinion of course. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
Jens Vagelpohl wrote: What I am reading out of this is that *you* yourself have a burning desire to continue supporting 1.5. I don't quite get it. My biggest reason for wanting to support CMF 1.5 is so that Plone developers don't have to wait *at least* another 4 months before they can build plone python-packages-as-products. (Plone 2.5 will be the first Plone version to use CMF 1.6 and isn't scheduled for final release until May 8) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: [z3-five] Re: RFC: products-less python packages as zope2 products
Since this got sent over to the CMF mailing list I'll ask here. Dear CMF mailing list... :) I've implemented some functionality on the Five branch which enables regular zope 2 products to be used from the PYTHONPATH and without requiring the Products toplevel package. But I've identified some code in CMF that needs to be modified to accomodate. The behaviour works identical as to before *except* that it now checks products that don't necessarilly live underneath Products in listDefaultTypeInformation. I would like to consider including this change in CMF 1.6. What do you all think? - Rocky Lennart Regebro wrote: On 1/13/06, yuppie [EMAIL PROTECTED] wrote: - CMF 1.6 is not yet released so it might be possible to change it directly. I think we should, but this met some resistance. I want to get rid of CMFonFive completely. Since CMF with version 1.5.2 became Five-aware, CMFonFive has lost it's raison d'etre, and I want to get everything into CMF. - CMFonFive might be a good place for the patch. The same patch should work for CMF 1.5 and 1.6. If not, we would end up with four different version of CMFonFive for different combinations of Five, Zope and CMF, and I think three is too many already. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.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 -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: CMF 2.0 Release Status
Martin Aspeli wrote: ... Does that mean that there is *no* way to e.g. overide document_view.pt or whatever else? Or just no TTW way? Basically it means no TTW way. You should be able to override view component definitions with overrides.zcml. But regarding the TTW customization, I happen to know some of the brightest Zope minds are brainstorming on these things :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: The components of Archetypes
Rocky Burt wrote: 1) Ease of development - AT helps cut down on boilerplate code as compared to building a regular CMF type (without AT) 2) Schema - The ability to declare which fields a content type has and what types those fields are 3) Widgets - The ability to declare general purpose distributable widgets that get displayed by default for either viewing a field directly or viewed the editable version of a field 4) References - Being able to have a common framework that allows us to relate one AT-based content type instance to another I forgot a very important fifth component: 5) Storage layers - AT provides a standard way of having the storage of fields exist somewhere other than directly on the content type itself such as in a sql database. My opinion on #5 is: I think sqlos has a good approach to accomplishing another storage layer on standard z3 content types. At a minimum the AT storage layer mechanism should be broken out... possibly using the same sort of strategy as sqlos (although I think I'd still like to see something a little more transparent that does all field-implementation mappings externally in zcml or something similiar) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: CMF 1.6 change broke Plone compatibility
Well now I'm *completely* confused. grin - Rocky Alexander Limi wrote: On Wed, 21 Dec 2005 00:32:02 +0100, yuppie [EMAIL PROTECTED] wrote: AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. Just a terminology correction here, the next version of Plone is 2.5, not 2.2 - we changed our version policy a while back: http://plone.org/products/plone/roadmap/114 http://plone.org/roadmap (Not that important for this discussion, but just a heads-up so you non-Plone people don't get confused about 2.2 vs. 2.5 when we talk about it later. :) -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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] CMFSetup, getting started
Hi CMF'ers, With all the recent talks on getting GenericSetup/CMFSetup working on CMF 2.0 and knowing that CMFSetup is already with us in CMF 1.5, I've decided to finally take the plunge and figure this thing out. So I started poking around in the CMFSetup and README.txt does a great job of describing what CMFSetup can do, but doesn't seem to describe anything on how to actually do it. I guess what I'm asking for here is some starter docs/comments/examples on getting started with CMFSetup. Could someone point out a good example product that makes use of CMFSetup? Are there any docs out there that describe how to get going with CMFSetup? Thanks, Rocky ps. Raphael, it would be phenomenal if your MySite tutorial could be extended to cover something like this. -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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: CMFSetup, getting started
I forgot to mention that I'm trying to get started with CMFSetup in CMF 1.5 as my current deployment platform happens to be Plone 2.1.1. Hopefully most of CMFSetup's (from CMF 1.5) functionality is migratable into CMF 2.0. - Rocky Rocky Burt wrote: Hi CMF'ers, With all the recent talks on getting GenericSetup/CMFSetup working on CMF 2.0 and knowing that CMFSetup is already with us in CMF 1.5, I've decided to finally take the plunge and figure this thing out. So I started poking around in the CMFSetup and README.txt does a great job of describing what CMFSetup can do, but doesn't seem to describe anything on how to actually do it. I guess what I'm asking for here is some starter docs/comments/examples on getting started with CMFSetup. Could someone point out a good example product that makes use of CMFSetup? Are there any docs out there that describe how to get going with CMFSetup? Thanks, Rocky ps. Raphael, it would be phenomenal if your MySite tutorial could be extended to cover something like this. -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ 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
