Hi!
Laurence Rowe wrote:
On 2 March 2011 11:29, yuppiey.2...@wcm-solutions.de wrote:
Laurence Rowe wrote:
On 2 March 2011 10:00, yuppiey.2...@wcm-solutions.dewrote:
Martin Aspeli wrote:
I don't know what setPageEncoding() does, though.
It sets a response Content-Type header with the
Am 04.03.2011, 08:58 Uhr, schrieb yuppie y.2...@wcm-solutions.de:
If we always send UTF-8, their current implementation doesn't make much
sense to me. Don't know if we really should try to fall back to all the
charsets mentioned in Accept-Charset. But at least we should *always*
try UTF-8
Charlie Clark wrote:
Am 04.03.2011, 08:58 Uhr, schrieb yuppiey.2...@wcm-solutions.de:
If we always send UTF-8, their current implementation doesn't make much
sense to me. Don't know if we really should try to fall back to all the
charsets mentioned in Accept-Charset. But at least we should
Hi again!
Based on the discussion I modified my proposal:
- Products.Five.browser.decode should be marked as deprecated. It
implements charset negotiation without making sure the 'Vary' header is
set correctly. Fixing this will cause other caching issues.
- The setPageEncoding() function
On 2 March 2011 11:29, yuppie y.2...@wcm-solutions.de wrote:
Laurence Rowe wrote:
On 2 March 2011 10:00, yuppiey.2...@wcm-solutions.de wrote:
Martin Aspeli wrote:
I don't know what setPageEncoding() does, though.
It sets a response Content-Type header with the first charset
processInputs
Hi!
ZPublisher.Publish and zope.publisher.publish process form inputs
differently. Zope 2 returns encoded strings unchanged if no converters
are specified. zope.publisher converts encoded strings to unicode.
One major reason why zope.formlib and z3c.form can't be used directly in
Zope 2 is
Hi,
On 2 March 2011 08:43, yuppie y.2...@wcm-solutions.de wrote:
Hi!
ZPublisher.Publish and zope.publisher.publish process form inputs
differently. Zope 2 returns encoded strings unchanged if no converters
are specified. zope.publisher converts encoded strings to unicode.
One major reason
Hi Martin!
Martin Aspeli wrote:
- After traversal and before calling the object
ZPublisher.Publish.publish should figure out if the object expects
zope.publisher behavior. Either we use a new interface for this or we
use zope.publisher.interfaces.browser.IBrowserPage: AFAICS in Zope 2
land
Am 02.03.2011, 12:29 Uhr, schrieb yuppie y.2...@wcm-solutions.de:
getPreferredCharsets()[0] always returns 'utf-8' **if** UTF-8 is
accepted.
If 'utf-8' is not in getPreferredCharsets(), it is not very likely that
the browser speaks UTF-8 and processInputs will not even try to decode
with
Hi Charlie!
Charlie Clark wrote:
Am 02.03.2011, 12:29 Uhr, schrieb yuppiey.2...@wcm-solutions.de:
getPreferredCharsets()[0] always returns 'utf-8' **if** UTF-8 is
accepted.
If 'utf-8' is not in getPreferredCharsets(), it is not very likely that
the browser speaks UTF-8 and processInputs
On Wed, Mar 2, 2011 at 9:43 AM, yuppie y.2...@wcm-solutions.de wrote:
Does that make sense? I guess that kind of change should only be made on
the trunk.
Sounds all good to me, and yes this should be Zope trunk only.
Hanno
___
Zope-Dev maillist -
11 matches
Mail list logo