[z3-five] Re: Extended characters in forms

[Philipp von Weitershausen]

Lennart Regebro wrote:
> On 5/27/05, yuppie <y.2005- at wcm-solutions.de> wrote:
> 
>>I still don't understand what's wrong with #3 (converting the form data
>>in EditView). Reimplementing the text widgets sounds like overkill.
> 
> It feels brittle (Mmm, god argumentation, eh), as it needs to work
> with whatever form data. And "reimplementing" probably means
> subclassing and overriding one method only. That way we pinpoint where
> the problem actually is.

Well, after some more insight into the problem, I can say this:

* I first thought that the problem were only related to TextWidget and 
TextAreaWidget, the only widgets related to unicode data. So, simply 
re-implementing those without trying to outsmart anything seemed like a 
sensible approach to me.

* Then I realized that other widgets need to be fixed up, too. If you 
have, for instance, a schema with an integer field, and a users falsely 
enters an "ä" into the field, the widget will have to redisplay itself 
with a non-ASCII character. So, even those fields need to be updated.

* Now, simply decoding form data in EditView is not that trivial because 
you don't know which form fields to deal with. Widgets generally decide 
their field names by themselves and complex widgets have subwidgets that 
have their own fields too. EditView can't possibly acquire that information.


I see two possible solutions:

a) EditView converts *everything* (except CGI variables coming from HTTP 
headers) in request.form to unicode, regardless of whether it's a form 
field or something else. One could argue that this is a pretty safe 
operation because request.form is likely to contain only form values 
anyway (apart from the above mentioned HTTP headers, etc.).\

b) We provide a mixin class FiveInputWidget that provides the necessary 
hooks for decoding widget values when reading from request.form and 
writing to the edit.pt/add.pt template. We re-implement every widget 
(except Bytes, probably) by creating classes inheriting from 
(FiveInputWidget, <originalwidget>).


I've just tested the first approach in my sandbox as it wasn't too hard 
to implement. It seems to work well, I can enter non-ASCII and 
non-latin-1 chars into an int field and get no UnicodeError but the form 
back with a validation error.

It's obviously an advantage of the first approach that it's easy to 
implement and short enough to be maintained well for upcoming Zope 3 
releases. We might be opening a can of worms with it though.

Thoughts?

Philipp