EXT JS 4 – BINDSTORE VS. RECONFIGURE

I have a form inside of my Ext JS 4 app that after it renders (yes, after it renders), I make an ajax request to load data into a store.  After the store loads successfully, I do a bit of fiddling with the form to add/remove components based on the state of some of the data in the store.  I then call “form.loadRecord(myRec)”.  I think I did this b/c I was working around/with the current state of forms backed by a store.

Of more interest though, my model has two associations on it (with a hasMany relationship).  The data that is in the associated store is presented in two separate grids on the form.   The problem I was having was getting the data from the store I loaded for the form, into the store that is backing the grid.

In my config for the form, I have the grid panels and guess what, store is a required config.  But I don’t have the store until after the form renders, so I put a temporary store in the gridPanel configuration.  After loading the data into the form (via loadRec) I wanted to replace the temporary store with the real store.

First I did this:

1 2	myForm.loadRecord(myRecord); myGrid.getView().bindStore(myRecord.getAssociatedStore());

where “getAssociatedStore” is really that accessor that you can use to get the associated stores, by using the relationship name.

It worked but there were a few odd things, like not getting the no records text and if the data was updated (thru other parts of the app) it refused to sync.  Well anyways, I figured out what was going.  I was updating the store on the “view” of the grid.  I didn’t realize they could be different.  The Firebug Illuminations plug-in finally helped me see what is going on.

I updated my code to this:

1 2 3

myGrid.reconfigure(myRecord.getAssociation(), columnConfig); myGrid.getStore.sort("id", "ASC"); myGrid.getView().refresh();

And it works.  This way I was replacing the store that backs the gridPanel (and the view) and not just the one behind the view.  The documentation on Store.reconfigure (in 4.0.2) says the columnConfig is optional, but on reading the code, it most definitely is not.  Not sure which is wrong, the documentation or the code, but in 4.0.2, both the store and columnConfig are required params.

I wonder if there is another, better approach to the whole thing, but this works.