Andreas Jung wrote:
No. Imagine a PythonScript that returns a unicode string. The ZPublisher
converts the unicode string to latin1 (zpublisher_default_encoding). Most
browsers will default Latin1 when they can't find the charset in the
content-type header. When you configure the ZPublisher to
--On 4. Januar 2006 11:23:09 +0200 Chris Withers [EMAIL PROTECTED]
wrote:
Andreas Jung wrote:
No. Imagine a PythonScript that returns a unicode string. The ZPublisher
converts the unicode string to latin1 (zpublisher_default_encoding). Most
browsers will default Latin1 when they can't
As you might know I worked on the integration of the Zope 3 ZPT
implementation for Zope 2.10. Before commiting the changes to the trunk I
would like discuss my approach for Zope 2.10
- the ZopePageTemplate and PageTemplateFile classes will be replaced
with wrapper classes around
Summary of messages to the zope-tests list.
Period Wed Jan 4 12:01:01 2006 UTC to Thu Jan 5 12:01:01 2006 UTC.
There were 8 messages: 8 from Zope Unit Tests.
Tests passed OK
---
Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux
From: Zope Unit Tests
Date: Wed Jan 4 21:02:51 EST
--On 5. Januar 2006 12:47:20 +0100 Andreas Jung [EMAIL PROTECTED]
wrote:
As you might know I worked on the integration of the Zope 3 ZPT
implementation for Zope 2.10. Before commiting the changes to the trunk I
would like discuss my approach for Zope 2.10
I forgot to mention a major
Andreas Jung wrote:
ToDo: in-place conversion of persistent ZPT instance through setstate()
or so...
Could we avoid doing things in __setstate__ please? It imposes a runtime
cost that doesn't disappear.
I'd rather have a one-time update method that trawls the database, like is
done for
--On 5. Januar 2006 17:36:45 +0100 Florent Guillaume [EMAIL PROTECTED] wrote:
Andreas Jung wrote:
ToDo: in-place conversion of persistent ZPT instance through setstate()
or so...
Could we avoid doing things in __setstate__ please? It imposes a runtime
cost that doesn't disappear.
I'd
Florent Guillaume wrote:
Andreas Jung wrote:
ToDo: in-place conversion of persistent ZPT instance through
setstate() or so...
Could we avoid doing things in __setstate__ please? It imposes a runtime
cost that doesn't disappear.
I'd rather have a one-time update method that trawls the
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Windows 2000
zc-bbwin2.
Buildbot URL: http://buildbot.zope.org/
Build Reason: changes
Build Source Stamp: 2603
Blamelist: tim_one
BUILD FAILED: failed failed slave lost
sincerely,
-The Buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Windows 2000
zc-bbwin6.
Buildbot URL: http://buildbot.zope.org/
Build Reason: changes
Build Source Stamp: 2609
Blamelist: andreasjung,efge,hdima,jim,oestermeier,tim_one
BUILD FAILED: failed failed slave lost
sincerely,
-The Buildbot
Andreas Jung wrote at 2006-1-5 13:39 +0100:
...
I forgot to mention a major point: compatibility.
When a ZPT is internally stored a unicode string then content returned by
methods called through the ZPT will be implicitly converted to unicode.
This will definitely raise UnicodeDecodeErrors. So
Andreas Jung wrote at 2006-1-5 17:44 +0100:
...
I'd rather have a one-time update method that trawls the database, like
is done for Python Scripts recompiling for instance. Or I can call it
myself in my upgrade procedures on the exact objects I know will need
updates.
I've implemented the
12 matches
Mail list logo
