On 15 Sep 2005, at 17:16, yuppie wrote:
Is there any need to support tool settings with other encodings
than utf-8 (and ascii as a subset of utf-8)?
I think there is. Take for instance the portal property "title".
It could very well be a non-ascii string, and contain accents. It
could be (a) an str encoded in some charset, or (b) unicode.
If (a), then we can assume the charset specified by the portal
property "default_charset" (with a default of "" meaning "latin-9"
maybe), and re-encode to unicode before passing it to the export
Export is thus not a problem.
When importing though, we'll have a non-ascii utf-8 string and we
have to decide if we're going to decode it to unicode or re-encode
it to the default_charset. This has to be done according to the
property type (for properties). For non-properties, I guess we
could punt and say tough luck.
But I agree that there's no need to pass around an "encoding"
attribute, XML is utf-8 and that's it.
The 'encoding' attribute specifies the site configuration encoding,
not the XML encoding. Quoting from the getEncoding() interface:
"Get the encoding used for configuration data within the site."
Ah ok. I haven't really looked at the code.
But looking at your examples the handlers should be able to get the
encoding information from their context if they want to support
special encodings. So there is at least no need to support
encodings in the framework. Right?
Yes that's my position, they should get it from the context. That
means setting the portal properties as one of the first steps during
import, but it's probably not a problem.
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests