Opened 14 years ago

Closed 7 years ago

#7279 closed defect (patchwelcome)

FilteringSelect does not correctly set value when two or more options have the same display (but different values)

Reported by: thecatwhisperer Owned by:
Priority: high Milestone: 1.13
Component: Dijit - Form Version: 1.1.1
Keywords: FilteringSelect Cc: [email protected]
Blocked By: Blocking:


FilteringSelect? that contains 2 or more items with the same display value (ie: two options of "R. Smith") but different values (specified by the store's identifier) cause the FilteringSelect? to always select the first value it finds.

This happens consistently in IE6+ & FF2+.

We do believe there is precedent for multiple items with the same display value (ie: individual names).

When a user initially selects the item, the correct item is identified, but some time after the "_callbackSetLabel" method is called in FilteringSelect?, the value is changed to the first item with the selected display value found.

For example:

I have a Filtering Select with the following data:

    {name: "J. Smith", key: 1},
    {name: "R. Findley", key: 2},
    {name: "R. Findley", key: 3},
    {name: "F. Clark", key: 4}

The store is set with the identifier as "key".

The Filtering select correctly lists the items in order.

When I select the 2nd "R. Findley", and debug, it does select the one with the key of "3", however after the "_callbackSetLabel" method is called, the field reports its value as "2".

It seems as if it is searching based on name, rather than the proscribed identifier.

I've taken a look around and could not find an example of this working properly.

Change History (6)

comment:1 Changed 14 years ago by Douglas Hays

Owner: set to haysmark

comment:2 Changed 14 years ago by bill

Milestone: tbdfuture

Hmm, given that a user can simply type in a value to FilteringSelect, without even using the drop down list, it seems like a bad app design to have multiple items with the same display value. Actually, that seems like a bad design in any case, but at least with dojox.form.DropDownSelect? there's no chance of ambiguity due to the user typing in a value manually.

comment:3 Changed 14 years ago by thecatwhisperer

You assume that the app designer has complete control over what users create, and that is not always the case. The specific example I mentioned is a case where this issue is not only possible, but likely to occur.

There are cases when you want to select a user, and the users could have the same name. You could also be dealing with imported data, of which the app designer may not have complete (if any) control over.

The simple fact is, that the control does not work right, you can blame it on the user (or me) for creating a case where the control contains two elements with the same name, or recognize the fact that the control SHOULD select the item based on its identifier (value) not its display, since that is what is being sent to the server.

I don't disagree that having two items that appear to be the same to the user is not desirable, but that's not what this bug was entered for. Setting it to "future" because you don't think the user should design in a specific way is well... bad design ;) We are already in the process of changing how we display users, as we understand that it was a bad decision to us the user's name instead of the username. That still doesn't fix this defect in the FilteringSelectBox?.

As for suggesting something from the Dojox library, many companies (mine included) restrict their developers from using experimental code in projects. Dojox is experimental, in that it can change without warning at any time.

comment:4 Changed 11 years ago by bill

Component: DijitDijit - Form

comment:5 Changed 7 years ago by bill

Owner: haysmark deleted
Status: newassigned

comment:6 Changed 7 years ago by dylan

Milestone: future1.12
Resolution: patchwelcome
Status: assignedclosed

Given that no one has shown interest in creating a patch in the past 5+ years, I'm closing this as patchwelcome.

Note: See TracTickets for help on using tickets.