如何使用ExtJS构建应用系统2

原文地址：http://blog.extjs.eu/know-how/writing-a-big-application-in-ext-part-2/

Writing a Big Application in Ext (Part 2)
2. February 2009 – 14:12 Important
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.

Introduction
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:

     this.getId();
    Ext.ComponentMgr.register(this);
    Ext.Component.superclass.constructor.call(this);
 
    if(this.baseAction){
        this.baseAction.addComponent(this);
    }
 
    this.initComponent(); 

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.

initialConfig
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 */);
    this.getId();
    Ext.ComponentMgr.register(this);
    Ext.Component.superclass.constructor.call(this);
 
    if(this.baseAction){
        this.baseAction.addComponent(this);
    }
 
    this.initComponent(); 

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.

listeners
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:

     Ext.Component.superclass.constructor.call(this);
 
    if(this.baseAction){
        this.baseAction.addComponent(this);
    }
 
    this.initComponent(); 

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(){
    if(this.listeners){
        this.on(this.listeners);
        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
    AnExtension.superclass.constructor.call(this, config);
 
    // parent constructor call post-processing
 
} // eo function constructor 

and define your listeners therein.

The Rule: Define listeners in constructor method.

Conclusion
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!