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