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:

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 1x1px 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:

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.

• Author
• Recent Posts

Follow me:

saki

I'm a well seasoned developer, consultant and educator of web applications based mainly on Sencha libraries, PHP, MySQL and Node.js. Besides (Apple) computers, I love photography and mountain biking.

Follow me:

Latest posts by saki (see all)

• Ext, Angular, React, and Vue - 27. June 2019
• The Site Resurgence - 11. February 2018
• Configuring ViewModel Hierarchy - 19. June 2015