用EXT写大型应用（Writing a Big Application in Ext）

Tutorial:Writing a Big Application in Ext

From Learn About the Ext JavaScript Library

Jump to: navigation, search

Summary: This tutorial helps you to write a big application in Ext.

Author: Jozef Sakalos

Published: April 12, 2008

Ext Version: 2.0+

Languages:

English

[hide]

Preface

I have decided to write this article for those users of Ext 2.x that have already grown up from children's diapers of 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 the number of solutions to it is equal to the number of people that tackle it. The way I am going to describe in the following text is not the only one, and I 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 maintainable --- 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 big application, right?

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

The answer to both above statements is Jein. When does the application become 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 a number of files or 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 DocumentRoot 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 when you, for example, download a new Ext version to a real directory, then you just 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, just change the link back.

css will hold all your stylesheets. If you have global stylesheets with company colors or fonts you can create the css directory as a link too.
ext link you your Ext JS Library tree as described above
img link to your images. It can contain an 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="./js/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.

js/application.js

We need a file where the onReady function will be placed; let's call it application.js. Its 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 the path to a 1x1 px 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, if any, into this file. If you need only a couple of rules it may seem as unnecessary to create a separate file for them, and it looks like a better idea to put them into <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 have to solve some rendering problems and you won't know where the styles are.

The wrong way

What does normally follow 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 couldn't we write it in index.html in the first place?

The right way: Break it apart

Even the most complex whole consists of smaller systems 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 these parts, components and relationships between them.

So, sit down, think it over, draw a sketch, make a list, whatever, but the result has to be that you know the components --at least the 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 extension 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() {
        Ext.apply(this, {
             store:new Ext.data.Store({...})
            ,columns:[{...}, {...}]
            ,plugins:[...]
            ,viewConfig:{forceFit:true}
            ,tbar:[...]
            ,bbar:[...]
        });
 
        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 are we doing here? We're extending Ext.grid.GridPanel creating a new class (extension) Application.PersonnelGrid, and we are registering it as a 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 its xtype (lazy instantiation):

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 the 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.js></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 into the ./js directory, include them in index.html and build our application from instances of them, as a 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 a 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?

In 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 the center region. We just cannot use it without the center, as then we have no component to create tabs in.

If we put it in the center, the result is the 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. An 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 file, and to minify it with some of the JavaScript minifying or compression tools. Also, you do not need the debug version of the Ext library for production systems.

On a production system we would include:

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

For additional information about minimizing your source and creating combined build files, we have another tutorial that covers this topic in depth.

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!