ExtJS 4, extend the Ext.toolbar.paging class to change some behavior

The Ext.toolbar.paging (pagingtoolbar) class is used when you require paging on an ExtJS gridpanel. But this class comes with some limitations. In this article we will extend the class to create a factory or base class for reusability.


imageThe refresh button

One of the limitations is that by default there is no config parameter that would hide the refresh button.

Alternative handlers for the buttons

The refresh and page buttons load or refresh pages of the store that is bound with the toolbar. By default you can’t influence the handlers of these buttons.

The store’s load parameters

One big annoyance of the paging toolbar is that it doesn’t remember the store’s load parameters that came with the load of the grid’s store. For example your store is loaded based on a group let’s say “Mercedes” and the grid’s store loads the Mercedes parts. When you do a refresh or next page, “Mercedes” is not remembered if you used it in the “load” params of the store. Only the extraParams that are set with the proxy are remembered. But that is quite a hassle to set this every time.


Time for an extension

Extjs 4 is very flexible in extending Ext classes. But be warned not to override existing functionality to easy, for you might be in jeopardy when an ExtJS upgrade is installed.

When to extend?

  • when you need a core class to be offering more functionality (like the following example)
  • when you create often objects from standard Ext classes with repetitive settings (like a search toolbar with always the same form fields and buttons, used in different panels)
  • reusability

Advantages of extending classes

The greatest advantage of extending a class (to a factory or base class) is that when you demand changes to the extension you made, you only have to modify one class and your whole applications benefits from it.

Another advantage is that you can add functionality to your own taste and demand.

Disadvantages of extending classes

Sensitive to ExtJS upgrade incompatibility. Therefor don’t stretch your luck too far. One very important recommendation is that you always extend with the source code of the class that you extend next to you. First make sure that what you want is not already there. Sometimes the source code show more than what the documentation offers.

Extending the Ext.toolbar.Paging class

Let’s add the following config options to the class:

  • hideRefresh (boolean) – hide the refresh button
  • saveParamsOnLoad (boolean) – save the load params object into the proxy’s extraParams
  • alternateHandlers (object) – alternate handler function for the refresh button

How to do it

Create a new file named Ext.ux.basePagingTbar.js in the folder “ux” of your application.

Make sure you add this new file in the views of the app.js of your application.

Using the Ext.ux.basePagingTbar class

To use this class you simply add the following to your gridpanel:

And instead of the standar pagingtoolbar you are now putting:

The class is an extension of the ExtJS core Ext.toolbar.paging class, so it inherits everything from that class into your extended class. When using the alternateHandlers (which you presumably might not), remember that the scope is already on this according to the Ext.toolbar.paging source code.

Some notes on safely extend core ExtJS classes

  • Never change behavior of Ext base classes with functionality that is not compliant with Sencha Ext standards.
  • Keep extensions independent. This means that you should not let it depending on additional classes that are not unique to the situation.
  • Make sure that your additional functionality don’t break the application. Never assume that what comes in always fits.
Johan van de Merwe
Dedicated to professional software development since 1985. Has worked since 1992 as IT manager in several international operating companies. Since 2007 CEO and Sencha Ext JS web application developer at Enovision GmbH.

Leave a Reply