Writing a Big Application in Ext (Part 2)

Code in this post can be obsolete, however, principles and theory may still apply.


If you have not already done so, study Writing a Big Application in Ext (Part 1) before you read this article. It would be very hard, if not impossible, to understand concepts explained here before you fully understand the first part.


It has been almost one year since I have published the first part of this article. I have been successfully using the concept of pre-configured classes personally to write a really big application (~150 javascript files, ~60,000 lines of code, plus server-side and css). The application is fully modularized, each class in separate file and it has proven that it can be easily developed, managed and debugged.

Unfortunately, the same has not been always true for other users, they were hitting various problems and Ext Support Team have had to handle may questions and help requests. These accumulated to the degree where the concept has been called “absolute abomination” (read absolutely hated) and it was stated that “it causes problems”.

Note: As “fast cars” do not cause accidents but “slow drivers driving fast cars” do, the concept itself cannot be a cause of the problems but its application can.

In any case, there must be some illogic if I can use the concept but others cannot.

Thus, I have looked deeper in it and I have isolated some pitfalls the users can run into on the course of development. I will also write on “dos” and “don’ts” and on when to use a pre-configured class and when not. I will not compare this concept to another application design concepts (factory functions, in-line configuration, on-demand load, or other) because 1) I do not use them and 2) I do not want to turn this article into a Linux versus Windows discussion.

It is fully up to you which application design concept you choose. However, if you do choose this one then follow the rules I’m going to lay down.

Most Common Sources of Troubles

  • Dull Copy&Paste
  • Extending a non-Ext.Component class
  • Not calling parent methods
  • initialConfig
  • listeners

Dull Copy&Paste

Do you know such people? They post on a forum:

I need to drag from tree to qrid, gimme plz complete codez

And if somebody altruistic writes a fragment of “codez” for him in a sheer attempt to help the response is going to be:

Your codez don’t work. Help me plz my manager wants it working

Do you see what happened? A dull “developer” ordered a code on the forum, he’s got some, copied&pasted it to his application without a clue what the code does, maybe hasn’t even changed url that still points to your server and the result is: it doesn’t work.

Well, this is an extreme (but not so rare as you would think), nevertheless, copying&pasting without understanding of what the copied&pasted code does can lead only to frustrations.

I am not against Copy&Paste in general, it can save a lot of time and I also occasionally do it, but I am against not-understanding or mis-understanding not only of coding but also of life.

The Rule: Do Copy&Paste but always with full understanding of what the code does.

Extending a non-Ext.Component class

If an Ext class does not inherit from Ext.Component the initComponent is never called so the code you have written there is never executed. This is fragment from Ext.Component constructor:




Ext classes that do not inherit from Ext.Component do not have this.initComponent(); line in their constructors.

The Rule: Always check if the Ext class you are going to pre-configure inherits from Ext.Component. You have to use an another approach if it does not.

Not calling parent methods

It happens very often that you do not only add some methods in your extended class but that you modify existing ones. initComponent being the first example. onRender, afterLayout are other (but not only) frequently overriden methods.

These methods are already implemented in the class you are extending and its parents so if you forget the line:

// in initComponent override
YourExtension.superclass.initComponent.apply(this, arguments);

// or in onRender override
YourExtension.superclass.onRender.apply(this, arguments);

// or in afterLayout override
YourExtension.superclass.afterLayout.apply(this, arguments);

your class will not work.

The Rule: Never forget to call the parent method, unless you exactly know what you are doing.


The constructor of Ext.Component saves the config passed to it as initialConfig:

     * This Component's initial configuration specification. Read-only.
     * @type Object
     * @property initialConfig
    this.initialConfig = config;

    Ext.apply(this, config);
    this.addEvents(/* abbreviated for clarity */);



You see what happens? The constructor saves initialConfig before initComponent is executed. Thus, all configuration you write in initComponent is not saved. I have overlooked this in first versions of my templates and examples mainly because there is only a couple of classes that refer to initialConfig and even in these classes the absence of properly saved initialConfig causes problems very rarely. These Ext classes refer to initialConfig:

  • AnchorLayout
  • BorderLayout
  • Action
  • GridPanel
  • Tip
  • Combo
  • Form

Now, I have updated all my examples, extensions, templates and main site to include this “magic” pattern:

// create config
var config = {
    // put your config here
}; // eo config object

// apply config
Ext.apply(this, Ext.apply(this.initialConfig, config));

// call parent
YourExtension.superclass.initComponent.apply(this, arguments);

The Rule: Ensure that your extension saves initialConfig.


If you try to install event handlers by setting property listeners in your config they will not work. Why? The answer lies again in the order of actions in Ext.Component constructor:;



As you can see, the constructor calls its parent, that is Ext.util.Observable before initComponent. Ext.util.Observable constructor executes:

Ext.util.Observable = function(){
        delete this.listeners;

Any listeners set in initComponent are thus ignored.

There is an easy workaround. Put constructor method in your extension:

 constructor:function(config) {
    // parent constructor call pre-processing - configure listeners here
    config = config || {};
    config.listeners = config.listeners || {};
    Ext.applyIf(config.listeners, {
        // add listeners config here

    // call parent constructor, config);

    // parent constructor call post-processing

} // eo function constructor

and define your listeners therein.

The Rule: Define listeners in constructor method.


If you decide to use my way of writing a big application then follow these rules:

  1. Do Copy&Paste but always with full understanding of what the code does.
  2. Always check if the Ext class you are going to pre-configure inherits from Ext.Component. You have to use an another approach if it does not.
  3. Never forget to call the parent method, unless you exactly know what you are doing.
  4. Ensure that your extension saves initialConfig.
  5. Define listeners in constructor method.

Happy extending!

Do not forget to read Part 1 and Part 3 of this article.

Follow me:
Latest posts by saki (see all)

23 Responses

  1. Hey Saki, thanks for this great article. It really got me going on extending Ext’s classes.

    I just wanted to give an update about the last section in this post about listeners. As of (I believe) Ext 3.2.0, you can now add a listeners property inside of initComponent(). This is due to Component.initComponent() duplicating Observable’s constructor for this very purpose (probably from so many people writing their own pre-configured classes!)

  2. Saki: Thanks very much for these clarifications. We\’re working on a medium-sized ExtJS application (~14K lines right now, about 1/2 done), and are using pre-configured classes extensively. They\’ve worked very well for us.

  3. Saki, I want to share my experience here.

    Initially, I’m a Flex developer, but Big Client came to our company asking for ExtJS expert for developing Outlook+Gmail+IM alternative to be used in their intranet as info sharing application.

    We agreed, I’ve heard about ExtJS and even run a couple of samples year ago.

    And then project started, I was very quickly learning ExtJS and was shooting my legs again and again, because all the JavaScript and JSON are so hacky for the ActionScript3 developer, who have compiler for all error checking, strict typing, and all static language comfort.

    Important moment, we use SCRUM for the development, and very tight deadlines.

    And then I’ve discovered your patterns and learned a lot in one moment. I can’t say it prevented me from making new errors, but your approach cleared a lot of questions, so now 2 months of development are gone, and I can say application is more or less stable, could be extended and supported further.

    I want to thank you for the great work you’ve done, and all the inspiration of your samples.

    Regarding pitfalls, yes, I had it once, the one with listeners, which lead me to setting listeners in “onShow” method, but then I looked into your greatly documented code again and found my mistake.

    Thank you!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Enter your username and password to log into your account. Don't have an account? Sign up.

Want to collaborate on an upcoming project?