PagingToolbar paramNames

[Artur Bodera (Joust)]

Hi.

The manual for Ext.PagingToolbar states:

This Component load (http://extjs.com/deploy/dev/docs/output/Ext.data.Store.html#load)s blocks of data into the Store passing parameters who's names are specified by the store's paramNames (http://extjs.com/deploy/dev/docs/output/Ext.data.Store.html#paramNames) property.That is not true!

Inside of the class we see that:


// private
doLoad : function(start){
var o = {}, pn = this.paramNames;
o[pn.start] = start;
o[pn.limit] = this.pageSize;
... so the component uses internal paramNames instead of the store's paramNames.



FIX 1:
Change line 285 in PagingToolbar.js or line 21517 in ext-all-debug.js , from:

var o = {}, pn = this.paramNames;to:

var o = {}, pn = this.store.paramNames;FIX 2:
Add after line 346 in PagingToolbar.js or after line 21569 in ext-all-debug.js ("bind" function):

Ext.apply(this.paramNames,store.paramNames);Have a nice day.

[Artur Bodera (Joust)]

.. I hope you guys know what you're doin with moving my post. It's not really a documentation bug, because it is MUCH BETTER for the toolbar component to fetch paramNames from Store than vice-versa.

(i.e. the toolbar is just a widget, while the store is in the "central management" point and can be used in/with multiple grids/widgets).

Conceptually, the manual is smart! Please don't change the documentation but implement the suggested fix to the widget source.

[evant]

Except that assumes the store always supports paging, which is not correct. Paging with the PagingToolbar will use the parameters as configured in the PagingToolbar. It works as intended, the issue is with the documentation.

[Animal]

Except that assumes the store always supports paging, which is not correct. Paging with the PagingToolbar will use the parameters as configured in the PagingToolbar. It works as intended, the issue is with the documentation.

But the Store does have a paramNames property which specifies the parameter names which may be used to request pages with.

It really is a good idea to let the PagingToolbar get these configs from the Store it is bound to.

In fact, I seem to remember contributing the 3.0 updated PagingToolbar code with this facility in and documented which is why the doc comments say that.

[mjlecomte]

Discussion was getting lengthy for the doc bugs thread so moved here. I may have to move this to general discussion so the OP can still reply.

Anyway, my thoughts:



But the Store does have a paramNames property which specifies the parameter names which may be used to request pages with.

It really is a good idea to let the PagingToolbar get these configs from the Store it is bound to.

In fact, I seem to remember contributing the 3.0 updated PagingToolbar code with this facility in and documented which is why the doc comments say that.

Coincidentally I was just reviewing the docs on this yesterday and was a bit confused by what was going on. IMO I think Animal's statement needs correction:


But the Store does have a paramNames property which specifies the parameter names which may WILL be used to request pages with.


I side with what joustin is saying. It's confusing to set it in two places. Pick one. The more logical place to configure the paging toolbar load request application of params seems to be within PagingToolbar to me.

I would agree with joustin's code suggestion, except Store should also have it's paramNames changed to remove the start and limit defaults. The defaults would be those residing within PagingToolbar as they are now. The developer MAY override them from the store if they choose by modifying the store's paramNames, or by directly modifying the PagingToolbar paramNames.

So specifically modify the store paramNames default to be:


this.paramNames = {
// "start" : "start",
// "limit" : "limit",
"sort" : "sort",
"dir" : "dir"
};

[Animal]

A Store doesn't need a PagingToolbar to function though, and to request pages. It just needs the calling code (wherever that might be, and whoever wrote it) to use the correct parameter names.

IMHO, the person/code responsible to configuring the Store must know this, and must have the ability to define what parameter names are used.

If, at some future point a PagingToolbar becomes involved, then that must abide by how the Store requires to be worked.

[mjlecomte]

Hrm, fair enough. Maybe this goes back to Evan as I don't see what Store doesn't support paging. Ext.data.Store sets paramNames, including start/limit. So why is PagingToolbar, which requires a store, assuming something on it's own?