zpt encoding and content-type
hight all i use PageTemplateFile in my python product. now I'm wondering if there is some way to redefine the content-type and the encoding of the response object in the file i tried the suggestion on zopelabs, to set it like the following somewhere in a tal:replace:: python:request.response.setHeader ... but this does not affect my response. it seems that PageTemplateFile always uses text/xml if an xml PI is on the top of the source file. It sniffs the content-type from the PI. what I basically want to do is, to define the encoding in the xml PI (e.g <?xml version="1.0" encoding="iso-8859-1"?>) so that I dont get unicode conversion errors (ascii out of range ...) when the file is read but this results in a text/xml content type tia, bernd
Bernd Dorn wrote at 2003-10-22 11:07 +0200:
i use PageTemplateFile in my python product. now I'm wondering if there is some way to redefine the content-type and the encoding of the response object in the file
i tried the suggestion on zopelabs, to set it like the following somewhere in a tal:replace::
python:request.response.setHeader ...
I should give you an "AttributeError", as "response" needs to be spelled "RESPONSE".
but this does not affect my response.
There has been a bug in earlier PageTemplate versions which were overriding a given "Content-Type". This bug should be fixed in Zope 2.6.2.
it seems that PageTemplateFile always uses text/xml if an xml PI is on the top of the source file. It sniffs the content-type from the PI.
what I basically want to do is, to define the encoding in the xml PI (e.g <?xml version="1.0" encoding="iso-8859-1"?>) so that I dont get unicode conversion errors (ascii out of range ...) when the file is read but this results in a text/xml content type
I do not think that the XML declaration is generated automatically. You must do it which the correct "encoding". When you know that you are strictly working in an "iso-8859-1" context, you can set Python's default encoding to "iso-8859-1" ("sys.setdefaultencoding") in your "sitecustomize.py" file. Read the "site.py" documentation, for details. Be warned, that some of the Python Gods do not like this feature and my drop it sometimes in the future. Otherwise, ensure that all non-ASCII strings are unicode strings and set the correct "Content-Type" header (including the correct charset). In this case, ZPublisher should automatically encode the result correctly. Search for "unicode support" on Zope.org. Dieter
Dieter Maurer wrote:
Bernd Dorn wrote at 2003-10-22 11:07 +0200:
i use PageTemplateFile in my python product. now I'm wondering if there is some way to redefine the content-type and the encoding of the response object in the file
i tried the suggestion on zopelabs, to set it like the following somewhere in a tal:replace::
python:request.response.setHeader ...
I should give you an "AttributeError", as "response" needs to be spelled "RESPONSE".
this is not true, because the response object is in the attribute 'response' of the request, it is just called RESPONSE if it is catched as a kw argument
but this does not affect my response.
There has been a bug in earlier PageTemplate versions which were overriding a given "Content-Type".
This bug should be fixed in Zope 2.6.2.
it seems that PageTemplateFile always uses text/xml if an xml PI is on the top of the source file. It sniffs the content-type from the PI.
what I basically want to do is, to define the encoding in the xml PI (e.g <?xml version="1.0" encoding="iso-8859-1"?>) so that I dont get unicode conversion errors (ascii out of range ...) when the file is read but this results in a text/xml content type
I do not think that the XML declaration is generated automatically. You must do it which the correct "encoding".
When you know that you are strictly working in an "iso-8859-1" context, you can set Python's default encoding to "iso-8859-1" ("sys.setdefaultencoding") in your "sitecustomize.py" file. Read the "site.py" documentation, for details. Be warned, that some of the Python Gods do not like this feature and my drop it sometimes in the future.
Otherwise, ensure that all non-ASCII strings are unicode strings and set the correct "Content-Type" header (including the correct charset). In this case, ZPublisher should automatically encode the result correctly. Search for "unicode support" on Zope.org.
Dieter
thanks for your responses is now figured out, that this statement in a tal:define attribute works xxx python:request.response.setHeader('content-type','text/html') but if an xml declaration is given in the source, the content-type is always text/xml in the output, because PageTemplateFile sniffs and sets the content type after rendering the content i think the problem for me is not actually the encoding of the pt file, it is the encoding of the attributes of zope objects (e.g. title), which i always have to convert to unicode if a non ascii charecter is in and if the attribute is not a unicode one. only if i set the encoding in the xml declaration it works without converting , but then the result is also xml, what is not what i want, because browsers display the result differently then. it would be convinient if PageTemplateFile could be instantiated with a given encoding and result content-type like in the PageTemplate of the ZMI changing the default encoding of python is also not possible, because this affects 4 other zope instances,hm i think i gonna subclass PageTemplateFile and override the default behaviour either way, thanks for your responses, bernd
Bernd Dorn wrote at 2003-10-23 12:33 +0200:
Dieter Maurer wrote:
Bernd Dorn wrote at 2003-10-22 11:07 +0200:
i use PageTemplateFile in my python product. now I'm wondering if there is some way to redefine the content-type and the encoding of the response object in the file
i tried the suggestion on zopelabs, to set it like the following somewhere in a tal:replace::
python:request.response.setHeader ...
I should give you an "AttributeError", as "response" needs to be spelled "RESPONSE".
this is not true, because the response object is in the attribute 'response' of the request, it is just called RESPONSE if it is catched as a kw argument
You are right: you can use both "response" as well as "RESPONSE".
...
Otherwise, ensure that all non-ASCII strings are unicode strings and set the correct "Content-Type" header (including the correct charset). In this case, ZPublisher should automatically encode the result correctly. Search for "unicode support" on Zope.org.
... the problem for me is not actually the encoding of the pt file, it is the encoding of the attributes of zope objects (e.g. title), which i always have to convert to unicode if a non ascii charecter is in and if the attribute is not a unicode one.
only if i set the encoding in the xml declaration it works without converting , but then the result is also xml, what is not what i want, because browsers display the result differently then.
Since Zope 2.6, properties can have unicode types (ustring, ulines, ...). In this case, Zope converts for you "at the boundaries". You should find some documentation on Zopes Unicode support (--> zope.org). It should also explain why it is good to encode/decode only at the boundaries. -- Dieter
participants (2)
-
Bernd Dorn -
Dieter Maurer