Opened 11 years ago

Closed 11 years ago

Last modified 8 years ago

#7678 closed defect (invalid)

[regression] FilteringSelect attached to ItemFileReadStore with data from a URL does not initialise properly if the URL takes a long time to load

Reported by: mog Owned by:
Priority: high Milestone: 1.2
Component: Dijit - Form Version: 1.2beta
Keywords: Cc:
Blocked By: Blocking:

Description

I have a FilteringSelect? and ItemFileReadStore? declared as below in markup.

<div dojoType="dojo.data.ItemFileReadStore?" jsId="instrumentStore" id="instrumentStore" url="get_instruments.json?instype=FX%"> </div>

<input dojoType="dijit.form.FilteringSelect?"

store="instrumentStore" searchAttr="name" name="instrument" id="instrumentSelect" style="width: 20.0em"

/>

I noticed after I switched from 1.1 to 1.2 that the select would sometimes not show any items.

I managed to set up a test where I accessed the same page through different networks. I accessed one from http://localhost and the other from http://10.1.10.206 where the latter is the IP address of localhost as seen from remote desktop to another machine on the same network. (I was trying to force it to take a long time to serve the json).

What I observed was this:

http://localhost had get_instruments.json returning in 126ms and normal behaviour, the FilteringSelect? showed all items (76 in total)

http://10.1.10.206 had get_instruments.json returning in 719ms and the FilteringSelect? showed 0 items.

On 10.1.10.206, when I open Firebug and view the objects "instrumentStore" and "dijit.byId('instrumentSelect').store", I see the following:

instrumentStore has 76 items and _jsonFileUrl="get_instruments.json?instype=FX%"

dijit.byId('instrumentSelect').store has 0 items and _jsonFileURL=undefined

If I then try to put a sleep of 1 second in the server-side code that generates get_instruments.json and then view it on localhost, I just get a delay between clicking on the select and seeing the values appear- not the above behaviour.

Change History (9)

comment:1 Changed 11 years ago by mog

More information:

I notice that when I view the Firebug console in http://localhost and http://10.1.10.206 for the page, I see that in 10.1.10.206, get_enums.json?instype=FX% shows as a GET even before I click on the select.

comment:2 Changed 11 years ago by mog

In dojo 1.1, the same scenario as the above (view in Firebug console), http://10.1.10.206 and http://localhost both show the stores being preloaded.

comment:3 Changed 11 years ago by bill

Given that this doesn't happen when you manually add a delay, it sounds like you just have a caching problem. Try clearing your cache and restarting firefox... and maybe restarting your web server too?

On 10.1.10.206, when I open Firebug and view the objects "instrumentStore" and "dijit.byId('instrumentSelect').store", I see the following:

instrumentStore has 76 items and _jsonFileUrl="get_instruments.json?instype=FX%" dijit.byId('instrumentSelect').store has 0 items and _jsonFileURL=undefined

Hmm well that's just really weird? They don't point to the same store? What is dijit.byId('instrumentSelect').store.declaredClass?

comment:4 Changed 11 years ago by bill

Milestone: tbd1.2
Priority: normalhigh
Summary: dijit.form.FilteringSelect attached to ItemFileReadStore with data from a URL does not initialise properly if the URL takes a long time to load[regression] FilteringSelect attached to ItemFileReadStore with data from a URL does not initialise properly if the URL takes a long time to load

comment:5 Changed 11 years ago by mog

After further testing, I don't think this is a bug but I will leave someone else to be the judge of that?

Here is what happened.

I looked at the store.declaredClass as you suggested, and saw that it was "dojo.data.ItemFileWriteStore?". This made me grep my code to see where I was using it. I found that some code was being triggered: I had an onChange handler that changes some other selects based on the value of one. It uses an itemFileWriteStore for this.

In another FilteringSelect? on the page, I was setting the value attribute to be if it was a blank form, and taking the value from the database otherwise. Between 1.2 and 1.1 I do not know what the differences are, but in 1.1 things are timed such that even though my code executes, it doesn't cause a problem. In 1.2, setting the value attribute to be causes the handlers to fire in an order that clobbers the store.

I've changed my code so that the value attribute is only present in markup if a database value is present. That is, I removed the possibility of the FilteringSelect? having value=. I think this is more correct anyway.

Apologies for the confusion and thank you for the suggestions.

comment:6 Changed 11 years ago by bill

Resolution: invalid
Status: newclosed

OK good, glad you got it working. Not sure I understood all of that, didn't get what "setting the value attribute to be '' clobbers the store" means...

but yah, it seems like you are doing some stuff under the covers to chain together FilteringSelects, which is understandable since we don't have a good official way to do that... you shouldn't just directly set the store property but perhaps that's what you were doing?

Anyway, doesn't sound like this is a bug per se.

comment:7 Changed 11 years ago by mog

I still don't know why this doesn't manifest if I view the URL as localhost rather than 10.1.10.206., but I think I was doing things the wrong way to begin with so I'm not about to look too hard for that.

"setting the value attribute to " means:

<input dojoType="dijit.form.FilteringSelect?" value= />

Basically having a value of nothing. Which is not the same as not having the value attribute at all, I have found.

The reason I reset the store attribute was that I had to restrict the options in one select based on what was chosen in the other. The real-world problem is that this is a financial application- currency pairs can be traded but not every currency against every other. A currency pair has a base and a non-base currency; what base currency you can have depends on the non-base currency.

I would rather have used a query select but I could not find one that supported SQL-like query syntax- the thing I needed was "select distinct". I also didn't want to keep going back to the server, which could have given me SQL support very easily. So I had to manually remove duplicates and create a new store, then attach that to the select.

If there is a better way I would love to hear it! I think my solution is hacky, but I couldn't get it to work any other way.

comment:8 Changed 11 years ago by bill

I would rather have used a query select

All we have is QueryReadStore?. That can take a query and convert it to SQL on the server side (it seems insecure to be sending SQL from the client; too much chance for foul play). But that pings the server every time the store is accessed so is probably not what you want.

The reason I reset the store attribute was that I had to restrict the options in one select based on what was chosen in the other.

Yah, I don't think there's an official way to do that. We need to work on that. BTW I'm compiling a list of features people want in the next release of dijit *after* 1.2, on http://dojotoolkit.org/2008/09/17/dijit-1-3, you can add some comments there if you want, about what you find most important (and lacking) in the current code.

comment:9 Changed 8 years ago by bill

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