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:

1
2
3
4
5
6
7
8
9

    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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

    /**
     * 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:

1
2
3
4
5
6
7
8
9
10

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

1
2
3
4
5
6
7

    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:

1
2
3
4
5
6

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

 
 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!

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

Preface

This article it the follow up of the Writing a Big Application in Ext post and it assumes that your application is written, at least to some degree, that way. It also assumes that the server side language is PHP 5.x, other users can take the idea and write the server side logic in their languages. It is written on and for Linux environment, again, users of other systems must accommodate it to their environments.

What’s the difference anyway?

On a development system we want fast cycle of edit-file/run-application. Also, we want to have access to human readable, fully commented files into which we can step with Firebug debugger to see what is happening when code runs. If your application consists of 100 javascript files we want them all individually included in page head to be able to quickly edit/reload page/see the result.

On a production system we want fastest load possible, no debugging, and possibly to prevent unauthorized users or attackers to read our files. No comments are needed in files.

The Files

We have our source javascript files but we need a bit more. First of all we need a file list that would define which files and in which order we will include. This file list will be used by both switch logic and Makefile that will create the compressed version of sources. An example of such file list can be:

FILES=\
    Ext.ux.grid.Search.js \
    Ext.ux.IconMenu.js \
    Ext.ux.IconCombo.js \
    Ext.ux.ThemeCombo.js \
    Ext.ux.LangSelectCombo.js \
    Ext.ux.grid.RowActions.js \
    Ext.ux.grid.CellActions.js \
    Ext.ux.tree.ArrayTree.js \
    Ext.ux.FileUploader.js \
    Ext.ux.UploadPanel.js \
    Ext.ux.FileTreeMenu.js \
    Ext.ux.FileTreePanel.js

Next, we need Makefile (file with rules for make program):

include filelist
 
application-all.js: application-all-debug.js
    java -jar ~/bin/yuicompressor.jar \
        application-all-debug.js > application-all.js
 
application-all-debug.js: $(FILES)
    cat $(FILES) > application-all-debug.js
 
clean:
    rm -f application-all-debug.js application-all.js
 
install: application-all.js
    # whatever you need to do to upload 
    # new version to production server

You can download yuicompressor here and you may need to install some “devel tools” and java on your Linux box for the above to run.

The Switch

We need a server-side logic that would generate the includes for individual files on the development system and one-file include on productions system. Decision what system it is running on can be also automatic. For example, our public, production web server has name extjs.eu and our development system has name extjs.localhost.

We can easily check if "extjs.localhost" === $_SERVER["SERVER_NAME"] and if yes we can run development branch if not we run production branch.

The Development Cycle

With all this in place, if you add a file you just add it to the file list, test it and debug it on the development system and if everything is works you issue the command:

make install

The compressed version is created and it is uploaded to your production system. The same is true for editing of a file, you only won’t modify your file list. If you delete file, just remove its line from file list and make install.

Conclusion

Hopefully this can make your developer’s life easier; I couldn’t live without it.

The complete working example of the above system is here, with manual switch for demonstration purposes.

Enjoy!

Preface

I have decided to write this article for those users of Ext 2.x that have already grown up from having one HTML page with embedded script that creates one simple window or form, for those who are already decided that Ext is the way and for those who are fighting with too long files hardly to search in and feeling that their applications need a structure.

The number of approaches to a problem and number of solutions of it is equal to number of people that tackle it. The way I am going to describe in the following text in not the only one and do not want to say that either an application is going to be written my way or it is not good. Nothing like that.

What I do want to say is that this approach is workable, neatly structured, easily maintable, simply stated: It works!

What is “A Big Application”?

If you have a Viewport with BorderLayout, a grid and a form all in one file it certainly is not the big application, right?. If you have tens of windows each with a grid, form or border layout in it in tens of files it certainly is the bit application, right?

(Germans have very nice word: Jein which is combination of Ja = Yes and Nein = No.)

The answer to both above statement is Jein. When the application becomes big, then? The answer is simple: It becomes big when you feel it is big. It is the point when you start to have troubles to orient yourself in number of files or in you have troubles to find a specific place in one file, when you cease to understand relations of components, etc. I am writing you here but imagine when a 2-3 grades less experienced programmer starts to have this feelings.

We can safely state that each application is big as also a small application deserves to be well written and it may likely become really big as we start to add new features, write new lines of code, new CSS rules, etc.

The best and the safest state of the mind at the start of a new application is: I’m starting the big application!

Files and Directories

These we need to organize first. There is always a ServerRoot directory configured in Apache or another HTTP server so all subdirectories I’ll describe later are relative to it.

Recommended directory structure:

./css (optionally link)
./ext (link)
./img (link)
./js
index.html


Link in the above structure means a soft link pointing to a real directory where files are stored. The advantage is that you, for example, download new Ext version to a real directory then you change the link above to point there and without changing a line in your application you can test if everything works also with this new version. If yes, keep it as it is, if no, you just change the link back.

• css will hold all your stylesheets. If you have global stylesheets with company colors or fonts you can create css directory as link too.
• ext link you your Ext JS Library tree as described above
• img link to your images. It can contain icons subdirectory as well.
• js will hold all javascript files the Application is composed of.
• index.html HTML file that is an entry point of your application. You can name it as you want and you may need some more files for example for a login process. Anyway, there is one application entry point/file.
• optionally you can create a directory or a link for your server side part of the application (I have ./classes). You can name it as you wish but consistently for all applications you write (./server, ./php are some good examples)

index.html

Minimal index.html file content is:

<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  <link rel="stylesheet" type="text/css" href="./ext/resources/css/ext-all.css">
  <link rel="stylesheet" type="text/css" href="./css/application.css">
  <script type="text/javascript" src="./ext/adapter/ext/ext-base.js"></script>
  <script type="text/javascript" src="./ext/ext-all-debug.js"></script>
  <script type="text/javascript" src="./application.js"></script>
  <title>A Big Application</title>
</head>
<body></body>
</html>

Although you can do with the above file I would recommend to add a descriptive header to not only this file but to all files you create. Also an “End of file” marker has its value. See File Patterns for example of such headers.

application.js

We need a file where the onReady function will be placed; let’s call it application.js. Minimum content is:

// vim: sw=4:ts=4:nu:nospell:fdc=4
/**
* An Application
*
* @author    Ing. Jozef Sakáloš
* @copyright (c) 2008, by Ing. Jozef Sakáloš
* @date      2. April 2008
* @version   $Id$
*
* @license application.js is licensed under the terms of the Open Source
* LGPL 3.0 license. Commercial use is permitted to the extent that the
* code/component(s) do NOT become part of another Open Source or Commercially
* licensed development library or toolkit without explicit permission.
*
* License details: http://www.gnu.org/licenses/lgpl.html
*/
 
