If you modify records of an editable grid with paging and if you then page-out, your changes are lost. Well, they are not lost in fact unless you have set pruneModifiedRecords:true on the strore. The modifications are still available so we just need to apply them. Here is the code fragment that does it:

var grid = new Ext.grid.EditorGridPanel({
    store:new Ext.data.Store({
         listeners:{
            load:{scope:this, fn:function(store) {
 
                // loop through modified records
                var modified = store.getModifiedRecords();
                for(var i = 0; i < modified.length; i++) {
 
                    // see if we have a record with same id 
                    // and apply changes if yes
                    var r = store.getById(modified[i].id);
                    if(r) {
                        var changes = modified[i].getChanges();
                        for(p in changes) {
                            if(changes.hasOwnProperty(p)) {
                                r.set(p, changes[p]);
                            }
                        } // eo changes loop
                    }
                } // eo modified loop
            }} // eo load listener
        } // eo listeners
 
        // rest of store configuration
 
    })
 
    // rest of grid configuration
 
}) // eo grid

pruneModifiedRecords must be false (the default) for this to work.

Hi,

I’ve just uploaded a full-fledged example of combo with remote store at http://examples.extjs.eu.

Enjoy!

You know, I’m not very big fan of factory functions, nevertheless, I’m aware of the fact that they may be necessary in some situations. Here is the file pattern that works (briefly tested).

Keep each factory function in a separate file name of which should be Namespace.Factory.functionName.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

// vim: ts=4:sw=4:nu:fdc=4:nospell
/*global Ext, MyNamespace */
/**
 * @class MyNamespace.Factory
 *
 * A Factory function pattern
 *
 * @author    Ing. Jozef Sakáloš
 * @copyright (c) 2009, by Ing. Jozef Sakáloš
 * @date      17. March 2009
 * @version   0.1
 * @revision  $Id$
 *
 * @license MyNamespace.Factory.myPanel.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.
 * 
 * <p>License details: <a href="http://www.gnu.org/licenses/lgpl.html"
 * target="_blank">http://www.gnu.org/licenses/lgpl.html</a></p>
 */
 
// create namespace
Ext.ns('MyNamespace.Factory');
 
/**
 * @method myPanel
 * @param {Object} config
 * A config object
 * @return {Ext.Panel}
 */
MyNamespace.Factory.myPanel = function(config) {
 
	// pre-instantiation code
	var defaults = {
		// put your defaults here
		// but avoid id, el, contentEl, renderTo, applyTo, or similar
	}; // eo defaults object
 
	// create config object
	var cfg = Ext.apply({}, config, defaults);
 
	// instantiate
	var cmp = new Ext.Panel(cfg);
 
	// post-instantiation code
 
	// return the created component
	return cmp;
 
} // eo function MyNamespace.Factory.myPanel
 
// eof

Important

If you have not already done so, study Writing a Big Application in Ext (Part 1) and Writing a Big Application in Ext (Part 2)before you read this article. It would be very hard, if not impossible, to understand concepts explained here before you fully understand the first and second part.

Introduction

Helping on the forum and reading code of others that failed to extend Ext classes, revealed more errors that users, especially beginners, commonly make. Therefore, I’ve decided to start this article that will collect these errors and will explain why the errors are errors. I mean it as loosely ended as I may discover more errors and ways of avoiding them so I plan just to add them to this article, not endlessly create parts 4, 5, etc…

… continued: Most Common Sources of Troubles

Here we go:

1. Unnecessary Extending
2. Adding Objects to Prototype
3. Hard Coding ids

Unnecessary Extending

The main reasons for extending are:

• re-usability
• adding functionality
• combination of them

so we extend if we need a re-usable component or we need to add a functionality (new methods) or both. If we are after re-usability the extension can be as simple as:

1
2
3
4
5

MyPortlet = Ext.extend(Ext.Panel, {
     anchor:'100%'
    ,draggable:true
    ,defaultType:'mygraph'
});

You see what happens? We are going to use MyPortlet many times so instead of scatter the above configuration in 10,000 lines application code 100 times, we create this simple extension and we save 297 lines of code.

The other aspect is that if we upgrade our ‘mygraph’ to ‘mygraph_new’ the only place where to change it is our extension saving us searching out code for all occurrences of ‘mygraph’ (100 times) and replacing it with ‘mygraph_new’ 100 times.

(Well, 100 is exaggerated, but you get the point, right?)

