Display views show a terms value while edit views show it's token

[Gaudenz Steinlin]

In the update method of RadioWidget and Checkbox widget the token of a term is assigned to the variable that gets shown in the input form. But the "displayValue" method of SequenceWidget, which is a parent class of all these widgets returns the value of a term for display. This leads to the situation that in the edit form the token is displayed while in the non edit view the value is shown.

This only happens if no title for the term is defined. If the term is titled, the right thing (ie. show the titlel) is done in both views.

IMHO both edit and display views should show the same string. I don't particularly care if it's the value or the token. There might be arguments either way. I have a weak preference to show the token.

[Roger Ineichen (rogerineichen)]

I didn't take a closer look at the code but it looks correct to me if the value get used for display or title for title tokenized terms. Because a token is not or not allways human readable for display in HTML. A token is only an internal representation which allways makes sure it can be used as POST value. This token is important for values which can't get used directly in forms e.g. a python object etc.

[Stephan Richter (srichter)]

I agree with the original report that the behavior is inconsistent. As Gaudenz mention, the choice for going with the token versus the value is tough. A value is not always a string and can lead to weird representations if it is a custom Python object while a token is not always readable (as Roger mentioned).

But then, if your term does not provide a title, you deserve some pain. :-) So I think going with the value is the right thing to do here, since it will work for all simple Python types well.

See r123936.

[David Glick (davisagli)]

Your change to unicode(term.value) will break with a UnicodeDecodeError if the value is a non-ASCII encoded string.

[Stephan Richter (srichter)]

On Wednesday, January 04, 2012 05:35:30 PM David Glick wrote:
> Your change to unicode(term.value) will break with a UnicodeDecodeError
> if the value is a non-ASCII encoded string.

Yeah, you are right. I was thinking about potential issues like that. I guess
I just ignore non-encodable strings.

Regards,
Stephan
--
Entrepreneur and Software Geek
Google me. "Zope Stephan Richter"

[Stephan Richter (srichter)]

Fixed in r124259.