Writing a Big Application in Ext (Part 1)

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


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)

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)



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.



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

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.



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:

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:


Writing a pre-configured class

Let’s take an example to discuss:

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:


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.



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.

Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone
Follow me:


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)


  1. Ami says

    Thank you Sooooooooooo much!!!

    been looking for this for over a 2 weeks

    no one would point me to any idea

    Your website is THE Learn Link from extjs.com

    it has everything i have been looking for.

    Thanks again for saving me tons of forums and IRC headaches.

    Greatly appreciate it
    Ami Mahloof

  2. says

    Thank you for this tutorial, it is really helpful for me. This was the tutorial i have had always searched in the Ext forums (for more than a year) and now you’ve made it!
    Great job

  3. Michael Hodgson says

    Really useful. I’ve been using Ext for about 4 months now and remember looking for a guide on how to lay out applications back then without much satisfaction.

    Have just spent the afternoon re factoring our small development app into this kind of structure and already am finding it easier to explain to our team where to look to do bug/code fixes or to copy stuff from to increase their understanding.

    I see your CAPTCHAs are almost as hard to read as Jacks :) I must be going blind

  4. says

    I also click “Request new image” several times until I get something readable… I’m new to wordpress – this plugin worked…

    To the matter: I’m glad you’re organizing your app this way and even more glad that it brings good results.

  5. Ben says


    I am new to EXTJS and JavaScript as well.
    I did exactly as you did in creating the Application namespace and render a pre-compiled class. But i am getting an error saying “Application.personnelgrid is not a constructor” in firebug. Can you help me regarding the error.

  6. says

    Thanks for this great overview,

    I now use it in the Symfony-Extjs Generator. The edit/detailed-pages are now being constructed like this: http://fun4me.demon.nl/test/test_dev.php/js/city/editAjaxJs.pjs

    The demo can be seen here: http://fun4me.demon.nl/test/test_dev.php
    At the moment only clicking the add city (not country) button works, and you can click on the cities but the datastore is not setup yet, so nothing gets loaded/shown, nor can be saved.

    The formpanel-layout gets lazy-loaded by another script called using.js

  7. cafebabe says

    I love writing structured applications, love having things consistent and organized. It’s been said but like to say it again, THANK YOU for taking the time to put this together along with all of the other code snippets, forum posts, tutorials, and extensions you’ve done. It helps A LOT when diving into ext and trying to not reinvent the wheel or stray from the path set forth by the API designers.

  8. JoyfulBob says

    Thanks for this solution! It’s going to be a great solution for us; we’ll be developing lots of EditorGrids that’ll be placed in tabs in a Layout.

    I have a question though. In the pre-configured grid, you’ve got a toolbar. Let’s say inside it the handler(s) call function(s). Where do you code for these associated functions?
    I’ve coded this way and it works; my xtype grid displays in my layout… however! In my grid I’ve got a toolbar button that deletes grid rows. I don’ know where to put my delete functions; everywhere I try I get errors.
    Does my delete function go
    1.) inside the initComponent
    2.) outside it but before the onRender
    3.) Outside the grid function
    4.) or somewhere else?

    Thanks in advance?


We will be happy to hear back from you

Please Login to post a comment