Zope 3

SomeWidget._getFormValue() often doesn't return a string

Bug #98333 reported by Björn Tillenius
2
Affects Status Importance Assigned to Milestone
Zope 3
Invalid
Medium
Unassigned
Zope 3 3.3

Bug Description

A lot of input widgets derive from SimpleInputWidget, which defines _getFormValue(). According to the docstring it should return a value suitable for use in a HTML form, which I interpret as it should be a string that can be uses as the HTML tag's value attribute.

The problem is that the default implementation deals only with the case where _toFieldValue(foo) returns a string. If you for example have a ChoiceInputWidget, with a vocabulary containing something else than strings, ChoiceInputWidget._getFormValue() will return a vocabulary item, instead of a token that can be used in a HTML form.

Widgets that derive from SimpleInputWidget and deal with non-string objects should override the _toFormValue() method in order to convert the object to a string that can be used in a HTML form. Note that a lot of code depend on the old behaviour, for example SingleDataHelper.

Tags: bug core
Revision history for this message
Stephan Richter (srichter) wrote :

Changes: submitter email, importance (medium => critical)

Revision history for this message
Christian Theune (ctheune) wrote :

Ok, given the method documentation isn't excellent, there is a
notice in the method "_toFormValue" which precedes "_getFormValue".

You can read there:

 This method is used in the default rendering of widgets that can
 represent their values in a single HTML form value. Widgets whose
 fields have more complex data structures should disregard this
 method and override the default rendering method (__call__).

So normally, this implementation should be fine. If you have non-simple values, like Choices, those widgets are supposed to
override __call__ which, according to the interface description, is:

    def __call__():
        """Render the widget."""

So, if you want to get the HTML widget representation, you got to
call this.

I vote for rejecting this bug. I'm not rejecting it directly, as
I'm not sure whether my understanding of the issue is right.

Revision history for this message
Björn Tillenius (bjornt) wrote :

Well, I wouldn't reject this bug based on your comment. What you're saying is that a lot of widgets, like ChoiceInputWidger, RadioWidget, use _getFormValue() even though they shouldn't, which is basically the same bug. Although I can't see how you came to that conclusion. The docstring you quoted says that widgets that can't represent their value in a single HTML form value shouldn't use that method. But a Choice and radio widget can do that, they map an object to a single token, which means that it should be able to use _getFormValue().

However, I'm not sure that this bug is worth fixing, due to the complexity of the problem. If you fix it, you have to change the (currently broken) semantics of some methods, which means that you might break other people widgets, since they might depend on the broken semantics. It's probably easier to create a new set of core widgets than to fix the existing ones.

Revision history for this message
Jim Fulton (jim-zope) wrote :

Changes: edited transcript, importance (critical => 3.3 Release)

Revision history for this message
Jim Fulton (jim-zope) wrote :

Status: Pending => Wontfix

SimpleInputWidget is a disaster. It makes implementing widgets
complex. :)

If you find a bug in a particular widget, please report it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.