store

Ext JS 4: Updating Ext.ux.data.PagingStore

I am in the process of updating an Ext JS 3 application to use Ext JS 4. So far so good, until I got to one grid that uses Condor’s Ext.ux.data.PagingStore. I tried to get away with using the Ext.ux.data.PagingMemoryProxy, but it was not to be since I want to add and remove records from the store. I tried to find an updated version among the thread in the forum, but had no luck. Therefore, I tried my hand at updating Ext.ux.data.PagingStore for Ext JS 4.

The code for Ext.ux.data.PagingStore is at https://github.com/aghuddleston/Ext.ux.data.PagingStore. I have also included some unit tests, using Siesta as the testing tool. I’m just starting to integrate this into my application, so it’s not well tested yet… I’ll be updating the code as changes are needed.

The main difference from the previous version is that in Ext JS 4 is that “start”, “limit” and “page” are no longer set on the params in the load request, but are their own properties on the Ext.data.Operation config object. A request is only made to load data if the params or extraParams change from the previous load request. Otherwise, it will just page the data. Any proxy should be usable, but I have only tested “ajax” and “memory”. Samples of configuring the data store and loading data are in the comments in the code.

Helpful links:

Version Info:
Ext JS 4.1.1

Advertisements

Ext JS 4: Load a Data Store using JSON params

Update 12/5/2012: Recently came across Skirtle’s excellent write up about custom proxies and I realized that my JSON Ajax proxy was overly complicated. Now it is simplified and results in less overriding of the code.


In Ext JS 4.1, when you have a store configured to use an Ext.data.proxy.Ajax proxy and you call store.load(), the request is a GET request with your params url encoded. I’ve managed to work w/this so far, but I now have a case where my params are getting much more involved (nested objects) and JSON is a better fit. Currently there is no way to indicate to the proxy “do this as a POST request, w/JSON”, like you can when calling Ext.Ajax.request directly (just use the jsonData parameter).

After much searching and Ext JS 4.1 source debugging, I extended the Ext.data.proxy.Ajax proxy and created one that will post the params as JSON.

The code is in gist 3370841.

I’m currently starting to really use this, so I’ll update if I find any issues, but basically it just puts your params into the jsonData property, so that when Ext.Ajax.request gets called, it does the right thing. It also says that “reads” are “POST”s, not “GET”s. The encode sorters/filters stuff is overridden to make sure that sorters and filters do not get JSON encoded twice. I’m not using full CRUD on my store, but I think it should all work.

To use it, just use this “jsonajax” as your proxy. Here’s a store config. It uses the new proxy and also has remote sorting and paging.

{
	xtype: 'store',
	storeId: 'myStore',
	model: 'My.Model',
	pageSize: 25,
	remoteSort: true,
	proxy: {
		type: 'jsonajax',
		url : 'my/url/here,
		reader: {
			type: 'json',
			root: 'rows',
			totalProperty: 'total',
			messageProperty: 'message'
		}
	}
}

Helpful links:

Version Info: Ext JS 4.1.1

Ext JS 4: Override timeouts

One way to override all the ajax related timeouts, including store loads and form submits.

Ext.Ajax.timeout= 60000; // 60 seconds
Ext.override(Ext.form.Basic, { timeout: Ext.Ajax.timeout / 1000 });
Ext.override(Ext.data.proxy.Server, { timeout: Ext.Ajax.timeout });
Ext.override(Ext.data.Connection, { timeout: Ext.Ajax.timeout });

This is from a Sencha forum post How to set timeout which is by ext4all

This was helpful for me b/c I wanted to increase the timeout globally across my application. Even though the documentation makes it look like setting Ext.Ajax.timeout will increase all timeouts, it’s just not true. Debugging through the code, I would still see 30 sec timeouts for store loads (b/c it pulls from the Ext.data.proxy.Server timeout). But, this covers it all.

Version Info: Ext JS 4.1

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:

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:

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.