[Zope-dev] Re: [Zope 2.10/ZPT] Fixes for encoding and webdav issues

Andreas Jung lists at zopyx.com
Mon Dec 18 06:11:41 EST 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



- --On 17. Dezember 2006 18:40:03 +0100 Andreas Jung <lists at zopyx.com> wrote:
>>
>> That is dangerous, because a page template may be called without being
>> the "main" driver for a request;  the response encoding should be used,
>> if already set, rather than the value set on the template.
>
> Ok, you're right. Is there an reliable way to distinguish between
> a direct call and a non-direct call?

I reverted the change. The __call__() and pt_render() method now
returns the rendered PT *always* as unicode string. It is now up to the 
ZPublisher or the template itself to set the 'charset' as needed.

>
>>
>>> WebDAV: the PUT factory was using the write() method to store uploaded
>>> content. This method wasn't aware of the output encoding. PUT() now
>>> uses pt_edit(). This implies that the uploaded content must have the
>>> same encoding as the output encoding. Means: when you create a ZPT with
>>> encoding UTF-8 you can't upload new content with a different encoding.
>>> This is a slightly different behavior from older Zope versions and might
>>> break backward compatibility. Anyone having such a usecase? One might
>>> check in addition for the 'encoding' attribute inside the XML preamble
>>> or for the 'charset' property inside a <meta http-equiv="content-type"
>>> ..> tag for HTML documents.
>>
>> PUT should always extract the encoding from the upload request, and use
>> it to decode the template to unicode for storage.
>
> This works already. However there will be cases when the code can't
> autodetect an encoding.
>
>> While saving that
>> encoding as the "outpout encoding" for a newly-created template is
>> reasonable, modifying the "output encoding" for an existing template is
>> riskier.
>
> Newly created content-type is still an open point..look as if I have to
> write a bunch of unittests for all edgecases.
>

I've added a bunch of unittest and some logic to cover all edgecases when 
editing a ZPT either through-the-web or through WebDAV/FTP.

The output_encoding is now used in two places: for the ZPT edit form and 
when accessing a ZPT through WebDAV/FTP. The output_encoding is determined
by the content-type and the content itself. For text/xml the output_encoding
is always set to utf-8. For text/html the ZPT engine checks for a
<meta http-equiv="content-type" ...> header and tries to extract the 
'charset'. If it is not available the output_encoding will be iso-8859-15.

Before merging the changes must be tested with CMF.

Andreas



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFFhndtCJIWIbr9KYwRAtnvAJ45QnO2IhCNKwiyFhyskgHA5QbXmgCeOs/Z
gfwjBTyds+MYaT6Pf6UFUhg=
=itbR
-----END PGP SIGNATURE-----



More information about the Zope-Dev mailing list