Maurits van Rees wrote:
I have been busy with zope.formlib. See this weblog entry for some
This is Plone 3 with Zope 2.10.4 btw.
I discovered there is a difference between getting a value from the
request or from request.form when unicode is involved. From a pdb
This is the character Ã¿: a y with something extra on top. :) You can
see the same in a python prompt (I hope this is readable for
This gave me problems while using zope.formlib. In the method
zope.app.form.browser.textwidgets.TextWidget._getFormInput() the value
is fetched from the request and not request.form. So you get a
UnicodeDecodeError. In the weblog entry I mentioned I post some code
to guard against that in a setUpWidgets method in your own form page:
deliberately overwrite the variable in the request by the variable in
But what I want to ask here is: does something need to be fixed
somewhere in zope?
Should the value in request and request.form really be the same
always? Probably: always unicode?
Out of the box, Zope 2 won't deal with unicode in the request at all.
The values in both the request and request.form are both 8bit encoded
Now, the Zope3 form framework (incl. widgets) works with unicode only.
So when we wanted to make Zope3-style forms (first zope.app.form, then
zope.formlib) work in Zope 2 via Five, we either had to rewrite the
whole widget story, or introduce a little hack. We went with the little
hack, which takes request.form and decodes all values in it using the
appropriate encoding that's guessed from the request. This is done in
the same way that Zope 3 guesses the encoding.
That's why, when using Five's forms and *only then*, request.form will
I don't think we can move to unicode for the whole request (like Zope 3
does) at all times since that will likely break backward compatibility.
For instance, Archetypes is completely unaware of unicode IIRC...
get the value from the form instead of from the request?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -