FilteringSelect: Why force item identity as field value?

[Jarrod Carlson]

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.

Suggestions?

[Jarrod Carlson]

locations

[Jarrod Carlson]

Subclass of FilteringSelect?

[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.

[bill]

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.