small bugfix for MultiListFields checked in
Clemens Robbenhaar <crobbenhaar-S0/[email protected]> Mon, 05 Jul 2010 23:36:03 +0200
| Newsgroups | gmane.comp.web.zope.formulator.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi *, (gently blowing the dust from the list) I just checked in a bugfix for Formulator. As I have not been active for quite a long time, I though I better tell everyone what this is about, lest you wonder what the heck this change comes from. A few days ago Philipp Lacovich from the WU Vienna noticed me about a problem he got reported from another guy there (I forgot his name, sure Philipp can tell you who). The problem is with MultiListFields/MultiCheckBoxFields in unicode mode if rendering the fields with values coming in from the request. (This will e.g. happen if showing the form with validation errors after submitting the form - usually one wants to show the values the user entered here.) The problem happens if the values (i.e. not the labels) from these fields contain non-ascii characters. These values have not been converted to unicode, because the Field._get_default method only converts string values to unicode. Selecting several values make them come in as a list of strings, however. Depending on the python version this causes different symptoms. When checking if the values are in the list of allowed values for that field, python compares plain values to unicode values. With python2.6 (the version the current buildout on the trunk seems to support) this just causes a warning message in the logfile that the conversion failed, and returns False for the comparison. As a result the values in the fields get lost. With python2.4 (which is the version in use at WUW) an Unicode error is raised, however, resulting in an error page. Also while being at it I corrected a minor problem with the "convert_unicode" helper, who assumed to convert from "utf-8" always. The changes have been checked in as: revision 43316 on the Formulator-1.11 branch revision 43317 on the Formulator-1.12 branch revision 43318 on the trunk In case You suspect this might break something else or the fix gets in your way in some other way, it should be easy to revert these changes. Please contact the WUW folks to sort out a different solution for their issue in this case. I did not cut a new release just for the fix as I thought it would not show decent manners if I do so without asking everybody else about it. I will be offline (traveling) from Wednesday till the end of the week. If so far nobody throws in a veto I would like to cut a 1.11.8 release from the corresponding branch at least, however. Cheers, Clemens