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 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."

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

--
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
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to