Zope 2 will hopefully use the Zope 3 ZPT implementation in the future.
Since the ZPT implementation will use unicode internally we have to deal
in some way with non-unicode in Zope 2 installations. We currently can not require that every callable object return unicode. Mixing unicode ZPTs with non-unicode content will definitely lead to UnicodeDecodeErrors. I have some ideas I would like to discuss (especially how they fit into the current Zope 3 implemenation).

- better handling of UnicodeDecodeError: these errors will basically show up
 using tal:content and tal:replace. Path expressions or Python expression
 returning non-unicode content will be implicitly converted to Unicode
 possibly raising UnicodeDecodeErrors. Is there any chance in improving the
 error handling? means..trapping the error and presenting an error message
 showing the path expression or python expression causing the failure?

- implicit conversion of non-unicode content to unicode. In case of a path
 expression "context/someobject/method" either the method could provide a
 function attribute (method.output_encoding or so) specifiy the encoding
 of the result. If we would default to some reasonable encoding. We could
 also check for someobject.output_encoding as fallback. Dealing with python
 expressions like "python: context.someobject.method()" seems to be more
 complex because it likely requires somekind of parser to get hold of the
 'method' or 'someobject' (I am not sure if there is already some code
 in TAL for this).

I've never had a closer look at the TAL code to be able to make a decision if these issues can be resolved in a sane way. Any comments?


Attachment: pgpXF9R34VPRQ.pgp
Description: PGP signature

ZPT mailing list

Reply via email to