Combobox passes item label, not item value

[[email protected]…]

ComboBox? places (in some cases) wrong value to field named in HTML... Consider this:

<select name="foo" dojoType="combobox">
 <option value="1">aaa</option>
 <option value="2">bbb</option>
 <option value="3">ccc</option>
</select>

when form is read, foo's value is "aaa" or "bbb" or "ccc", when it should be 1,2 or 3. OF course, this behaviour should be configured behavior, because it is not wanted always. It places the "key" to foo_selected, but it's not good if we already have software to handle foo as key.

[[email protected]…]

fix for #730

[[email protected]…]

I've attached a patch to address this. I ran through the test_ComboBox.html tests and they all appeared to be fine.

regards

Matthew Flanagan

[[email protected]…]

Matthews patch seems to fix exactly this problem.

[bill]

Matthew, have you filed a CLA?

[[email protected]…]

yes I have.

[bill]

Merged in [4207]

[Tom Trenka]

Something in this patch hosed the ability to set the value of the widget programmatically (at first glance it would probably be the removal of the setting of the value of the textInputNode in setValue, but that might be something different).

I'm not sure what that did for the widget...but I would expect that .setValue would, in fact, set the value of the widget.

[bill]

setValue() does set the value but the meaning of "value" is somewhat confusing. In the text below, value is 1, not aaa

<select name="foo" dojoType="combobox">
 <option value="1">aaa</option>
 <option value="2">bbb</option>
 <option value="3">ccc</option>
</select>

Can you be more specific in describing what the issue is?

[Tom Trenka]

Sure.

It seems like the original widget didn't preserve the value attribute of the option list (if creating via an HTML select list), and that getValue and setValue returned and set (correctly) the label of the box. The applied patch removed the ability to set that correctly programmatically...

For instance, if one was writing a data submission based on an onClick event of something else, they would have (in previous versions), used the following to find out the current value of the widget:

var comboBoxValue=dojo.widget.byId("myComboBox").getValue();

...which would have been the label (since creating new entries for the box would have to, by the nature of the widget, be string values).

The applied patch killed that.

...My suggestion right now would be to roll it back and then throw out to the contributors what the actual purpose and values of the combobox should be. The reality is that because of the nature of the widget, the labels *are* the values, which makes it kind of weird or pointless to attempt to create the combo box out of a select element (since the select element has a value and a label for that value).

It might help to simplify the widget a little bit also...

(Sorry I didn't get back to you on this sooner Bill, I don't get emails from the bug list at all)

[[email protected]…]

You now have to use:

var comboBoxValue=dojo.widget.byId("myComboBox").getValue();
// get the displayed label
var comboBoxSelectedValue=dojo.widget.byId("myComboBox").getSelectedValue();

and the corresponding setValue(value) to set the value and setSelectedValue(label) to set the label. Maybe these functions should be renamed or atleast clearly documented.

The combobox widget is emulating a select element and in apps I've worked on the value is quite often different to the label. eg. value="some integer id of an object in a database" and label="human readable representation of the object".

There is no reason why application developers can't just use the "myComboBox_selected" value in their form processing or set both value and label to be the same.

I vote to keep the patch as is.

[bill]

The confusion here stems from the fact that ComboBox? can be used like HTML's <select>, where the possible input values are predefined, and there's a mapping from the displayed value "California" to a hidden value "CA"... or it can be used more like an <input> box, where the user can type in any string (in addition to selecting a predefined string), and there is no mapping. Arguing over whether the value is "California" or "CA" is just a word game.

It seems the patch effectively changed the names of setValue()/getValue() to setSelectedValue()/getSelectedValue(), which is bad merely for backwards-compatibility reasons. If we just rename the functions to setValue() and setHiddenValue(), will that fix things?

[bill]

Discussed with Alex and Tom and Mathew.

I reverted ComboBox? to function like in 0.2.2, i.e., like an <input> field. User can input an arbitrary value, or select a predefined value from a list. In the case below,

  <input dojoType="ComboBox" name="foo">

when you submit the form, the value of "foo" will be the displayed value, perhaps "Arizona", selected from the drop down list, or "England" (typed in manually).

Mathew will write a new widget called Select that functions like a <select>, with the nomenclature:

• "value" is the hidden value (ex: "AZ")
• "label" is the displayed value (ex: "Arizona").

The value submitted with the form is the hidden value (AZ not Arizona)

[[email protected]…]

First pass at Select widget.

Changes in following patch:

Changed ComboBox?.js to allow easier subclassing.

Added autocomplete="off" to input in HtmlComboBox?.html to prevent browser autocomplete showing for this widget.

New Select widget.

[[email protected]…]

dojo.widget.Select

[[email protected]…]

In the attachment to follow i've added: cleaned up typos in comments. Added fadeTime parameter. In Select widget I now force selection of item from option list. If not from list the input gets cleared onBlur.

[[email protected]…]

updated patch

[[email protected]…]

fix clearing of _selected value in combobox.

[bill]

Mathew, thanks for the patch! It all seems to work now. Closing this bug. Fixed in [4257].

[[email protected]…]

Updated patch cleans up some commented out code and fixes a reference to a null value in selectOption().

[[email protected]…]

updated patch

[[email protected]…]

removed patch to test_Select.html

[[email protected]…]

myWidget.setSelectedValue(value); does not update widget.

Say I have select-options with id/label pairs like {1,one}, {2,two} .. etc.. And I choose three.

Then I push button which has like this action: "myWidget.setSelectedValue("1");"

The value in myWidget still shows three.

[bill]

OK, new patch checked in as [4277].

Matthew - not sure about Joose's comment. I don't expect people to use setSelectedValue() w/ComboBox at all, but on the other hand it's reasonable to call setValue() on the Select widget and have the label updated, in addition to the value itself.

[(none)]

Milestone 0.3.1 deleted