#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: |
Description
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?
Attachments (2)
Change History (5)
Changed 12 years ago by
Attachment: | locations.js added |
---|
comment:1 Changed 12 years ago by
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 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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 10 years ago by
Component: | Dijit → Dijit - Form |
---|
locations