-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, as mentioned in an earlier I was working on several encoding and webdav issues related to the Zope 3 ZPT integration in Zope 2.10. I backported the changes to the 2.10 branch. The changes include an in-place migration of all ZopePageTemplate instances to unicode (through a custom __setstate__() implemenetation). The migration code tries to sniff the encoding (it knows about ISO-8859-15 and UTF-8). A custom "preferred" encoding can be specified through the environment variable $ZPT_PREFERRED_ENCODING. I know that this migration is a big hammer (for a minor release) however I have not found another solution to deal with the outstanding issues in a reasonable and sane way. Therefore this migration must be tested. I am thinking about a beta release for 2.10.2 in order to get the stuff tested (I am also aware of the fact that most people don't test betas :-)) Thoughts? Objections? Andreas - -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFk81+CJIWIbr9KYwRAhF9AKCTgzufb/v5VUBxQvHNbL/1GcfcfACdG9Wo Ti+S/skHE79SXJfnjjI8gAM= =QKf4 -----END PGP SIGNATURE-----
Andreas Jung schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
as mentioned in an earlier I was working on several encoding and webdav issues related to the Zope 3 ZPT integration in Zope 2.10. I backported the changes to the 2.10 branch.
The changes include an in-place migration of all ZopePageTemplate instances to unicode (through a custom __setstate__() implemenetation). The migration code tries to sniff the encoding (it knows about ISO-8859-15 and UTF-8). A custom "preferred" encoding can be specified through the environment variable $ZPT_PREFERRED_ENCODING.
You should rather use config param default-zpublisher-encoding as a default, maybe with a fallback to (hopefully once obsolete) MANAGE_PAGE_CHARSET property.
I know that this migration is a big hammer (for a minor release) however I have not found another solution to deal with the outstanding issues in a reasonable and sane way. Therefore this migration must be tested. I am thinking about a beta release for 2.10.2 in order to get the stuff tested (I am also aware of the fact that most people don't test betas :-))
The sniffing could work however. Maybe we should have some warnings printed on console during zope start? Or even a "configureme" parameter which stopps zopes start when there is a non empty storage to migrate? Regards Tino
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On 28. Dezember 2006 20:43:34 +0100 Tino Wildenhain <tino@wildenhain.de> wrote:
Andreas Jung schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
as mentioned in an earlier I was working on several encoding and webdav issues related to the Zope 3 ZPT integration in Zope 2.10. I backported the changes to the 2.10 branch.
The changes include an in-place migration of all ZopePageTemplate instances to unicode (through a custom __setstate__() implemenetation). The migration code tries to sniff the encoding (it knows about ISO-8859-15 and UTF-8). A custom "preferred" encoding can be specified through the environment variable $ZPT_PREFERRED_ENCODING.
You should rather use config param default-zpublisher-encoding as a default, maybe with a fallback to (hopefully once obsolete) MANAGE_PAGE_CHARSET property.
The zpublisher-encoding usually must not have something to do with the encoding of ZPTs. The manage_page_charset would make sense since it can be specific to a particular subfolder. However we can't use acquisition with the phase where the migration happens (__setstate__()).
I know that this migration is a big hammer (for a minor release) however I have not found another solution to deal with the outstanding issues in a reasonable and sane way. Therefore this migration must be tested. I am thinking about a beta release for 2.10.2 in order to get the stuff tested (I am also aware of the fact that most people don't test betas :-))
The sniffing could work however. Maybe we should have some warnings printed on console during zope start? Or even a "configureme" parameter which stopps zopes start when there is a non empty storage to migrate?
Zope will raise an exception if it can't autodetect the encoding. However the current implementation does not store the changes back. So the original data in the ZODB remains untouched until the user clicks on 'Save'. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFlCHaCJIWIbr9KYwRAlSkAKDI8gpFGq4qnjFs9NRymg3tw5fElQCfXQSF y4sF5VjpOW0mU3qfSMNSfMg= =pDVE -----END PGP SIGNATURE-----
Andreas, The changes are not backward compatible, apparently. http://mail.zope.org/pipermail/cmf-tests/2006-December/003656.html http://mail.zope.org/pipermail/cmf-tests/2006-December/003657.html Stefan On 28. Dez 2006, at 14:58, Andreas Jung wrote:
I know that this migration is a big hammer (for a minor release) however I have not found another solution to deal with the outstanding issues in a reasonable and sane way. Therefore this migration must be tested. I am thinking about a beta release for 2.10.2 in order to get the stuff tested (I am also aware of the fact that most people don't test betas :-))
-- Anything that happens, happens. --Douglas Adams
In fact, the Zope trunk is a bit of a mess as well. http://mail.zope.org/pipermail/cmf-tests/2006-December/003658.html Stefan -- Anything that, in happening, causes itself to happen again, happens again. --Douglas Adams
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On 29. Dezember 2006 11:25:28 +0100 "Stefan H. Holek" <stefan@epy.co.at> wrote:
Andreas,
The changes are not backward compatible, apparently. http://mail.zope.org/pipermail/cmf-tests/2006-December/003656.html http://mail.zope.org/pipermail/cmf-tests/2006-December/003657.html
The implementation was in parts to rigid :-) The ZPT write() method now auto-converts to unicode and the constructor takes text/html as default for the 'content_type' parameter. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFlQf2CJIWIbr9KYwRArNlAJ4yf2TtaR30OUyHAspUi8zF4Ia/NACg0CLu O+3oA9qwI5FC0XJD+QvzCA8= =AiMB -----END PGP SIGNATURE-----
participants (3)
-
Andreas Jung -
Stefan H. Holek -
Tino Wildenhain