[Zope-CMF] [dev] encoding of tool settings / CMFSetup
Hi! Is there any need to support tool settings with other encodings than utf-8 (and ascii as a subset of utf-8)? AFAICS there's not even a need for utf-8: Most settings are not visible for users and those that are (like title and description of Actions and type infos) can contain an ascii i18n message id. But supporting utf-8 would not cost us much extra and might help people who don't use translations. See also http://www.zope.org/Collectors/CMF/292 For CMFSetup/GenericSetup this would mean: All 'encoding' parameters, attributes and methods could be removed. The XML files are anyway utf-8 encoded, so there would not be any need to convert strings from one encoding to an other. (At the moment a hardcoded ascii encoding is passed around everywhere.) 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] 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 efge - CMFSetup: provide non-ascii im- and exports, [Accepted] http://www.zope.org/Collectors/CMF/292 - CMFSetup doesn't correctly detect DCWorkflow on export, [Accepted] http://www.zope.org/Collectors/CMF/298 jens - FSPropertiesObject.py cannot handle multiline input for lines, text attributes, [Accepted] http://www.zope.org/Collectors/CMF/271 mhammond - Windows DevelopmentMode penalty in CMFCore.DirectoryView, [Accepted] http://www.zope.org/Collectors/CMF/366 mj - CMFSetup doesn't correctly detect DCWorkflow on export, [Accepted] http://www.zope.org/Collectors/CMF/298 Pending / Deferred Issues - Debuggable scripts, [Deferred] http://www.zope.org/Collectors/CMF/194 - CMFCalendar weekday locale issue, [Pending] http://www.zope.org/Collectors/CMF/237 - 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 - PortalCatalog.ZopeFindAndApply should probably also search in opaqueItems, [Pending] http://www.zope.org/Collectors/CMF/296 - WorkflowTool should recurse into opaqueItems, [Pending] http://www.zope.org/Collectors/CMF/297 - add External Methods to workflow script handling, [Pending] http://www.zope.org/Collectors/CMF/329 - 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 Pending / Deferred Features - Favorite.py: queries and anchors in remote_url, [Pending] http://www.zope.org/Collectors/CMF/26 - Allow flexible date editing in Event.py (CMFCalendar), [Pending] http://www.zope.org/Collectors/CMF/40 - DefaultDublinCore should have Creator property, [Pending] http://www.zope.org/Collectors/CMF/61 - Make changeFromProperties accept sequences too, [Pending] http://www.zope.org/Collectors/CMF/99 - 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 - Permissions in PortalFolder: invokeFactory(), [Pending] http://www.zope.org/Collectors/CMF/175 - 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 - Action._listsActions() should be more safe, [Pending] http://www.zope.org/Collectors/CMF/253 - Expose Document text_format metadata, [Pending] http://www.zope.org/Collectors/CMF/285 - customization of type of homefolder on creation, [Pending] http://www.zope.org/Collectors/CMF/288 - Allow contentFilter to use review_state, [Pending] http://www.zope.org/Collectors/CMF/294 - CMFTopic Does Not Cache, [Pending] 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, [Pending] 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 ___ 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: [dev] encoding of tool settings / CMFSetup
Hi Yuppie, 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. Florent AFAICS there's not even a need for utf-8: Most settings are not visible for users and those that are (like title and description of Actions and type infos) can contain an ascii i18n message id. But supporting utf-8 would not cost us much extra and might help people who don't use translations. See also http://www.zope.org/Collectors/CMF/292 For CMFSetup/GenericSetup this would mean: All 'encoding' parameters, attributes and methods could be removed. The XML files are anyway utf-8 encoded, so there would not be any need to convert strings from one encoding to an other. (At the moment a hardcoded ascii encoding is passed around everywhere.) 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 -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +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: [dev] encoding of tool settings / CMFSetup
Hi Florent! 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 framework. Right? 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: [dev] encoding of tool settings / CMFSetup
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 RD +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
