QueryReadStore does not work with FilteringSelect

[guest]

Not sure if this is a defect or enhancement.

I tried using a QueryReadStore? with a FilteringSelect? so I could easily re-fetch the data from the server on demand. I have an "Add New" button next to my Select list which adds a new item to a backend db, which when finished should update the select list with the new value.

The problem with using a QueryReadStore? and FilteringSelect? is that it re-fetches the data on each keypress in the filtering select and also when you select an item with the mouse - this causes the initial value to become re-selected. In other words there is no way to actually change the value in the Select Box.

I would not need to use a QueryReadStore? with a FilteringSelect? if there was an easy way to tell an ItemFileReadStore? that you want to re-fetch the data from the server.

At current the only way (that I know of) to handle this is to create a brand new ItemFileReadStore? object with the same URL as the original store, and assign it to widget.store. This seems like a poor way to solve this problem.

For what it's worth - here is the attempted markeup I used:

[guest]

oops: borked my HTML:

<div dojoType="dojox.data.QueryReadStore?"

id="select_store_field_3486" jsId="select_store_field_3486" url="/callbacks/some_php_script.php"></div>

<input id="field_3486"

dojoType="dijit.form.FilteringSelect?" store="select_store_field_3486" autoComplete="false" ignoreCase="true" pageSize="15" searchAttr="name" name="candidate_id_4_3486" size="15" style="width: 250px;">

[bill]

As we discussed 8 hours ago on #dojo, this is intended behavior. If you want an enhancement to ItemFileReadStore to re-download the data (if such a feature doesn't already exist) please file another ticket about it, with the data category.

trutwijd: Anyone used a QueryReadStore with a FilteringSelect?  It seems to do a server pull for every keypress.
wildbill:trutwijd: that sounds believable
wildbill:(ie, the expected behavior)
mccain:trutwijd: QueryReadStore is meant for sending data to the server for filtering huge lists, so that happens yes
trutwijd:Hmm - I think it's the only way to get a FilteringSelect to refresh on demand though - unless you know how to do that with a ItemFileReadStore
trutwijd:Seen a couple forum posts on this, but unfortunately usually no answers.
trutwijd:mccain: not much data - but need to be able to refresh the FilteringSelect w/o full page refresh (see above)

[guest]

Replying to bill:

As we discussed 8 hours ago on #dojo, this is intended behavior. If you want an enhancement to ItemFileReadStore to re-download the data (if such a feature doesn't already exist) please file another ticket about it, with the data category. {{{ trutwijd: Anyone used a QueryReadStore? with a FilteringSelect?? It seems to do a server pull for every keypress. wildbill:trutwijd: that sounds believable wildbill:(ie, the expected behavior) mccain:trutwijd: QueryReadStore? is meant for sending data to the server for filtering huge lists, so that happens yes trutwijd:Hmm - I think it's the only way to get a FilteringSelect? to refresh on demand though - unless you know how to do that with a ItemFileReadStore? trutwijd:Seen a couple forum posts on this, but unfortunately usually no answers. trutwijd:mccain: not much data - but need to be able to refresh the FilteringSelect? w/o full page refresh (see above) }}}

My bad - I also filed 6073 at the same time which deals with ItemFileReadStore? re-fetch, though I think it will also be met with resistance. I thought the behavior of QueryReadStore? + FilteringSelect? strange, not intended, and forgot wildbill's comment from IRC. That said, I do think the FilteringSelect? documentation in the book needs to updated to indicate that a QueryReadStore? is not an acceptable backend for the widget so no one else falls into this. (Well, no one who reads the documentation) I will put a comment in the documentation pointing to this ticket.

Josh

[bill]

FilteringSelect documentation in the book needs to updated to indicate that a QueryReadStore is not an acceptable backend for the widget

Actually QueryReadStore is a recommended back end for FilteringSelect. It often makes sense to go the server every time the user hits a key . See google suggests for an example of this.

[guest]

Replying to bill:

FilteringSelect documentation in the book needs to updated to indicate that a QueryReadStore is not an acceptable backend for the widget

Actually QueryReadStore is a recommended back end for FilteringSelect. It often makes sense to go the server every time the user hits a key . See google suggests for an example of this.

True - but why did my FilteringSelect? then always re-select the first value when the field becomes unfocused? It also restored the first value if I select a new value, then unfocus. This was the root reason for filing this ticket. Basically there was no way I could change the value of the FilteringSelect?, it would temporarily allow a selection of another item in the list, then revert back after a last re-fetch to the server.

Thanks,

Josh

[guest]

FYI - this is dojo 1.0.2 release

[haysmark]

Maybe I don't understand the problem, but it sounds like to me that your server app for your QueryReadStore? is either not receiving or is ignoring the dojo.data query parameters. I say this because you complain is always selects the 'first' value. Well, when FilteringSelect? makes a query, it always assumes that the server received and applied the query, meaning the first item in the results is *the* value it asked for. If the query got lost somewhere then it makes sense that it would select the first value in the list.

Here is a perfectly good QueryReadStore? with a FilteringSelect? you might want to reference:

http://archive.dojotoolkit.org/nightly/checkout/dojox/data/tests/QueryReadStore.html

If you check the xhrs in Firebug, you see it is making requests like:

http://archive.dojotoolkit.org/nightly/checkout/dojox/data/tests/stores/QueryReadStore.php?q=Wyom*&start=0&count=5
http://archive.dojotoolkit.org/nightly/checkout/dojox/data/tests/stores/QueryReadStore.php?q=Arizona 

If your server either isn't receiving the parameters at the end of the url, or forgot to process them, you are bound to run into the trouble it sounds to me like you are describing.