[Zope-CMF] Re: GenericSetup now incompatible with Zope 2.8?
yuppie wrote: > Jens Vagelpohl wrote: >> This checkin seems to have broken Zope 2.8-compatibility: >> >> http://svn.zope.org/GenericSetup/trunk/tests/common.py?rev=68391&r1=41338&r2=68391 >> >> >> Specifically, the line "from zope.testing.cleanup import cleanUp" >> breaks Zope 2.8, I checked all stable tags (2.8.5, 2.8.6, 2.8.7) and >> there is no toplevel name "cleanUp" in zope.testing.cleanup. >> >> DEPENDENCIES.txt still claims it works with Zope 2.8.5 and higher. One >> or the other needs changing, either DEPENDENCIES.txt needs updating >> or, if this breakage was inadvertently introduced, common.py needs >> fixing. > > Sorry, my mistake. I only tested against Zope 2.9 and 2.10 before > checking in. > > Should be fixed now: http://svn.zope.org/?rev=68474&view=rev Simply avoiding the cleanup in Zope 2.8 isn't a proper fix. You should instead do the following (which works across all Zopes): from zope.testing.cleanup import CleanUp CleanUp().cleanUp() ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open 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] Re: GenericSetup now incompatible with Zope 2.8?
Hi Philipp!
Philipp von Weitershausen wrote:
yuppie wrote:
Should be fixed now: http://svn.zope.org/?rev=68474&view=rev
Simply avoiding the cleanup in Zope 2.8 isn't a proper fix. You should
instead do the following (which works across all Zopes):
from zope.testing.cleanup import CleanUp
CleanUp().cleanUp()
Thanks for keeping an eye on these checkins, but I believe in this case
it is a proper fix. You just can't see it in the diff. There is nothing
to clean up in Zope 2.8. These tests require the traversing setup only
in Zope 2.10 and a separate 'traversing.zcml' does not exist in earlier
Zope/Five versions. I attached the complete code.
Cheers,
Yuppie
class SecurityRequestTest(ZopeTestCase):
def setUp(self):
import Products
from AccessControl.SecurityManagement import newSecurityManager
ZopeTestCase.setUp(self)
try:
# BBB: for Zope 2.9
from Products.Five.traversable import FiveTraversable
except ImportError:
zcml.load_config('meta.zcml', Products.Five)
zcml.load_config('traversing.zcml', Products.Five)
self.root = self.app
newSecurityManager(None,
OmnipotentUser().__of__(self.app.acl_users))
def tearDown(self):
from AccessControl.SecurityManagement import noSecurityManager
noSecurityManager()
ZopeTestCase.tearDown(self)
try:
from zope.testing.cleanup import cleanUp
cleanUp()
except ImportError:
# BBB: for Zope 2.8
pass
___
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] [Patch] GenericSetup and encodings
Hi Yves!
Yves Bastide wrote:
GenericSetup has problems handling non-ASCII data.
1.) GenericSetup explicitly doesn't support non-UTF-8 XML in profiles.
UTF-8 is the default encoding for XML and I can't see a need to support
other XML encodings.
2.) GenericSetup explicitly doesn't support non-UTF-8 site settings. If
someone provides a good patch this feature can be added.
3.) GenericSetup is not tested with non-ASCII UTF-8 site settings. AFAIK
import works, but not export. I consider this a bug.
It treats strings
sometimes as ASCII, sometimes as UTF-8, yet it has access to two
variables: its own ISetupContext.getEncoding() (whose use I didn't fully
grok) and CMF's ISetupContext.getSite().getProperty('default_charset').
Sorry, but your assumptions are wrong:
- The default setup tool creates export contexts without specifying the
encoding, so ISetupContext.getEncoding() returns always None. And even
if it would be set it represents the encoding of the exported files, not
the site encoding.
- getSite().getProperty('default_charset') is CMF specific and should
not be used in GenericSetup.
- The adapters adapt ISetupEnviron, not ISetupContext. getEncoding() and
getSite() are not always available.
Attached is a patch using both of them and somewhat working in my setup.
Can knowledgeable people comment on it before I enter a collector issue?
(I'm using GS alongside with CPS, which also needs some patching; yet
basic things, such as exporting-importing an iso8859-15 Title in a CMF
charset-default'ed to iso8859-15, should work)
First of all we need unit tests that make sure UTF-8 works and I think
this should be the default used by GenericSetup. Code that needs to know
how to find the site encoding can't be generic.
There is an additional problem: If tools use the default property edit
page from OFS the properties might have a different encoding than
'default_charset' of the site. Since the default
'management_page_charset' is UTF-8 we have less trouble if we allow only
UTF-8.
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: [RFC] [Patch] GenericSetup and encodings
yuppie wrote:
Hi Yves!
Yves Bastide wrote:
GenericSetup has problems handling non-ASCII data.
1.) GenericSetup explicitly doesn't support non-UTF-8 XML in profiles.
UTF-8 is the default encoding for XML and I can't see a need to support
other XML encodings.
2.) GenericSetup explicitly doesn't support non-UTF-8 site settings. If
someone provides a good patch this feature can be added.
3.) GenericSetup is not tested with non-ASCII UTF-8 site settings. AFAIK
import works, but not export. I consider this a bug.
It treats strings sometimes as ASCII, sometimes as UTF-8, yet it has
access to two variables: its own ISetupContext.getEncoding() (whose
use I didn't fully grok) and CMF's
ISetupContext.getSite().getProperty('default_charset').
Sorry, but your assumptions are wrong:
- The default setup tool creates export contexts without specifying the
encoding, so ISetupContext.getEncoding() returns always None. And even
if it would be set it represents the encoding of the exported files, not
the site encoding.
- getSite().getProperty('default_charset') is CMF specific and should
not be used in GenericSetup.
- The adapters adapt ISetupEnviron, not ISetupContext. getEncoding() and
getSite() are not always available.
Attached is a patch using both of them and somewhat working in my
setup. Can knowledgeable people comment on it before I enter a
collector issue? (I'm using GS alongside with CPS, which also needs
some patching; yet basic things, such as exporting-importing an
iso8859-15 Title in a CMF charset-default'ed to iso8859-15, should work)
First of all we need unit tests that make sure UTF-8 works and I think
this should be the default used by GenericSetup. Code that needs to know
how to find the site encoding can't be generic.
There is an additional problem: If tools use the default property edit
page from OFS the properties might have a different encoding than
'default_charset' of the site. Since the default
'management_page_charset' is UTF-8 we have less trouble if we allow only
UTF-8.
Let's not forget also that the goal in CMF 2 (I think) is to have all
content be unicode strings, never encoded ones. In that case GenericSetup
only has to deal with the XML file's encoding (always UTF-8 anyway) but
that's all.
CPS 3 was a pure-latin1 application for various historical reasons, so we
modified a number of I/O adapters so that they encode/decode properly what
GenericSetup works with. CPS 3.4 tends to remove the hardcoding of latin-1
to the site's default_charset property, but that's not been taken into
account everywhere, although it should.
CPS 4 will be purely unicode, and won't need all that shit.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+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: [RFC] [Patch] GenericSetup and encodings
Hi Florent! Florent Guillaume wrote: Let's not forget also that the goal in CMF 2 (I think) is to have all content be unicode strings, never encoded ones. In that case GenericSetup only has to deal with the XML file's encoding (always UTF-8 anyway) but that's all. That's a long term goal. AFAICT nobody is working on it. CPS 3 was a pure-latin1 application for various historical reasons, so we modified a number of I/O adapters so that they encode/decode properly what GenericSetup works with. CPS 3.4 tends to remove the hardcoding of latin-1 to the site's default_charset property, but that's not been taken into account everywhere, although it should. CPS 4 will be purely unicode, and won't need all that shit. Also configuration data? I guess CPS 4 will still use some CMF tools and a lot of work will be necessary to make them play nice with unicode. 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: [RFC] [Patch] GenericSetup and encodings
yuppie wrote:
Hi Yves!
Yves Bastide wrote:
GenericSetup has problems handling non-ASCII data.
1.) GenericSetup explicitly doesn't support non-UTF-8 XML in profiles.
UTF-8 is the default encoding for XML and I can't see a need to support
other XML encodings.
As output, right? Agreed.
2.) GenericSetup explicitly doesn't support non-UTF-8 site settings. If
someone provides a good patch this feature can be added.
But with the problems you mention later ('default_charset',
'management_page_charset', and so on), how would you envision it?
3.) GenericSetup is not tested with non-ASCII UTF-8 site settings. AFAIK
import works, but not export. I consider this a bug.
Neither: CMF trunk, change portal_types/Document's title to 'Dôcument',
export:
Traceback (innermost last):
Module ZPublisher.Publish, line 115, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 41, in call_object
Module Products.GenericSetup.tool, line 471, in manage_exportAllSteps
Module Products.GenericSetup.tool, line 272, in runAllExportSteps
Module Products.GenericSetup.tool, line 736, in _doRunExportSteps
Module Products.CMFCore.exportimport.typeinfo, line 198, in
exportTypesTool
Module Products.GenericSetup.utils, line 728, in exportObjects
Module Products.GenericSetup.utils, line 722, in exportObjects
Module Products.GenericSetup.utils, line 501, in _exportBody
Module xml.dom.minidom, line 62, in toprettyxml
Module StringIO, line 271, in getvalue
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf4 in position 20:
ordinal not in range(128)
It treats strings sometimes as ASCII, sometimes as UTF-8, yet it has
access to two variables: its own ISetupContext.getEncoding() (whose
use I didn't fully grok) and CMF's
ISetupContext.getSite().getProperty('default_charset').
Sorry, but your assumptions are wrong:
- The default setup tool creates export contexts without specifying the
encoding, so ISetupContext.getEncoding() returns always None. And even
if it would be set it represents the encoding of the exported files, not
the site encoding.
- getSite().getProperty('default_charset') is CMF specific and should
not be used in GenericSetup.
- The adapters adapt ISetupEnviron, not ISetupContext. getEncoding() and
getSite() are not always available.
Thanks for setting me right. What's the usefulness of getEncoding()? As
you say, exported files don't need to be other than utf-8 encoded.
First of all we need unit tests that make sure UTF-8 works and I think
this should be the default used by GenericSetup. Code that needs to know
how to find the site encoding can't be generic.
Yep.
There is an additional problem: If tools use the default property edit
page from OFS the properties might have a different encoding than
'default_charset' of the site. Since the default
'management_page_charset' is UTF-8 we have less trouble if we allow only
UTF-8.
D'oh! /manage is 8859-15, /manage_menu is -1 and manage_propertiesForm
UTF-8. No wonder Firefox sometimes gets confused :-)
Well, I think I can wriggle out of most of my problems using
translation. And I'll try and write UTF-8 unit tests if nobody beats me
to it.
Thanks!
Cheers,
Yuppie
yves
___
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] zLOG -> logging
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. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +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: zLOG -> logging
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 if you forward port the fixes ;) (see http://www.zope.org/Collectors/CMF/439) 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: [RFC] [Patch] GenericSetup and encodings
Hi!
Yves Bastide wrote:
yuppie wrote:
2.) GenericSetup explicitly doesn't support non-UTF-8 site settings.
If someone provides a good patch this feature can be added.
But with the problems you mention later ('default_charset',
'management_page_charset', and so on), how would you envision it?
Maybe PropertyManagerHelpers should have a _properties_encoding
attribute that defaults to utf-8 and can be easily overridden by subclasses.
Or we try to set the default encoding the same way manage_propertiesForm
does. That might be even better than using always utf-8.
The adapters shipped with CMF would be responsible for CMF-specific
modifications to _properties_encoding.
3.) GenericSetup is not tested with non-ASCII UTF-8 site settings.
AFAIK import works, but not export. I consider this a bug.
Neither: CMF trunk, change portal_types/Document's title to 'Dôcument',
export:
Traceback (innermost last):
Module ZPublisher.Publish, line 115, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 41, in call_object
Module Products.GenericSetup.tool, line 471, in manage_exportAllSteps
Module Products.GenericSetup.tool, line 272, in runAllExportSteps
Module Products.GenericSetup.tool, line 736, in _doRunExportSteps
Module Products.CMFCore.exportimport.typeinfo, line 198, in
exportTypesTool
Module Products.GenericSetup.utils, line 728, in exportObjects
Module Products.GenericSetup.utils, line 722, in exportObjects
Module Products.GenericSetup.utils, line 501, in _exportBody
Module xml.dom.minidom, line 62, in toprettyxml
Module StringIO, line 271, in getvalue
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf4 in position 20:
ordinal not in range(128)
This traceback just confirms that export does not work. Is import also
broken?
Thanks for setting me right. What's the usefulness of getEncoding()? As
you say, exported files don't need to be other than utf-8 encoded.
I guess it just exists for historical reasons.
Well, I think I can wriggle out of most of my problems using
translation. And I'll try and write UTF-8 unit tests if nobody beats me
to it.
That would be great.
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: 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
Re: [Zope-CMF] zLOG -> logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7 Jun 2006, at 18:26, 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. Yeah, should be fine. You're using CMF 1.6 under Zope 2.10? I only ever test it under Zope 2.8. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEhxgRRAx5nvEhZLIRAkOwAKC1c5lv0wgGt8yhaLDHVwR9j0FGqwCeMWHh Z5xRUu7WYaVNEf/7Nca6rz8= =hq6J -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] zLOG -> logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7 Jun 2006, at 20:24, Andreas Jung wrote: --On 7. Juni 2006 20:16:49 +0200 Jens Vagelpohl <[EMAIL PROTECTED]> wrote: On 7 Jun 2006, at 18:26, 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. Yeah, should be fine. You're using CMF 1.6 under Zope 2.10? I only ever test it under Zope 2.8. I have the impression that Zope 2.9 is ignored by most ppl :-) Absolutely not, I test CMF 2.0 against Zope 2.9 ;) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEhyH+RAx5nvEhZLIRAvyIAJ0Vo5IHiWggXZwGTbpeFiLbR0wdEACcC9VD QlKHy8sVqzeG+kCiLMi+9Y0= =mK2v -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: zLOG -> logging
Jens Vagelpohl wrote: On 7 Jun 2006, at 20:24, Andreas Jung wrote: I have the impression that Zope 2.9 is ignored by most ppl :-) Absolutely not, I test CMF 2.0 against Zope 2.9 ;) And CPS 3.3 and 3.4 have been using Zope 2.9 since its inception, and is the only recommended "stable" platform for them. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +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: zLOG -> logging
Florent Guillaume wrote: And CPS 3.3 and 3.4 have been using Zope 2.9 since its inception, and is the only recommended "stable" platform for them. Though they also flood the console with zLOG deprecation warnings ;-) (I incrementally patched the worst offenders on my local copy, but never sent the result mainly because of the BLATHER/TRACE/DEBUG-to-debug impedance mismatch) Florent yves ___ 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
Yves Bastide wrote: And CPS 3.3 and 3.4 have been using Zope 2.9 since its inception, and is the only recommended "stable" platform for them. Though they also flood the console with zLOG deprecation warnings ;-) (I incrementally patched the worst offenders on my local copy, but never sent the result mainly because of the BLATHER/TRACE/DEBUG-to-debug impedance mismatch) Well you're better off patching zLOG then, to make it not send the warning :) Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +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: zLOG -> logging
Florent Guillaume wrote:
Yves Bastide wrote:
And CPS 3.3 and 3.4 have been using Zope 2.9 since its inception, and
is the only recommended "stable" platform for them.
Though they also flood the console with zLOG deprecation warnings ;-)
(I incrementally patched the worst offenders on my local copy, but
never sent the result mainly because of the
BLATHER/TRACE/DEBUG-to-debug impedance mismatch)
Well you're better off patching zLOG then, to make it not send the
warning :)
Too easy :-)
(And I just saw ZODB.loglevels.{TRACE,BLATHER}. /me go hiding)
Florent
yves
___
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] [Patch] GenericSetup and encodings
yuppie wrote:
Hi!
Yves Bastide wrote:
yuppie wrote:
3.) GenericSetup is not tested with non-ASCII UTF-8 site settings.
AFAIK import works, but not export. I consider this a bug.
[...]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf4 in position
20: ordinal not in range(128)
This traceback just confirms that export does not work. Is import also
broken?
Differently: it may or may not raise ... And Zope treats properties as
iso8859-15 anyway.
Fresh install of Zope trunk (after a long struggle; make instance now
works but make install is broken?) and CMF trunk, with
~/src/CMF$ svn diff
Index: CMFDefault/profiles/default/properties.xml
===
--- CMFDefault/profiles/default/properties.xml (revision 68514)
+++ CMFDefault/profiles/default/properties.xml (working copy)
@@ -1,6 +1,6 @@
- Portal
+ Portàl
[EMAIL PROTECTED]
Fails when CMFDefault.factory.addConfiguredSite calls createSnapshot.
Here's a minimal patch for GenericSetup not to raise on the previous
case (Demonstration product. Not for sale.)
[EMAIL PROTECTED]:~/src/CMF$ svn diff GenericSetup/
Index: GenericSetup/context.py
===
--- GenericSetup/context.py (revision 68514)
+++ GenericSetup/context.py (working copy)
@@ -475,7 +475,7 @@
if isinstance( body, unicode ):
encoding = self.getEncoding()
if encoding is None:
-body = body.encode()
+body = body.encode('UTF-8')
else:
body = body.encode( encoding )
Index: GenericSetup/utils.py
===
--- GenericSetup/utils.py (revision 68514)
+++ GenericSetup/utils.py (working copy)
@@ -625,6 +625,8 @@
else:
if prop_map.get('type') == 'boolean':
prop = str(bool(prop))
+elif isinstance(prop, str):
+prop = prop.decode('UTF-8')
elif not isinstance(prop, basestring):
prop = str(prop)
child = self._doc.createTextNode(prop)
[EMAIL PROTECTED]:~/src/CMF$
With this applied, Portàl (u'Port\xe0l'), which becomes 'Port\xc3\xa0l',
is displayed as Portà l ... Zope does input--output properties in utf-8,
but stores them in iso8859. Sigh.
Thanks for setting me right. What's the usefulness of getEncoding()?
As you say, exported files don't need to be other than utf-8 encoded.
I guess it just exists for historical reasons.
Might it be removed, or default'ed to utf-8? Do people already rely on it?
Well, I think I can wriggle out of most of my problems using
translation. And I'll try and write UTF-8 unit tests if nobody beats
me to it.
That would be great.
Hmm, by adding to an existing test suite, or creating a new one?
Cheers,
Yuppie
Thanks,
yves
___
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
