您的位置：首页 > 移动开发

ExtJS建立大型项目应用教程实例总结Tutorial:Writing a Big Application in Ext

2009-03-11 10:49 756 查看

ExtJS建立大型项目应用教程实例总结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

Русский

Português

[hide]

1 Preface

2 What is "A Big Application"?

3 Files and Directories

3.1 index.html

3.2 js/application.js

3.3 css/application.css

4 The wrong way

5 The right way: Break it apart

6 Pre-configured classes

6.1 Writing a pre-configured class

7 Organizing pre-configured classes

8 Inter-component communication

9 Production Systems

10 Conclusion

11 See also

if (window.showTocToggle) { var tocShowText = "show"; var tocHideText = "hide"; showTocToggle(); }

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'
    ,width:600
    ,height:400
    ,items:{xtype:'personnelgrid'}
});
win.show();

Writing a pre-configured class

[Note: The following structure may not work in all situations, for some exceptions please see this post.]

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!

ExtJS建立大型项目应用教程实例总结Tutorial:Writing a Big Application in Ext