View Full Version : Store pageSize

24 Jul 2010, 1:44 AM
Hi, i've created a store element, i want to use his pagination features, but i can't get it work.

here is my code:

var picdata_store = new Ext.data.Store({
autoload: true,
id: 'picdata_store',
model: 'picData',
pageSize: 10,
currentPage: 1,
proxy: new Ext.data.AjaxProxy({
type: 'ajax',
url: 'filtra2.php',
reader: {
root: 'items',
type: 'json'

instead of visualize only 10 records, it show all the query result (44 records).

where is the error?


26 Jul 2010, 12:48 PM
i think this do not work at this time got the same problems without any hint here in the forum how this stuff could work. I think this is part of a special Gridview Compontent of ExtJS => Sencha

26 Jul 2010, 4:38 PM
You need to filter the store on the server side. If the client requests 10 items from the first page, you only send back those 10 from the server.

10 Aug 2010, 4:28 AM
Well, if i had to filter by server side, the methods nextpage, previouspage, loadpage are useless ....

10 Aug 2010, 4:31 AM
some days later i learnd ..... they are not useless you will get the parameters to the file and build your own SQL

27 Nov 2010, 9:51 AM
Is Sencha 1.0 fixed this? I set pageSize and used pageLoad() but it returned all my records. So I have to build my own pagination :(

16 Dec 2010, 11:37 AM
Could some one please explain what the capabilities of paging are for the store? From this thread it is obvious that these capabilities are not very well explained at all. I too assumed that pageSize, loadPage, nextPage, etc. is talking about manipulating a previously populated store on the client side. If this is not the case, it would be nice to know what exactly these methods are doing. Are they merely appending params to the store and firing it's load method using the configured proxy? If so, I agree with the @wakatanka, pretty useless. Be much better if this did this client side. I realize that pulling back all the records is is potentially a bandwidth killer, but it would be nice to be able to make this decision based on knowing the data, and have the option to page on the client after take the upfront hit on the load.

17 Dec 2010, 9:02 AM
+1 for adding a client side pagination option (maybe along side with the server one).
for most of my use cases, I preffer loading all the records to the store. so its just a matter of displaying the records in chunks for User Interface purposes.

17 Dec 2010, 10:26 AM
The parameters are not for filtering a data store locally, the whole idea behind the paging is to send less data down to the client. If you have a component with 10000 records we don't want to send them down, instead we send down smaller chunks as pages.

The parameters you set up are to determine the size pages should be and convenience methods loadPage/nextPage/etc are there to generate the proper ajax call to the server that will pass the start/count parameters so the server will be able to find and send back the proper set of records for that page. I fail to see why this would be useless, as the fundamental idea behind implementing paging is to reduce the data sets sent to the client, otherwise we could just let them scroll through the data forever.

There is a Ext.data.WebStorageProxy that lets you utilize localStorage as the data source, if you are adamant about pulling down a full set of records and paging locally you could stash the data there and utilize the proxy to get local paging.

17 Dec 2010, 10:37 AM
The bigger issue here is the failure mention the intended use of these features when they are added to the framework, especially brief code example so we aren't left with having to rummage through the forums to discover usage techniques. I am fine with server side paging, but if I know my data source is small and want to bring it down and page, it would be nice to have the option. How about an example of using the server side paging somewhere?

How are we supposed to automatically know this is intended for server side usage from the description?
nextPage() : void
Loads the next 'page' in the current data set

17 Dec 2010, 10:46 AM
Good point on the API, it could definitely be more clear. loadPage does a better job explaining:
Loads a given 'page' of data by setting the start and limit values appropriately. Internally this just causes a normal load operation, passing in calculated 'start' and 'limit' params

18 Dec 2010, 12:37 AM
as long as we are on this. is there a recommended page size for simple lists (just text lists)?. is there an optimized number for good user experience? i assume the performance qriteria is platform dependent...

26 Sep 2011, 2:18 PM
I was investigating how to do server side sorting, filtering, and paging for a datastore for sencha touch. Here is what I found. When I call LoadPage( 1 ) on the store, it calls the server to get a mouthful. In that mouthful, it passes a page number and a limit for the records on a page. The server is then required to implement that pagination in the sql query.

Some code:

TitleView.stores.ChangeRecords = new Ext.data.Store({
model: 'ChangeRecord',
sorters: ['date_created', 'studio_name'],
filters: [
{ property: 'notification_id', value: ' = 11' }
remoteSort: true,
remoteFilter: true,
proxy: {
type: 'ajax',
url: '/wwsgd/ajax_handler/FastAjaxChangeRecords.php',
reader: {
type: 'json',
root: 'changeRecordList'
autoLoad: false

Query params passed up in the ajax call are:

filter:[{"property":"notification_id","value":" = 11"}]

So you can see that the ajax call passes up the parameters. It's up to me to catch that junk in the server and put it into some SQL.

something like:

Select blah blah blah
where blah blah blah (interpret the sort param with json_decode loopy stuff)
order by blah blah blah (interpret the filter param with json_decode loopy stuff)
limit blah blah blah (page number * limit, limit)

so for this ugly duckling, it would be

select * from change_records
where notification_id = 11
order by date_created ASC, studio_name ASC
limit 25, 25

I suck at php but I wrote some code to morph those params into the necessary SQL.

I hope this helps,

Mike Vargo

18 Jan 2012, 11:33 AM

A store isn't necessarily populated with a complete dataset in one server round trip. I start by loading a store with about 30 or 40 objects, then add to that store as the application is running. The list responsible for rendering the contents of that store works just fine for a bit - then the app blows up when a certain list threshold is encountered.

This would be a good place for some kind of client side list paging mechanism.

26 Jul 2012, 7:17 AM
Have there been any additional thoughts on adding this (client-side paging)? My use case is that I'm populating a list with an associated store -- user.products() -- which is loaded based on nested JSON data (loading the user automatically populates the products). Obviously I don't want to load all of the users (or even just the one user) again to get a new "page" of products, especially when there's no real way for me to handle the paging since the products are nested.

For now I'm thinking about modifying the ListPaging plugin manually to try to create client-side paging, but it's a rather daunting task for my limited use of it.

Since I'm working in Sencha Touch 2, I'll be copying this post over to the proper forum in the form of a new thread as well.