Re: [Zope-CMF] GenericSetup backport
Le 27/05/11 10:03, Hanno Schlichting a écrit : On Thu, May 26, 2011 at 10:39 PM, Godefroid Chapelle got...@bubblenet.be wrote: Le 26/05/11 17:15, Hanno Schlichting a écrit : Smaller 1.4.x numbers could be kept for bug fix releases for CMF 2.1 and Plone 3. That's a really weird way of doing it. And I'm a -1 on that. I agree it is a bit weird, I am just trying to be creative to comply with your request of preserving Plone 3 tests. Outside being weird, can you explain issues you have ? You want to backport a feature that is known to break things into a stable release series. It does not break things, this is too wide. GS test suite was not touched outside places where tests did check internal implementation. It would be much more fair to state that it is known to break tests setup. To me that's just wrong and defeats the very purpose of having stable releases. Hanno What I am actually trying to understand is which versions to give to public releases after forking an existing branch. The numbering scheme of those versions should fill the following goals : - systems that depend on releases of the original branch should not be impacted. - new releases of the original branch should be pullable without the need to touch the existing systems. - releases of the newest branch should have their own numbering so that other packages can state unambiguous dependency on those new releases. This is what dev releases are for (as you suggested). My proposal is then the following : I would publish a Products.GenericSetup 1.4.6dev001 release from my backported branch to PyPi. And have p.a.testing 3.0.x depend explicitely on this GS 1.4.6dev001 release until there is a need for a new release of GS from this backported branch. Opinions ? -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup backport
Le 31/05/11 15:36, Hanno Schlichting a écrit : My proposal is then the following : I would publish a Products.GenericSetup 1.4.6dev001 release from my backported branch to PyPi. Sorry, but publishing dev releases is frowned upon on PyPi. The arguments against the proposal seem lighter and lighter. I begin to feel zope-dev like stop energy. The version numbering scheme we have doesn't allow for you use-case. You want to effectively fork the 1.4 release series to continue with a different feature set than we have already gotten in the 1.5 and 1.6 series. We have a stable feature releases in all of the 1.4, 1.5 and 1.6 series. If you want to introduce any new feature you can only do this in the 1.6.x or 1.7 release series. Anything else means doing a private fork and publishing it under some other URL. It's really not that hard to do that and will only cost you ten minutes. True as I told already. Anyone who wants to use this version will need a find-links URL in addition to the version pin, but that's just one extra line of config. But the user needs to know that he needs to add that line. Doing this means keeping things sane and stable for the majority of users Using a dev release does the same without the need for debugging broken cases where the user did not know. and adding a tiny little bit of extra work for the few that want to run your backport. I think that is a very sane approach. Hanno Constructively ;-) -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup backport
Le 26/05/11 17:15, Hanno Schlichting a écrit : On Thu, May 26, 2011 at 4:46 PM, Godefroid Chapellegot...@bubblenet.be wrote: Would anyone see an issue that I release a Products.GenericSetup 1.4.20 (or any other big integer) with ZCA registries ? Smaller 1.4.x numbers could be kept for bug fix releases for CMF 2.1 and Plone 3. That's a really weird way of doing it. And I'm a -1 on that. I agree it is a bit weird, I am just trying to be creative to comply with your request of preserving Plone 3 tests. Outside being weird, can you explain issues you have ? Why don't you just cut a branch of GenericSetup 1.4 with your changes and make a private (vendor) release of it? Then put the private release up on some Web server serving a flat directory, including it into the buildout via find-links? We do that all the time, see for example http://dist.jarn.com/public/ I obviously thought of an egg on our own server. Nevertheless, at least Vitaliy Podoba from Quintagroup also uses p.a.testing 3.x and I'd like him (and others) to be able to also use p.a.testing released eggs. Further, I think it is a real advantage for the product developers if they can migrate their tests to p.a.testing while keeping Plone 3 compatibility. Hanno Gotcha ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] GenericSetup backport
Hi, I had made changes to GS registries (use ZCA instead of own registries) which got released in 1.6.3. I backported those changes to 1.4. http://zope3.pov.lt/trac/browser/Products.GenericSetup/branches/1.4-with-global-zca Can I merge to 1.4 branch ? Would someone cut a new 1.4 release after merge ? Thanks -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup backport
Le 26/04/11 12:04, Hanno Schlichting a écrit : On Tue, Apr 26, 2011 at 11:53 AM, Godefroid Chapelle got...@bubblenet.be wrote: I had made changes to GS registries (use ZCA instead of own registries) which got released in 1.6.3. I backported those changes to 1.4. http://zope3.pov.lt/trac/browser/Products.GenericSetup/branches/1.4-with-global-zca Can I merge to 1.4 branch ? Please don't. The changes broke quite a number of tests This feels acceptable to me. and some of my own code. But this does not. Can you explain more ? I'd like to understand how your code got broken, which I did not foresee at all. This way, I'll learn how to avoid same type of issues for a next case. It's bad enough this got into the 1.6 bug fix releases, even though it's a feature change. Most tests failed as the ZCA now has to be setup before calling certain API's like profile_registry.registerProfile. It's been a very common pattern in Plone add-ons to call this on the module level of a test to register a test-only profile. I guess it should be possible to ensure ZCA is setup from within GS. Would that help ? We have adjusted most of the test layers for the recent Plone release, so the change can stay in the 1.6.x series from my point of view. I made a few fixes to test layers for Plone 4.1. Can you point me to the other changes that you had to do ? But if would be a lot of pain to do this for Plone 3.x releases using GenericSetup 1.4. I see. Hanno -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.GenericSetup/trunk/ Refactored global registries to use global named utilities.
Hi Yvo,
Thanks for reviewing my work !
Le 11/03/11 10:43, yuppie a écrit :
Hi Godefroid!
A few questions:
Godefroid Chapelle wrote:
Log message for revision 120850:
Refactored global registries to use global named utilities.
merge of branch gotcha-registries-use-utilities
[...]
Modified: Products.GenericSetup/trunk/Products/GenericSetup/registry.py
===
--- Products.GenericSetup/trunk/Products/GenericSetup/registry.py
2011-03-10 15:13:48 UTC (rev 120849)
+++ Products.GenericSetup/trunk/Products/GenericSetup/registry.py
2011-03-10 16:56:57 UTC (rev 120850)
[...]
@@ -721,13 +758,26 @@
# metadata.xml description trumps ZCML description... awkward
info.update( metadata )
- self._profile_info[ profile_id ] = info
+ sm.registerUtility(info, provided=IProfile, name=profile_id)
+ def _computeProfileId(self, name, product):
+ profile_id = '%s:%s' % (product or 'other', name)
+ return profile_id
+
+ security.declareProtected( ManagePortal, 'unregisterProfile' )
+ def unregisterProfile( self, name, product=None):
+ profile_id = self._computeProfileId(name, product)
+ sm = getGlobalSiteManager()
+ sm.unregisterUtility(provided=IProfile, name=profile_id)
+
security.declarePrivate( 'clear' )
def clear( self ):
+ sm = getGlobalSiteManager()
+ profile_ids = [profile_id for profile_id, profile_info
+ in sm.getUtilitiesFor(IProfile)]
+ for profile_id in profile_ids:
+ sm.unregisterUtility(provided=IProfile, name=profile_id)
- self._profile_info = {}
- self._profile_ids = []
Does GlobalRegistryStorage not work for the ProfileRegistry?
Good point.
Done ! I did it for UpgradeRegistry as well.
Modified:
Products.GenericSetup/trunk/Products/GenericSetup/tests/test_registry.py
===
---
Products.GenericSetup/trunk/Products/GenericSetup/tests/test_registry.py
2011-03-10 15:13:48 UTC (rev 120849)
+++
Products.GenericSetup/trunk/Products/GenericSetup/tests/test_registry.py
2011-03-10 16:56:57 UTC (rev 120850)
@@ -1014,6 +1014,8 @@
, ConformsToIProfileRegistry
):
+
+
def _getTargetClass( self ):
from Products.GenericSetup.registry import ProfileRegistry
@@ -1045,7 +1047,7 @@
, PRODUCT
, PROFILE_TYPE
)
-
+
self.assertEqual( len( registry.listProfiles() ), 1 )
self.assertEqual( len( registry.listProfileInfo() ), 1 )
You touched test_registry.py just to add some extra whitespace in
strange places?
Sorry for the noise. Do you want a revert ?
Modified: Products.GenericSetup/trunk/Products/GenericSetup/zcml.py
===
--- Products.GenericSetup/trunk/Products/GenericSetup/zcml.py
2011-03-10 15:13:48 UTC (rev 120849)
+++ Products.GenericSetup/trunk/Products/GenericSetup/zcml.py
2011-03-10 16:56:57 UTC (rev 120850)
[...]
def cleanUpImportSteps():
- global _import_step_regs
- for name in _import_step_regs:
- try:
- _import_step_registry.unregisterStep(name)
- except KeyError:
- pass
+ pass
- _import_step_regs = []
-
def cleanUpExportSteps():
- global _export_step_regs
- for name in _export_step_regs:
- try:
- _export_step_registry.unregisterStep(name)
- except KeyError:
- pass
+ pass
Why didn't you remove cleanUpImportSteps and cleanUpExportSteps?
I should have.
All cleanup functions are now gone.
Cheers,
Yuppie
--
Godefroid Chapelle (aka __gotcha) http://bubblenet.be
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup global registries
Le 09/03/11 15:09, Wichert Akkerman a écrit : It all looks like a workaround for a missing feature in plone.testing, which won't even help much since plone.testing needs to support older GS releases as well. Wichert. The change I made is internal implementation only. IOW, it can go into a new 1.6.x GenericSetup release... ... which next Plone 4.0.x and 4.1 can both use (AFAIK they use the same version of GenericSetup). This way, plone.testing (which is still not final) can be cleaned up. -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] GenericSetup global registries
Hello, GenericSetup has global registries for profiles and steps. They are a PITA when testing. For instance, plone.app.testing has to make a complicated dance to record and restore their state. In branch gotcha-registries-use-utilities, I have removed those global storages. The profiles and steps are instead registered as global named utilities. All tests pass. I would appreciate review : http://zope3.pov.lt/trac/changeset?old_path=%2FProducts.GenericSetup%2Fbranches%2Fgotcha-registries-use-utilitiesold=120672new_path=%2FProducts.GenericSetup%2Fbranches%2Fgotcha-registries-use-utilitiesnew=120738 If I get no comment within 1 week, I'll assume I can merge and will do so. TIA ;-) -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup global registries
Le 08/03/11 17:26, Wichert Akkerman a écrit : On 2011-3-8 17:08, Godefroid Chapelle wrote: Hello, GenericSetup has global registries for profiles and steps. They are a PITA when testing. For instance, plone.app.testing has to make a complicated dance to record and restore their state. How come? There is a very simple cleanup function for them iirc? zope.testing.cleanup functions are all or nothing; there are no ways to clear a part of what was loaded through ZCML. plone.testing zca.py uses component registry chaining to enable partial unload of components registrations. -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] GenericSetup import and export step registries
Hi, I have been looking at GenericSetup tool.py. The order in which global and local registries are queried is different in getImportStep and getExportStep on one side and in getImportStepMetadata and getExportStepMetadata on the other side. See below: def getExportStep(self, step, default=None): Simple wrapper to query both the global and local step registry. res=_export_step_registry.getStep(step, default) if res is not default: return res return self._export_registry.getStep(step, default) def getExportStepMetadata(self, step, default=None): Simple wrapper to query both the global and local step registry. res=self._export_registry.getStepMetadata(step, default) if res is not default: return res return _export_step_registry.getStepMetadata(step, default) I have looked at the SVN history and it seems that there has been merging problems. In line with usual ZCA pattern which queries local before global, I guess that the local registry should be queried before the global like in getImportStepMetadata and getExportStepMetadata. IOW, it seems it should be : def getExportStep(self, step, default=None): Simple wrapper to query both the global and local step registry. res=self._export_step_registry.getStep(step, default) if res is not default: return res return _export_registry.getStep(step, default) def getExportStepMetadata(self, step, default=None): Simple wrapper to query both the global and local step registry. res=self._export_registry.getStepMetadata(step, default) if res is not default: return res return _export_step_registry.getStepMetadata(step, default) Can someone confirm ? -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup import and export step registries
Le 02/03/11 14:59, Godefroid Chapelle a écrit : IOW, it seems it should be : def getExportStep(self, step, default=None): Simple wrapper to query both the global and local step registry. res=self._export_step_registry.getStep(step, default) if res is not default: return res return _export_registry.getStep(step, default) I meant : def getExportStep(self, step, default=None): Simple wrapper to query both the global and local step registry. res=self._export_registry.getStep(step, default) if res is not default: return res return _export_step_registry.getStep(step, default) -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] String exceptions
Hi, Python2.6 has deprecated string exceptions. However, I find about 15 string exceptions in CMF 2.2 I guess this is just something that was forgotten. Can we consider this as a critical issue for next release ? Regards -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] String exceptions
Le 25/02/11 15:23, Laurence Rowe a écrit : As mentioned on the zope-dev list, string exceptions were actually removed int Python 2.6. I still don't think it's critical though, it just raises a TypeError now instead of a string exception. Laurence Right, they are not critical. I once again spoke before thinking deep enough. -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] TypesTool and contruction permissions
Hello, I always thought I could register two portal types based on the same class with different add permissions. I read TypesTool code today. If I understand well, when using new style ZTK factories, construction permissions are looked up in meta_types registration. I came to the following conclusion : to register separate portal_types that share class implementation but have different contruction permissions, I need to register meta_types with separate permissions then use those meta_types in the FTIs to relate the permissions and the portal_types. Is this correct ? -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/branches/2.2/Products/CMFCore/exportimport/content.py remove type check that seem useless
Hi,
I have fixed an exportimport bug on branch 2.2 : see tests in revision
119560.
I'd like some review before merging the fix into trunk.
I do not know for sure that I can remove the type check.
Thanks
Gotcha
Le 13/01/11 12:00, Godefroid Chapelle a écrit :
Log message for revision 119561:
remove type check that seem useless
Changed:
U Products.CMFCore/branches/2.2/Products/CMFCore/exportimport/content.py
-=-
Modified:
Products.CMFCore/branches/2.2/Products/CMFCore/exportimport/content.py
===
--- Products.CMFCore/branches/2.2/Products/CMFCore/exportimport/content.py
2011-01-13 10:44:41 UTC (rev 119560)
+++ Products.CMFCore/branches/2.2/Products/CMFCore/exportimport/content.py
2011-01-13 11:00:16 UTC (rev 119561)
@@ -101,15 +101,9 @@
parser = ConfigParser()
title = self.context.Title()
-if isinstance(title, unicode):
-title_str = title.encode(self._encoding)
-else:
-title_str = title
+title_str = title.encode(self._encoding)
description = self.context.Description()
-if isinstance(description, unicode):
-description_str = description.encode(self._encoding)
-else:
-description_str = description
+description_str = description.encode(self._encoding)
parser.set('DEFAULT', 'Title', title_str)
parser.set('DEFAULT', 'Description', description_str)
--
Godefroid Chapelle (aka __gotcha) http://bubblenet.be
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/branches/2.2/Products/CMFCore/exportimport/content.py remove type check that seem useless
Le 13/01/11 12:07, Wichert Akkerman a écrit : On 1/13/11 12:04 , Godefroid Chapelle wrote: Hi, I have fixed an exportimport bug on branch 2.2 : see tests in revision 119560. Aren't you risking double encoding now? That patch looks like it makes things worse, not better. I am not sure I understand what you mean. I did try the patch on one of my sites where export was raising an exception. Export did work and the files produced make sense to me. In the branch, prior to apply the patch, I added tests that mimic my site setup and do not pass. With the patch, they pass. Wichert. -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/branches/2.2/Products/CMFCore/exportimport/content.py remove type check that seem useless
Le 13/01/11 14:02, Wichert Akkerman a écrit : On 1/13/11 14:01 , Godefroid Chapelle wrote: Le 13/01/11 12:07, Wichert Akkerman a écrit : On 1/13/11 12:04 , Godefroid Chapelle wrote: Hi, I have fixed an exportimport bug on branch 2.2 : see tests in revision 119560. Aren't you risking double encoding now? That patch looks like it makes things worse, not better. I am not sure I understand what you mean. I did try the patch on one of my sites where export was raising an exception. Export did work and the files produced make sense to me. In the branch, prior to apply the patch, I added tests that mimic my site setup and do not pass. But do you know why? The original code was more robust than your version, so I am extremely curious why it was failing for you and is not now. Wichert. Reproducing the bug is extremely easy : install a bare Plone 4 site with language french (this creates content with accented characters that trigger the bug) then try an export or snapshot in portal_setup. What your comment might imply is that the creation of default content in a Plone site is the culprit, rather than the export code in CMFCore. You make me wonder if I am actually reproducing something wrong in my tests setup : am I allowed to set a unicode value in Title and Description ? The code hereunder is setting up the tests : ITEMS_TITLE = u'Actualit\xe9' ITEMS_DESCRIPTION = u'Actualit\xe9 r\xe9centes' for id in ITEM_IDS: site._setObject(id, _makeINIAware(id)) item = getattr(site, id) item.setTitle(ITEMS_TITLE) item.setDescription(ITEMS_DESCRIPTION) -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/branches/2.2/Products/CMFCore/exportimport/content.py remove type check that seem useless
Le 13/01/11 14:17, Godefroid Chapelle a écrit : Le 13/01/11 14:02, Wichert Akkerman a écrit : On 1/13/11 14:01 , Godefroid Chapelle wrote: Le 13/01/11 12:07, Wichert Akkerman a écrit : On 1/13/11 12:04 , Godefroid Chapelle wrote: Hi, I have fixed an exportimport bug on branch 2.2 : see tests in revision 119560. Aren't you risking double encoding now? That patch looks like it makes things worse, not better. I am not sure I understand what you mean. I did try the patch on one of my sites where export was raising an exception. Export did work and the files produced make sense to me. In the branch, prior to apply the patch, I added tests that mimic my site setup and do not pass. But do you know why? The original code was more robust than your version, so I am extremely curious why it was failing for you and is not now. Wichert. Reproducing the bug is extremely easy : install a bare Plone 4 site with language french (this creates content with accented characters that trigger the bug) then try an export or snapshot in portal_setup. What your comment might imply is that the creation of default content in a Plone site is the culprit, rather than the export code in CMFCore. You make me wonder if I am actually reproducing something wrong in my tests setup : am I allowed to set a unicode value in Title and Description ? The code hereunder is setting up the tests : ITEMS_TITLE = u'Actualit\xe9' ITEMS_DESCRIPTION = u'Actualit\xe9 r\xe9centes' for id in ITEM_IDS: site._setObject(id, _makeINIAware(id)) item = getattr(site, id) item.setTitle(ITEMS_TITLE) item.setDescription(ITEMS_DESCRIPTION) I want to add that this setup triggers the same exception as in a live Plone site. -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/branches/2.2/Products/CMFCore/exportimport/content.py remove type check that seem useless
Le 13/01/11 14:41, Charlie Clark a écrit : Am 13.01.2011, 14:01 Uhr, schrieb Godefroid Chapellegot...@bubblenet.be: Aren't you risking double encoding now? That patch looks like it makes things worse, not better. I am not sure I understand what you mean. Hi Godefroid, the unpatched code checks to see whether a self.Title() or self.Description() are unicode in which case they can be encoded. I think what you call the unpatched code is my first attempt at fixing the bug (iow revision 119560). My first message to the list might not be clear enough to express that I am actually asking review for both revision 119560 and 119561. Your patch will force encoding even on strings, ie. double-encoding. If I understand well, you tell me that my first attempt could be correct while the second revision takes the risk to double encode. Tell me if you agree with patch in 119560. Regarding the procedure: changes to the CMF should be tested on CMF buildouts, with CMF specific tests. This is what I did ;-) I even added the missing buildout (copied from trunk - see revision 119553). You should probably run the exportimport with pdb to see what self.Title() is returning but, yes, I suspect the problem you are experiencing is Plone and not CMF related. I am still not convinced. Charlie -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/branches/2.2/Products/CMFCore/exportimport/content.py remove type check that seem useless
Le 13/01/11 17:03, Godefroid Chapelle a écrit : Le 13/01/11 15:04, Tres Seaver a écrit : This change should be reverted -- you now double-encode any already-encoded UTF=8 strings. We should probably add a test for that condition. Change reverted, test added in 119566. After having tuned the patch and its tests, I merged into trunk. -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF dev buildouts
Le 13/01/11 17:50, yuppie a écrit : Godefroid Chapelle wrote: One buildout per package is the practice in ZTK world. I have come to really appreciate it; it really lowers the barrier for contributions. checkout bootstrap buildout run tests to check state before changes fix run tests commit That only works if someone makes sure bootstrap.py and buildout.cfg are up to date. True. However, making this type of version pinning is not too hard as I usually can rely on the fact that the last developer checked the tests were running before committing. You just did have to update buildout.cfg on CMFCore trunk. Cheers, Yuppie -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
