Issue Type: Bug Created: 2009-07-23T04:28:38.000+0000 Last Updated: 2009-12-15T08:29:38.000+0000 Status: Resolved Fix version(s): - 1.9.6 (24/Nov/09)
Reporter: Sudheer Satyanarayana (bonaparte) Assignee: Matthew Weier O'Phinney (matthew) Tags: - Zend_Dojo
Related issues: - ZF-7266
I hope the title says it all.
It is working well with ZF 1.8.3 but not 1.8.4 and trunk.
Posted by Eric Dennis (threetee) on 2009-08-18T19:42:35.000+0000
Pre-1.8.4 (this works):
And here is what it looks like in 1.8.4 and after (this doesn't work):
Posted by Matthew Weier O'Phinney (matthew) on 2009-10-16T06:54:38.000+0000
Can you please provide a few things? * Minimal code necessary to reproduce the issue * A detailed description of the behavior you're expecting, including the Dojo markup that should be generated to achieve the results you need * A detailed description of the actual behavior you're receiving, and why the Dojo markup generated does not work The reason for the change from 1.8.3 to 1.8.4 was due to another issue filed, in which it was reported that instantiating the data store in the same scope as the dojo.require statements was resulting in a race condition, where the store was attempting to instantiate before the actual dojo.data store class was yet loaded. Moving the store creation to an onLoad event corrected those issues.
I've tried using a datastore with a filtering select recently, and all was working as expected for me -- which is why I'd like you to answer the above questions.
Posted by Matthew Weier O'Phinney (matthew) on 2009-11-19T11:57:48.000+0000
Fixed in trunk and 1.9 release branch.
Posted by Symphony IT (symphony) on 2009-12-15T07:55:10.000+0000
The fix for this has broken all of the dojo.data.ItemFileReadStore stores on my Filtering Selects. They worked fine on version 1.9.5 of the framework, but when I updated to version 1.9.6 (which this fix was included in) and all of the stores on my filtering select no longer work. Could we revert this please until we find a better solution?
I suspect this is down to the now globalised variable (meaning you're overwriting the datastore call to dojo.data.ItemFileReadStore) for the datastore rather than the re-ordering, however I'm currently in the process of finding the exact cause in the code.
Posted by Symphony IT (symphony) on 2009-12-15T08:29:38.000+0000
Looking into this, this is purely caused on the programmatic way of doing things and it's down to the changes made for this issue in:
before you were removing the store parameter passed if it was a programmatic instance, then using the dijit.byId("dropDown").attr("store", stateStore); to set the store.
This does seem to be caused by the globalised variable because it's being overwritten, the original datastore is no longer accessible via the variable for the first FilteringSelect on a page. All subsequent datastores for all subsequent FilteringSelects are overwriting the datastore before the filtering selects have ever got a chance to be initialised by Dojo, hence all filtering selects now only have the last Datastore as their data source.
I'd have to say breaking the options in a drop down is far worse than not being able to set the selected option you want when first loaded.
Have you found an issue?
See the Overview section for more details.