--On 5. Januar 2006 21:12:08 +0100 Dieter Maurer <[EMAIL PROTECTED]> >>
- allowing only unicode textual content when calling macros, PyScript etc.definitely not.
I know that this is a hard requirement but it is an implicit requirement in Zope 3.
- converting non-unicode to unicode inside the TAL code using some encoding. The encoding could be specified as property of the called method (function properties) or object.Using a site encoding would probably be the best way (as done by e.g. Plone and Archetypes). Most sites use in fact a fixed encoding most of the time. At the places where a different encoding is used, it can be employed explicitely to convert to unicode.
A site encoding as default makes sense however there are situations when the encoding of a string from is different. E.g. when you deal with XMLHTTPRequest the browser expects an utf8 fragment which might conflict with an iso-8859-15 site-encoding. So there should be some mechanism to specify the encoding. For PyScript one could introduce a property to specify the encoding and methods of products I can imagine using function properties..and this is possibly something some must be solved on the TAL level.
As pointed out in private email ("charset negociation will not work"), the response charset has a significant impact on the charset used in form data sent back to the server. This may pose severe problems when the response charset is not the same as the site encoding (for textual form data).
This issue is connected to the ongoing/planned project to use the Z3 publisher in Zope 2.10. There will be a sprint at PyCon next month afaik...
Description: PGP signature
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )