[Zope-CMF] Re: [RFC] [Patch] GenericSetup and encodings

[yuppie]

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