/*global Ext, Application */
 
Ext.BLANK_IMAGE_URL = './ext/resources/images/default/s.gif';
Ext.ns('Application');
 
// application main entry point
Ext.onReady(function() {
 
    Ext.QuickTips.init();
 
    // code here
 
}); // eo function onReady
 
// eof

Your header and footer may vary but sure you need to set Ext.BLANK_IMAGE_URL to point to your server. This is path to 1×1px transparent image file that is used by Ext as an image placeholder and if it points to an invalid location you can get various rendering problems such as missing combo trigger images, missing icons or similar.

You may also need to create a new global object variable for your application (here it is Application).

What you need for sure is Ext.onReady that is the main application entry point – the place where you write your application.

css/application.css

You will put your css stylesheet to this file, if any. If you need only a couple of rules it may seem as unnecessary to create a separate file for them and it looks like the better idea to put them to <style> tags in the page head.

The reverse is true, remember you’re writing a big application, so everything has to have its place. If you put styles in the page head sooner or later you will solve some rendering problems and you won’t know where the styles are.

The wrong way

What normally follows when we have all basics in as we have at this point? Let’s begin writing. So we sit down and we start to write:

var vp = new Ext.Viewport({
layout:'border'
    ,items:[
        new Ext.grid.GridPanel({
            store:new Ext.data.Store({
                proxy:new Ext.data.HttpProxy({ ...

Wait a minute. This way we will have 10,000 lines in our application.js very soon and that is what we want last. Obviously, some step is missing as if we’re going to create such a big file why we couldn’t write it in index.html in the first place?

The right way: Break it apart

Even the most complex whole consists of smaller system which consist of smaller parts which consist of some elements. Your to-be-written big application is not an exception. Now it is the time to identify this parts, components and relationships between them.

So, sit down, think it over, draw a sketch, make a list, whatever but result has to be that you know the components, at least most important ones, your application will consist of.

Pre-configured classes

Now, that you are done with application analysis and identifying its components you can start to write the first one. But how? The best approach is to write extension classes of Ext components that have all configuration options, otherwise passed as the configuration object, built-in. I call such extensions pre-configured classes as they rarely add much functionality to base Ext ones but the main purpose of having them is to have them configured. For example, to have a “Personnel” grid with personnel specific column model, store, sorting options, editors, etc.

If we had such, our configuration of a Window could look like:

var win = new Ext.Window({
     title:'Personnel'
    ,widht:600
    ,height:400
    ,items:{xtype:'personnelgrid'}
});
win.show();

Writing a pre-configured class

Let’s take an example to discuss:

Application.PersonnelGrid = Ext.extend(Ext.grid.GridPanel, {
     border:false
    ,initComponent:function() {
        var config = {
           store:new Ext.data.Store({...})
          ,columns:[{...}, {...}]
          ,plugins:[...]
          ,viewConfig:{forceFit:true}
          ,tbar:[...]
          ,bbar:[...]
        }; // eo config object
 
        // apply config
        Ext.apply(this, Ext.apply(this.initialConfig, config));
 
        Application.PersonnelGrid.superclass.initComponent.apply(this, arguments);
    } // eo function initComponent
 
    ,onRender:function() {
        this.store.load();
 
        Application.PersonnelGrid.superclass.onRender.apply(this, arguments);
    } // eo function onRender
});
 
Ext.reg('personnelgrid', Application.PersonnelGrid);

What we’re doing here? We’re extending Ext.grid.GridPanel creating the new class (extension) Application.PersonnelGrid and we are registering it as the new xtype with name personnelgrid.

We are giving the general grid panel all the configuration options needed to become the specific personnel grid. From this point on we have a new component, a building block for our application that we can use everywhere (window, border panel region, standalone) where the list of personnel is needed. We can create it either as:

var pg = new Application.PersonnelGrid();
 
// or using it's xtype
var win = new Ext.Window({
     items:{xtype:'personnelgrid'}
    ,....
});

Organizing pre-configured classes

The code above does not need to and should not run within the onReady function because it has nothing to do with DOM structure; it only creates a new javascript object. Therefore it can and it should be written in a separate file (js/Application.PersonnelGrid.js) and it can and must be included in the index.html header as:

<script type="text/javascript" src="./js/Application.PersonnelGrid"><script>

So far so good, we have almost everything in place and (almost) all we need to do more is to continue writing our pre-configured classes, put them in ./js; directory, include them in index.html and build your application from instances of them as puzzle is assembled from pieces.

Looks good, yeah?

Anyway, there is a bit more to it.

Inter component communication

Imagine that we need a border layout with a link list in the west and tab panel in the center region. Clicking a link in the west would create a new tab in the center. Now, where should we put the logic of it, event handler and creation routine? In the west, or in the center?

Neither of them. Why? If we have a pre-configured class that creates and displays the west link list and we put the above logic in it it can no longer exist without center region. We just cannot use it without center as then we have no component to create tabs in.

If we put it in center, the result is same: center cannot exist without west.

The only component that should be aware of the existence of both west and center panels is their container with the border layout and this is the only right place where to put inter-component communication.

What should we do then? The container (with border layout) should listen to events fired by the west and it should create tabs in the center as responses to these clicks. The example of the component communication written this way can be found here: Saki’s Ext Examples

Production Systems

As we keep on writing our application we happen to have large number of included javascript files very soon (I have around 80 includes in one application at present and this number grows every day). This can degrade performance of a production system.

The best way to solve it is to concatenate all javascript files in the right order to create one big and to minify it with some of the javascript minfying or compression tools. Also, you do not need debug version of Ext Library for production systems.

We would include:

• ext-all.js
• app-all.js and
• application.js

on a production system.

Conclusion

It’s almost all there is to it… There are specific techniques for specific Ext classes, there is a lot of another server and client side know-how but the above is the overall concept.

Happy coding!

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