Opened 13 years ago

Closed 13 years ago

Last modified 11 years ago

#9091 closed enhancement (wontfix)

FilteringSelect: Why force item identity as field value?

Reported by: Jarrod Carlson Owned by:
Priority: high Milestone: tbd
Component: Dijit - Form Version: 1.3.0
Keywords: filteringselect Cc:
Blocked By: Blocking:


Referring back to #3347, was there a definite reason why a FilteringSelect? has to use the item identity as the value sent back to the server? It seems that the "keyAttr" attribute was pulled in favor of a call to store.getIdentity(item).

I've got a list of city, state, and country reference data (attached) where each entity has a unique ID, but the values I'd want sent to the server are not necessarily the ID. For example, for state, I would want the item's "cd" value sent back.

It seems a bit regressive to impose the identity as the value...

Fortunately, I control both my reference data and the form using it, so I have two possible solutions at this time:

1.) Sub-class the FilteringSelect? to provide a configurable "valueAttr" property, like FilteringSelect? used to have.

2.) Create separate ItemFileReadStore? instances for each of the city, state, and country collections.

The second option sounds like a shame, since it would make it hard to use the reference features of ItemFileReadStore?, linking a city, state, and country together.

I would just make the ID of each item the value I want to send back to the server, but that won't work because the state of California and the country of Canada would share the same ID, causing a conflict.


Attachments (2)

locations.js (29.2 KB) - added by Jarrod Carlson 13 years ago.
FilteringSelect.js (4.5 KB) - added by Jarrod Carlson 13 years ago.
Subclass of FilteringSelect?

Download all attachments as: .zip

Change History (5)

Changed 13 years ago by Jarrod Carlson

Attachment: locations.js added


Changed 13 years ago by Jarrod Carlson

Attachment: FilteringSelect.js added

Subclass of FilteringSelect?

comment:1 Changed 13 years ago by bill

keyAttr is limited to one key, where getIdentity() can be composed (in your example) of a combination of country, city, and state, so in that sense getIdentity() is superior to keyAttr. That's why the change was made.

It sounds like you are running into problems since you are trying to use "cd" as the identity, but in fact it isn't unique. Had the same problem with the i18n demo and ended sticking in a field into the data that was truly unique, but I suppose the better way is to extend your data store to have a valid getIdentity() etc. call. I'd suggest subclassing your data store to do that.

comment:2 Changed 13 years ago by bill

Resolution: wontfix
Status: newclosed

Anyway, I'm going to mark this as wontfix since I think there's a simple "workaround" as I outlined above.

If you are declaring in markup, should be as simple as adding <script type="dojo/method" event="getIdentity"> and <script type="dojo/method" event="fetchItemByIdentity"> overrides, each one just one line long.

comment:3 Changed 11 years ago by bill

Component: DijitDijit - Form
Note: See TracTickets for help on using tickets.