Writing a Big Application in Ext
12. April 2008 – 23:2012. April 2008 – 23:20Preface
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: Jain which is combination of Ja = Yes and Nein = No.)
The answer to both above statement is Jain. 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, ./phpare 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 pointExt.onReady(function() { Ext.QuickTips.init(); // code here }); // eo function onReady // eofYour 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() { 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 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 xtypevar 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!
扫一扫
427
到【灌水乐园】发言
11 Responses to “Writing a Big Application in Ext”
Very interesting post ! I was searching how to structure a big app since yesterday and you just posted this article. Thanks a lot.
By kilgore on Apr 13, 2008
Very nice introduction…
By Lucian on Apr 13, 2008
Wow, impressive tutorial! Thanks for sharing!
By paolo on Apr 13, 2008
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
By Ami on Apr 14, 2008
All of you are welcome.
I’m always glad if I can help to create understanding.
Good luck with Ext.
By jsakalos on Apr 14, 2008
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
By Fotios Kossyvas on Apr 14, 2008
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
By Michael Hodgson on Apr 14, 2008
@Michael
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.
By jsakalos on Apr 14, 2008
Thanks for that!
By TomSta on Apr 16, 2008
Hi,
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.
By Ben on Apr 16, 2008
@Ben,
post please this query to Forums and send me the link via PM (I only handle Premium Help).
By jsakalos on Apr 16, 2008