If we are after adding functionality, which can be also simple, we add some “logic”:

1
2
3
4
5
6

MyPanel = Ext.extend(Ext.Panel, {
    onRender:function() {
        MyPanel.superclass.onRender.apply(this, arguments);
        alert('Rendered');
    }
});

Here we add some logic to Panel, it does more that it did before.

There is no need to extend in all other cases.

Adding Objects to Prototype

Run this code first:

<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">
  <script type="text/javascript" src="ext/adapter/ext/ext-base.js"></script>
  <script type="text/javascript" src="ext/ext-all-debug.js"></script>
  <title id="page-title">Extending Error: Object in prototype</title>
  <script type="text/javascript">
  Ext.BLANK_IMAGE_URL = 'ext/resources/images/default/s.gif';
  Ext.onReady(function() {
    MyPanel = Ext.extend(Ext.Panel, {
         layout:'fit'
        ,panelConfig: {
            bodyBg:'red'
        }
 
        ,initComponent:function() {
            var config = {
                bodyStyle:'background-color:' + this.panelConfig.bodyBg
            }; // eo config object
 
            // apply config
            Ext.apply(this, Ext.apply(this.initialConfig, config));
 
            MyPanel.superclass.initComponent.apply(this, arguments);
        } // eo function initComponent
 
        ,applyBackground:function(color) {
            this.panelConfig.bodyBg = color;
            this.body.applyStyles({'background-color':color});
        } // eo function applyBackground
 
    }); // eo extend
 
    var p1 = new MyPanel({
         title:'Panel with Blue Background'
        ,renderTo:Ext.getBody()
        ,width:240
        ,height:160
    });
 
    p1.applyBackground('blue');
 
    var p2 = new MyPanel({
         title:'Panel with Red Background'
        ,renderTo:Ext.getBody()
        ,width:240
        ,height:160
    });
 
  });
  </script>
</head>
<body></body>
</html>

What do we expect? It is written in titles of panels: Top panel (p1) should have blue body background because we set it to it after it is created. And bottom panel (p2) should have red because we just create default MyPanel.

But it is blue too!!! Why? The reason is simple: panelConfig is object that is created during class definition and it is added to MyPanel prototype. Objects (arrays too) are accessed by reference so p1 and p2 share the same instance of panelConfig. Setting bodyBg property in applyBackground method changes this single instance of panelConfig object. So we create p2 with blue background too.

You see, here it is clearly and immediately visible that something went wrong but making this error can lead to weeks of wasted debugging time in real applications. Imagine you have a store in prototype…

Hard Coding ids

Very simple, but deadly mistake is to set ids in the extension either to the main extension object or on its items, toolbars, buttons, etc. If a hard coded ids are set we cannot create two or more instances of our extension, can we?

Loose End

That’s all for now but if I discover more errors I will add them above.

Stay tuned!

Do not forget to read Part 1 and Part 2 of this article.

Follow up: Factory Functions in Ext Extensions (Abstract Classes)

Suppose we want to remove all children of the node node:

while(node.firstChild) {
    node.removeChild(node.firstChild);
}

That’s all there is to it

Important

If you have not already done so, study Writing a Big Application in Ext (Part 1) before you read this article. It would be very hard, if not impossible, to understand concepts explained here before you fully understand the first part.

Introduction

It has been almost one year since I have published the first part of this article. I have been successfully using the concept of pre-configured classes personally to write a really big application (~150 javascript files, ~60,000 lines of code, plus server-side and css). The application is fully modularized, each class in separate file and it has proven that it can be easily developed, managed and debugged.

Unfortunately, the same has not been always true for other users, they were hitting various problems and Ext Support Team have had to handle may questions and help requests. These accumulated to the degree where the concept has been called “absolute abomination” (read absolutely hated) and it was stated that “it causes problems”.

Note: As “fast cars” do not cause accidents but “slow drivers driving fast cars” do, the concept itself cannot be a cause of the problems but its application can.

In any case, there must be some illogic if I can use the concept but others cannot.

Thus, I have looked deeper in it and I have isolated some pitfalls the users can run into on the course of development. I will also write on “dos” and “don’ts” and on when to use a pre-configured class and when not. I will not compare this concept to another application design concepts (factory functions, in-line configuration, on-demand load, or other) because 1) I do not use them and 2) I do not want to turn this article into a Linux versus Windows discussion.

It is fully up to you which application design concept you choose. However, if you do choose this one then follow the rules I’m going to lay down.

Most Common Sources of Troubles

• Dull Copy&Paste
• Extending a non-Ext.Component class
• Not calling parent methods
• initialConfig
• listeners

Dull Copy&Paste

Do you know such people? They post on a forum:

I need to drag from tree to qrid, gimme plz complete codez

And if somebody altruistic writes a fragment of “codez” for him in a sheer attempt to help the response is going to be:

Your codez don’t work. Help me plz my manager wants it working

Do you see what happened? A dull “developer” ordered a code on the forum, he’s got some, copied&pasted it to his application without a clue what the code does, maybe hasn’t even changed url that still points to your server and the result is: it doesn’t work.

Well, this is an extreme (but not so rare as you would think), nevertheless, copying&pasting without understanding of what the copied&pasted code does can lead only to frustrations.

I am not against Copy&Paste in general, it can save a lot of time and I also occasionally do it, but I am against not-understanding or mis-understanding not only of coding but also of life.

The Rule: Do Copy&Paste but always with full understanding of what the code does.

Extending a non-Ext.Component class

If an Ext class does not inherit from Ext.Component the initComponent is never called so the code you have written there is never executed. This is fragment from Ext.Component constructor:

1
2
3
4
5
6
7
8
9

    this.getId();
    Ext.ComponentMgr.register(this);
    Ext.Component.superclass.constructor.call(this);
 
    if(this.baseAction){
        this.baseAction.addComponent(this);
    }
 
    this.initComponent();

Ext classes that do not inherit from Ext.Component do not have this.initComponent(); line in their constructors.

The Rule: Always check if the Ext class you are going to pre-configure inherits from Ext.Component. You have to use an another approach if it does not.

Not calling parent methods

It happens very often that you do not only add some methods in your extended class but that you modify existing ones. initComponent being the first example. onRender, afterLayout are other (but not only) frequently overriden methods.

These methods are already implemented in the class you are extending and its parents so if you forget the line:

// in initComponent override
YourExtension.superclass.initComponent.apply(this, arguments);
 
// or in onRender override
YourExtension.superclass.onRender.apply(this, arguments);
 
// or in afterLayout override
YourExtension.superclass.afterLayout.apply(this, arguments);

your class will not work.

The Rule: Never forget to call the parent method, unless you exactly know what you are doing.

initialConfig

The constructor of Ext.Component saves the config passed to it as initialConfig:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

    /**
     * This Component's initial configuration specification. Read-only.
     * @type Object
     * @property initialConfig
     */
    this.initialConfig = config;
 
    Ext.apply(this, config);
    this.addEvents(/* abbreviated for clarity */);
    this.getId();
    Ext.ComponentMgr.register(this);
    Ext.Component.superclass.constructor.call(this);
 
    if(this.baseAction){
        this.baseAction.addComponent(this);
    }
 
    this.initComponent();

You see what happens? The constructor saves initialConfig before initComponent is executed. Thus, all configuration you write in initComponent is not saved. I have overlooked this in first versions of my templates and examples mainly because there is only a couple of classes that refer to initialConfig and even in these classes the absence of properly saved initialConfig causes problems very rarely. These Ext classes refer to initialConfig:

• AnchorLayout
• BorderLayout
• Action
• GridPanel
• Tip
• Combo
• Form

Now, I have updated all my examples, extensions, templates and main site to include this “magic” pattern:

1
2
3
4
5
6
7
8
9
10

// create config
var config = {
    // put your config here
}; // eo config object
 
// apply config
Ext.apply(this, Ext.apply(this.initialConfig, config));
 
// call parent
YourExtension.superclass.initComponent.apply(this, arguments);

The Rule: Ensure that your extension saves initialConfig.

listeners

If you try to install event handlers by setting property listeners in your config they will not work. Why? The answer lies again in the order of actions in Ext.Component constructor:

1
2
3
4
5
6
7

    Ext.Component.superclass.constructor.call(this);
 
    if(this.baseAction){
        this.baseAction.addComponent(this);
    }
 
    this.initComponent();

As you can see, the constructor calls its parent, that is Ext.util.Observable before initComponent. Ext.util.Observable constructor executes:

1
2
3
4
5
6

Ext.util.Observable = function(){
    if(this.listeners){
        this.on(this.listeners);
        delete this.listeners;
    }
};

Any listeners set in initComponent are thus ignored.

There is an easy workaround. Put constructor method in your extension:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

 
 constructor:function(config) {
    // parent constructor call pre-processing - configure listeners here
    config = config || {};
    config.listeners = config.listeners || {};
    Ext.applyIf(config.listeners, {
        // add listeners config here
    });
 
    // call parent constructor
    AnExtension.superclass.constructor.call(this, config);
 
    // parent constructor call post-processing
 
} // eo function constructor

and define your listeners therein.

The Rule: Define listeners in constructor method.

Conclusion

If you decide to use my way of writing a big application then follow these rules:

1. Do Copy&Paste but always with full understanding of what the code does.
2. Always check if the Ext class you are going to pre-configure inherits from Ext.Component. You have to use an another approach if it does not.
3. Never forget to call the parent method, unless you exactly know what you are doing.
4. Ensure that your extension saves initialConfig.
5. Define listeners in constructor method.

Happy extending!

Do not forget to read Part 1 and Part 3 of this article.

We need to know all events that are fired by a component and in which order sometimes. It is easy to find out.

Let’s say that the component in question has id my-comp. Load the page with the component, open Firebug, Console tab, and type:

Ext.util.Observable.capture(Ext.getCmp('my-comp'), console.info)

Now do some actions with the component and watch the Firebug output.

Historical Background

Most likely many of you who will read this article do not remember times of Fortran language and computers that were fed with tons of punch cards to have some some job done.

The main purpose of computers at that time was to compute something really; that is not true anymore because computers are used for getting computational result very rarely at schools or scientific institutions nowadays.

How did it work at that time? If you wanted a computer to run a program you went to a shelf with your punched cards, you found the drawer with the stack of them, fed them through card reader and the computer started your program.

First task was to ask for user inputs and once you filled them in the program computed the result, printed it and ended. Easy, straightforward, “single thread” job.

Events Introduced

With the invent of GUI and Mouse this concept of load-run-end just couldn’t work anymore as we needed some infinite loop that would wait for user actions (mouse movement and clicks) and that would process them to execute the required actions.

I has became clear very soon that putting the code that processes these action directly in that loop is the route to nowhere so the Event driven programming was born.

Event Definition

Event is a message, a function call, generated by one (part of) program, the event source, that notifies another (part of) program, the event listener, that something happened. Events are generated as responses to user actions or to state changes of the event source.

The event source is independent of event listeners and it generates events also if nobody listens or even if there is no listener defined. The viewpoint of our infinite loop would be: “I’m informing everybody that user moved the mouse to position [x,y] and I do not care who listens, if anybody.”

The viewpoint of the listener would be: “Let me know when user moves the mouse, I need to do something with it.”

Events in Ext

There are two main “sorts” of events in Ext: DOM events and JavaScript, or software, events.

DOM Events

Browsers that display (X)HTML pages already have our “infinite loop” that watches user actions and fires events if these actions are occurring on DOM elements. Before Ext we were used to install event listeners on DOM elements this way:

<div id="mydiv" onclick="alert('You clicked me')">Click me!</div>

Ext.Element wraps DOM elements together with their events so now we install the same event handlers this way:

Ext.get('mydiv').on('click', function() {alert('You clicked me');});

It can be said that DOM events are “passed-through” from DOM through Ext.Element to listeners.

JavaScript Events

Now, DOM elements are not only possible event sources; it is quite easy to implement event source logic and event listener installation to any JavaScript object. But, what could it be good for?

Imagine that you have a complex component such as grid. If you had only DOM events, the handling of user actions such as column move would be extremely difficult. You would need to listen to DOM elements, process mouse clicks, moves, calculate from where to where the column has been moved, etc. If would be much easier if grid component would do all this dirty work for you and, after everything has be done, just informed you: “User moved column 3 to position 1.”

That is exactly what grid does: it fires JavaScript events that inform potential listeners what has happened to it. The same is true for another Ext components. Form validation events, Panel resize events, Tree expand/collapse events can serve as examples, to name a few.

How do I listen to events?

If you have an object of Ext class, for example Panel, and you need to do some action when panel resizes you would install a listener to implement your action:

// create panel
var myPanel = new Ext.Panel({...});
 
// install resize event listener
myPanel.on('resize', function(panel, w, h) {
    alert('Panel resized to ' + w + 'x' + h);
});

From this point on, whenever the panel myPanel is resized your function is called so you can do your actions.

How do I create event source?

Events related functionality is implemented in Ext.util.Observable class so if you want your extension to be an event source just extend Observable. Also, if you extend a class that is already descendant of Observable (Panel, Grid, Form, Tree, etc), your extension is automatically the event source.

Events fired by your extension are events fired by parent class(es).

Custom Events

It happens very often that you need add new events, for example you create Employee class and Organization Chart class and you implement drag&drop assignment/dismissal of employee to/from a position. I would come handy to fire event assigned and dismissed, wouldn’t it?

We could listen to these events and the listeners could send e-mails to the employee informing him that he has been assigned to a position or dismissed from it.

We do it this way:

OrgChart = Ext.extend(Ext.Panel, {
    initComponent:function() {
        // call parent init component
        OrgChart.superclass.initComponent.apply(this, arguments);
 
        // add custom events
        this.addEvents('assigned', 'dismissed');
    }
 
    ,assign:function(employee, position) {
        // do whatever is necessary to assign the employee to position
 
        // fire assigned event
        this.fireEvent('assigned', this, employee, position);
    }
 
    ,dismiss:function(empoyee, position) {
        // do whatever is necessary to dismiss employee from position
 
        // fire dismissed event
        this.fireEvent('dismissed', this, employee, position);
    }
});

In the initComponent function we inform Observable class that we are going to fire our new events so it can do all necessary setup.

Note: We do not extend Observable directly here but Panel, what we extend, does. Panel’s inheritance chain is: Observable -> Component -> BoxComponent -> Container -> Panel.

And in assign and dismiss functions we fire our events after all assign/dismiss job has been done with signature (arguments) of our choice.

When we fireEvent, Observable looks if there are some listeners to this event and calls all listeners with arguments we supplied in fireEvent call. If there is no listener it just does nothing.

Summary

• event is a message sent (fired) by an event source to inform listeners that something happened
• event source is an object that can fire events
• event listener is a function that is called when event source fires an event
• to listen to events we use on function to install an event listener
• to create an event source we extend Observable class, addEvents and fireEvent

Enjoy firing your events and listening to them!

Preface

I believe that many of Ext users have already thought about adding some custom functionality that is not present in core Ext Library to a class. Something that is specific to their applications or not that specific so that others could also be interested in such feature.

OK, we have the idea, we know what the new code should do, we even know how to write it, but what should we write? An Extension or a Plugin?

Extensions and Plugins

The fact we are talking about them together and the fact that we can be even indecisive which one to use infers that they must have something in common. True, they have. They both add some functionality to an existing library or modify a feature of the library.

Neither extension nor plugin can exist standalone; they have to have a component, a class, they extend or plug into.

Extension

An extension (in Ext world) is a derived class in fact. Let’s imagine we have a basic class with some general methods to which we want to add some more specific methods. So, using the inheritance framework of an library or a language we create new class that contains methods of both basic class and new added methods.

We choose an existing Ext class, we extend it using Ext.extend function and the result is new class with new name. For example:

MyExtension = Ext.extend(Ext.Panel, {/* object with new properties and methods */});

Later on, when we need an object:

var myExtension = new MyExtension({/* optional configuration object */});

Plugin

Plugin does not need any exiting Ext class to exist. Although plugins often extend Ext.util.Observable it is not a must; they can be written from scratch. Sure, writing a plugin without having a target we want to plug it in has no sense so we always write plugins for an existing Ext class: panel, form, grid, data view, etc.

For example, we create plugin as:

MyPlugin = function() {/* code */};

And then we use it this way:

var myPanel = new Ext.Panel({
     plugins:[new MyPlugin({/* optional config object */})]
    ,// rest of myPanel configuration
});

Extension or Plugin?

It depends… You can often achieve same result with extension or with plugin. Sometimes it is only that programmer likes plugins more so he writes a plugin or he likes extensions more so he writes an extension. However, plugins are more suitable for adding smaller features and extensions are more suitable for adding more complex functionalities. Plugins can be easily removed from components, extensions are usually more tied to applications.

Summary

• An extension is a new class with a new name, based on an existing base class and created at definition time. Extension must be instantiated as any other class to work.
• Plugin plugs into an existing class, is easily removed, is defined during definition time and is initialized during base class initialization.

Further reading

• Extending an Ext Class
• Writing an Ext Plugin

If you want to see permissions of a file or a directory in both human readable and octal notation issue this command:

stat -c "%n %a %A" /tmp # replace /tmp with your file/dir

The output is as follows:

/tmp 1777 drwxrwxrwt