Zope 2 will hopefully use the Zope 3 ZPT implementation in the future. Since the ZPT implementation will use unicode internally we have to dealin 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?
Description: PGP signature
_______________________________________________ ZPT mailing list ZPT@zope.org http://mail.zope.org/mailman/listinfo/zpt