Florent Guillaume 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 template.
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."
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
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests