Opened 13 years ago

Closed 13 years ago

Last modified 11 years ago

#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: [email protected]…, Jared Jurkiewicz
Blocked By: Blocking:

Description (last modified by bill)

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

	        <div dojoType="" 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">

<?xml version="1.0" encoding="UTF-8" ?>
    <name>Text and Images</name>

Many thanks for your help.

Attachments (2)

testfs.html (1.1 KB) - added by Ian Fouls 13 years ago.
testfs.xml (4.8 KB) - added by Ian Fouls 13 years ago.

Download all attachments as: .zip

Change History (11)

Changed 13 years ago by Ian Fouls

Attachment: testfs.html added

Changed 13 years ago by Ian Fouls

Attachment: testfs.xml added

comment:1 Changed 13 years ago by bill

Description: modified (diff)

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.

comment:2 Changed 13 years ago by bill

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:

  1. FilteringSelect.labelFunc() calls store.getValue(item, "name")
  2. getValue(item, "name") returns a rather than a String like the FilteringSelect code expects
  3. (because of that things break down the line)

Calling toString() on that 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, or a bug in XmlStore. Jared, what do you think?

comment:3 in reply to:  2 Changed 13 years ago by Ian Fouls

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 13 years ago by bill

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:


In that case, for XmlStore to be internally consistent getValue() should always return that XmlItem object.

comment:5 Changed 13 years ago by Jared Jurkiewicz

XMLStore is working to 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 13 years ago by bill

Milestone: tbd1.4
Owner: set to bill
Status: newassigned

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 13 years ago by bill

Resolution: fixed
Status: assignedclosed

(In [17713]) Use toString() in labelFunc because returns an XMLItem instead of a string. Fixes #9354 !strict.

comment:8 Changed 13 years ago by Ian Fouls

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 11 years ago by bill

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