#9354 closed defect (fixed)
FIlteringSelect XmlStore labelAttr problem
| Reported by: | Ian Fouls | Owned by: | bill |
|---|---|---|---|
| Priority: | high | Milestone: | 1.4 |
| Component: | Dijit - Form | Version: | 1.3.0 |
| Keywords: | FilteringSelect XmlStore | Cc: | ianfoulds@…, Jared Jurkiewicz |
| Blocked By: | Blocking: |
Description (last modified by )
In version 1.3, when a FilteringSelect uses an XmlStore with a label and data pair, the label is shown correctly in the dropdown but the text box is poulated with the data item instead of the label value.
In the example the 'id' attribute is the hidden 'data' value and the 'name' attribute is the label to be displayed to the user. The FilteringSelect? initially shows the 'id' attribute in the text box, clicking the down arrow shows the correct list of 'name' attributes, selecting an item from the list populates the text box with an 'id' and not 'name'.
<html>
<div dojoType="dojox.data.XmlStore" jsId="contentTypesStore" keyAttribute="id" label="name" url="/testfs.xml"></div>
<input dojoType="dijit.form.FilteringSelect" store="contentTypesStore" searchAttr="name" labelAttr="name" id="cse_content_type_id" name="cse_content_type_id" value="1">
</html>
<xml>
<?xml version="1.0" encoding="UTF-8" ?>
<content_types>
<content_type>
<id>1</id>
<type>static</type>
<name>Text and Images</name>
<default_css_class>content</default_css_class>
<display_handler>/cms/display_handlers/static_content.php</display_handler>
<edit_handler>/cms/edit_handlers/staticEditor.class.php</edit_handler>
</content_types>
</xml>
Many thanks for your help.
Attachments (2)
Change History (11)
Changed 10 years ago by
| Attachment: | testfs.html added |
|---|
Changed 10 years ago by
| Attachment: | testfs.xml added |
|---|
comment:1 Changed 10 years ago by
| Description: | modified (diff) |
|---|
comment:2 follow-up: 3 Changed 10 years ago by
| Cc: | Jared Jurkiewicz added |
|---|
OK, I see that it's copying the "id" field into the <input>, rather than the "name" field. Here's what's happening:
- FilteringSelect.labelFunc() calls store.getValue(item, "name")
- getValue(item, "name") returns a dojox.data.XmlItem? rather than a String like the FilteringSelect code expects
- (because of that things break down the line)
Calling toString() on that dojox.data.XmlItem returns a string (like "Text And Images"). Not sure if this is a bug in FilteringSelect (that it needs to call toString() on every single return value from dojo.data), or a bug in XmlStore. Jared, what do you think?
comment:3 Changed 10 years ago by
Hi Bill
Many thanks for looking into this, FWIW I would think that there should be a consistency in the values returned from stores and that value should not depend on the underlying data format, thus all calls to getValue on any store should return the real data value and not a store dependant item. I guess though that this could break a lot of stuff if, in this case, calls to XmlStore?.getValue are expecting xml content as the result.
Regards Ian
comment:4 Changed 10 years ago by
That was my thought too but "consistency" can mean various things. On the one hand it would be nice for XmlStore to be consistent with ItemFileReadStore but OTOH maybe sometimes getValue() on an XMLStore returns a whole XML fragment, like
store.getValue(item, 'name')
effectively returns:
<name>
<first>Bill</first>
<last>Keese</last>
</name>
In that case, for XmlStore to be internally consistent getValue() should always return that XmlItem object.
comment:5 Changed 10 years ago by
XMLStore is working to Dojo.data spec. getValue() returns the value of the request attribute. That value can be atomic (string, int, boolean), etc, or another DataStore? item (Hence how dijit.tree works). In this case it's returning another DataStore? item instead of an atomic type. As XmlStore?, the name, implies, Xml tags are items, so they are treated and returned as DataStore? Items.
ItemFile?*Store would do the exact same things in cases like:
{
items: [
{name: {name: "name"}, atomic: "SomeBasicString?"}
]
}
if you requested the 'name' attribute of that item you would get a DataStore? Item. And you would have the exact same problem you are denoting above.
comment:6 Changed 10 years ago by
| Milestone: | tbd → 1.4 |
|---|---|
| Owner: | set to bill |
| Status: | new → assigned |
FilteringSelect requires the name attribute (and other attributes it references) to be simple strings, or at least things that can be converted to simple strings. I.e. It has no way to handle my <first>/<last> example from above.
However, assuming that (as in this test case) "name" is a simple element containing only text, I'll modify it to work, by adding the toString() into the code.
comment:7 Changed 10 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:8 Changed 10 years ago by
Many thanks guys, your help is very much appreciated.
The use of toString() is indeed a sensible approach and I would suggest that it should be used in all widgets that are expecting simple data types to be returned from a store. If the store can potentially return complex types, then the toString override should be smart enough to turn stuff like <name><first>Bill</first><last>Keese</last></name> recursively into BillKeese?.
comment:9 Changed 8 years ago by
| Component: | Dijit → Dijit - Form |
|---|
Like I said in #9185, there isn't any special handling for XmlStore in FilteringSelect, or vice-versa. I'll take a look to see if I can figure out what the issue is. IIRC FilteringSelect copies the searchAttr not the labelAttr into the <input>, but you have them both defined to point to the same field.
When you say "data item" which of the fields in your XML above are you referring to? The searchAttr and labelAttr are "name" so you must be referring to another field.