[z3-five] Re: Extended characters in forms

[Martijn Faassen]

Lennart Regebro wrote:
> On 5/23/05, Martijn Faassen <faassen at infrae.com> wrote:
> 
>>>>1. Force people to change the default encoing in site.py.
>>
>>This we cannot possibly recommend, as this is evil and will break other
>>stuff...
> 
> 
> Dieter came up with this:
> "sys.setdefaultencoding(some_appropriate_encoding_fitting_the_sites_encoding)"
> in "sitecustomize.py"
> 
> It's basically the same, but sitecustomize.py can be put anywhere in
> the python-path. The question is what the pythonpath is when it's
> sucked in, but I'm going to look at this. It's still not a very great
> solution, but at least a usable workaround.

I definitely do not recommend changing the default encoding... If you 
use this in a development environment, you're not going to be able to 
write portable code for instance. That this is even made to be 
configurable I consider to be fairly evil already, though for 
last-minute hacks it may be worthwhile..

I don't ever want this in Five itself though, as it can completely break 
code in unexpected places.

>>>>3. Do some magic so everything in these forms is converted to unicode
>>>>with the charset encoding in the for request.
>>>
>>>I tried #3, and you get problems with things that are for example
>>>lists of strings, so that didn't work.
>>
>>Hm, how did you try #3? I think #3 is most similar to what the Zope 3
>>publisher itself does, though I still need to go study it.
>  
> I tried making the editform and addform view-classes do this
> convertion. But, you get problems with things that are not pure
> strings, like lists and stuff. It should, I guess, be done in the
> Zope2 publisher, which is not a prospect I particularily look forward
> to trying at the moment.

No, that is indeed fairly scary. I guess another way it make a separate 
set of widgets (perhaps wrapping the original ones somehow) that do the 
conversion, and register those.

Regards,

Martijn