Am 20.08.2007, 21:12 Uhr, schrieb Andreas Jung <[EMAIL PROTECTED]>:
If you think this is a bug, please put it into a unittest (ZPT has
enough related tests which can serve as an example).
Will do. I've noticed that the newer templates have explicit
output-encodings and I thought that this mi
--On 20. August 2007 21:04:34 +0200 Charlie Clark <[EMAIL PROTECTED]>
wrote:
Am 20.08.2007, 20:53 Uhr, schrieb Dieter Maurer <[EMAIL PROTECTED]>:
This is caused by switching in the Zope3 (unicode based) ZPT
implementation
for Zope 2.10.
Yes, I know the cause and can see it in the traceba
Am 20.08.2007, 20:53 Uhr, schrieb Dieter Maurer <[EMAIL PROTECTED]>:
This is caused by switching in the Zope3 (unicode based) ZPT
implementation
for Zope 2.10.
Yes, I know the cause and can see it in the tracebacks. It's just a bit
weird that string formatting works fine but TALES string:
Charlie Clark wrote at 2007-8-20 14:41 +0200:
>I've noticed in Zope 2.10 that the behaviour of ZPT with regard to encoded
>values returned by a database has changed which leads to errors when using
>string: and non-ascii characters.
This is caused by switching in the Zope3 (unicode based) ZPT
Hi,
I've noticed in Zope 2.10 that the behaviour of ZPT with regard to encoded
values returned by a database has changed which leads to errors when using
string: and non-ascii characters.
ie.
/> will raise UnicodeDecodeError
for result = {'firstname':'charlie', 'surname':'Düsseldorf'}
but
