new Ext.XTemplate('{0:plural("record","records")} deleted').apply([4])
// -> 4 records deleted

This is nice. Yet the formatting functions are not limited to just a few. Templates support all formatting functions in Ext.util.Format. What’s even better is that you can add your own formatting functions and have them in the templates.

One use case for this usage of templates is displaying user feedback in a label or tooltip when deleting records in a grid, or selecting records. In order to be accurate and give a nice user experience, it would be nice to output: ‘No records selected’, and not ‘0 records selected’; ‘One record selected’, and not ‘1 record selected’. So, a nice solution would be the following:

(function() {

    Ext.apply(Ext.util.Format,{

        /**
         * Label plural formatter : lplural - to be used with templates
         *
         * @param value {Number} number
         * @param singular {String} singular form
         * @param plural {String} plural form
         * @param zero {String} zero form
         * @param addPluralValue {Boolean} whether to add
         *            the value in the plural form
         */
        lplural: function(value, singular, plural, zero, addPluralValue){
            //make the text for the zero quantity be optional
            if (zero && !value){
                return zero;
            }

            //also the addPluralValue flag is optional - if it is true,
           //also return the value: eg - 5 records
            plural = addPluralValue? (value + ' ' + plural) : plural;

            return value != 1 ? plural : singular;
        }
    })

    Ext.onReady(function(){

        var t = new Ext.XTemplate('{0:lplural("one record","records","no records", true)}');

        //add plural value
        console.log(t.apply([5])) // -> 5 records

        console.log(t.apply([0])) // -> no records
        console.log(t.apply([1])) // -> one record

        var t = new Ext.XTemplate('{0:lplural("one record","records", null , false)}');

        //don't output the '5'
        console.log(t.apply([5])) // -> records
       //haven't provided a text for zero, so defaults to the plural form
        console.log(t.apply([0])) // -> records
    })
})();

I really think templates are very powerful, so use them! Any other clever usages? (besides all the ext4 being built on top of them )

1. Keep the DOM small. I know all the DOM elements in ExtJS have a reason and they are needed in order to have nicely rounded corners in all browsers and consistent behavior. Yet it’s quite too much, especially for large applications. I am currently developing a large web 2.0 application with ExtJS and on older browsers the performance is a big issue (you should read IE 7 and 8). The application behaves well with Firefox 3.5+ and runs the smoothest with Chrome. But when having more than just 2,3 windows and a simple grid, when you have live events and Comet notifications, stores sharing data and large UI controls, you have to start thinking on how to keep everything running smoothly. The next points touch on keeping the DOM small as well.
2. Drop IE 6 support. We all hate it. Google dropped it and so should the team at Sencha. All the DOM elements are needed for old browsers like IE 6. But we could drop support for it and have a smaller DOM, so better performance and happier users. Those who still need IE 6 can continue on the 3.x ExtJS branch. Come on, we now have HTML5 and CSS3. I know the adoption is not the best, but hey, we are web developers, let’s push at least for a minimum subset of it to be out there.
3. Integrate Raphael graphs. It was nice to see Sencha being formed and acquiring Raphael and jqTouch. We now saw jqTouch contributing to Sencha Touch. The next normal step I think is to integrate Raphael graphs into ExtJS. I really suppose this is the intention, but let’s mention it upfront, just in case. It’s nice to have charting, but Flash is not the best sollution.
4. Give us an integrated test platform. Testing is important, but we don’t see it so often in our own ExtJS apps. Yes, we test with Selenium, and this is a great tool, but show us the testing framework in ExtJS. As far as I know, the Sencha team is using a customized YUI Test framework. Would be nice if they shared it, so we can all benefit.
5. Custom theming. This is a well known issue, but let’s just recap we need this. ExtJS would benefit from a much larger adoption if they had an easy way to build themes, like the jQueryUI theme roller. Let’s face it, on this issue, jQuery is far more attractive. I didn’t like to say it, but that’s the truth. With the help of a designer I have put up a custom theme, and yes…. you have a bit of headache. It’s not like you’re building it in one day, if you want something a bit more complicated and flashy. It was nice to see SASS being used in Sencha Touch. This is a first step towards easy, custom theming.
6. Distribution builder. ExtJS is very nice, but sometimes you just need a bit of it. You just want a window and a grid, so importing the whole library is quite expensive. I know this was present with the ExtJS 2 distribution, and let’s hope we’ll have it back again. A workaround on this would be using the Google Closure JavaScript Compiler to have the unused code removed from our apps. Then we would still have problems with the ‘xtype‘ config, and would probably need to artificially instantiate all the components which have their xtype used in the application. Anyway, this is just an idea to try out, but it would be nice to have something from the official distribution.

These are not all the issues that would be nice to have, but at least the most important that come to mind. It’s nice to see the ExtJS ecosystem at work and new components popping up, like the pivot grid, the calendar etc.

So… looking forward to ExtJS version 4 and hoping to see that many (why not all?) of these issues find their way into the framework. Looking forward to see the great work! Keep up!

NOTE: I know there are the activate and deactivate events on every window, but when a window triggers the ‘deactivate’ event, Ext.WindowMgr.getActive() still returns it as the active window. This is why I needed the ‘tofront’ and ‘toback’ events.

(function(){

    // get the previous implementation of the toFront method
    var prevToFront = Ext.Window.prototype.toFront;

    Ext.override(Ext.Window, {

        toFront: function(){

            //get the window manager of this window, or Ext.WindowMgr if it doesn't have one
            var manager = (this.manager || Ext.WindowMgr);
            //get the window which is currently to front
            var activeWindow = manager.getActive();

            prevToFront.apply(this, arguments);

            //only fire tofront and toback events if the current window was not already to front
            if (this != activeWindow){
                this.fireEvent('tofront');
            }

            if (activeWindow){
                activeWindow.fireEvent('toback');
            }

            return this;
        }

    });
})();

I needed to run code both before and after the default implementation of the toFront method. If I didn’t need this, an easier approach would have been to use createSequence:

Ext.override(Ext.Window,{
       toFront: Ext.Window.prototype.toFront.createSequence(function(){
             // code here.
       })
})

Nice ExtJs! Go try it!

Here is the code for this:

(function(){
    //put all the code in an anonymous function to hide the local variables from the global namespace

    //methods that will be overriden - keep the original
    var originalFilterKeys = Ext.form.TextField.prototype.filterKeys;
    var originalInitEvents = Ext.form.TextField.prototype.initEvents;

    Ext.override(Ext.form.TextField,{

        // private
        filterKeys : function(e){
            var res = originalFilterKeys.apply(this, arguments);

            var cc = String.fromCharCode(e.getCharCode());

            //if the caret is in the first position, and the typed character
            //was space, stop the event
            if (cc == ' ' && (this.getCaretPos(this.el.dom) == 0) ){
                e.stopEvent()
            }

            //the case when the text is selected and the user presses space
            if (cc == ' ' && this.getSelectedText() == this.getValue()){
                //clear value of the text field
                e.stopEvent();
                this.setValue('');
            }

            return res; //return original result
        },

        /**
         * @return String the selected text or '' if none
         */
        getSelectedText: function(){
            var dom = this.el.dom;
            var selected = (dom.value).substring(this.getSelectionStart(), this.getSelectionEnd());

            return selected;
        },

        getSelectionStart: function(){
            var input = this.el.dom
            if (input.setSelectionRange){ // Mozilla
                return input.selectionStart;
            } else if (document.selection) { // IE
                var pos, textRange = document.selection.createRange().duplicate();

                if (textRange.text.length > 0) { // selection is not collapsed
                    pos = input.value.indexOf(textRange.text);
                } else { // selection is collapsed
                    pos = 0;
                }

                return pos;
            }
            return 0;
        },

        getSelectionEnd: function() {
            var input = this.el.dom
            if (input.setSelectionRange){ // Mozilla
                return input.selectionEnd;
            } else if (document.selection) { // IE
                var selectedRange = document.selection.createRange().duplicate();
                if (selectedRange.text.length > 0){
                    selectedRange.moveStart("character", -input.value.length);
                }
                return selectedRange.text.length;
            }

            return 0;
        },

        /**
         * @return int - the current index of the caret
         */
        getCaretPos: function() {
            var input = this.el.dom;
            var pos = 0;
            if (input.createTextRange) {
                var range = document.selection.createRange().duplicate();
                range.moveStart('textedit',-1);
                pos = range.text.length;
            } else if (input.setSelectionRange) {
                pos = input.selectionEnd;
            }
            return pos;
        },

        // private
        initEvents : function(){
            this.maskRe = new RegExp('.*'); //I just needed a reg exp to match all characters
            //as filterKeys method is only called if the textfield has a 'maskRe' property
            return originalInitEvents.call(this);
        }
    })

})()

Hope it helps! Enjoy the code. If you have any questions, let me know!

.

• in Ajax calls

  var MyPanel = Ext.extend(Ext.Panel, {
      doSave: function(){
  	Ext.Ajax.request({
  	    url: 'your_url',
  	    params: ....
  	    success: function(response){
  		response = Ext.decode(response.responseText);
  		this.onSuccess(response)
  	    },
  	    scope: this //the scope in which the success callback is called
  	})
      },
      onSuccess: function(){ .... }
  }

  In this example, specifying the scope is very useful. By default, the success callback on Ajax calls is executed with the scope being the browser ‘window’ object, which is not very useful. In the code above, we execute the success callback in the ‘this’ scope, ‘this’ being the instance of MyPanel which executes the doSave method. This is why we can safely call this.onSuccess(response), as ‘this’ is a MyPanel object, which has the onSuccess method.
  I find the scope config property very useful, so even though specifying the scope of a function is very natural in JavaScript, the fact that ExtJS made it so natural and easy deserves being noted. Well done ExtJS!

• in Buttons

  {
      xtype: 'button',
      text: 'Save',
      handler: function(){
  	//do something on pressing the button
      },
      scope: myScope //scope of the handler
  }

• with Stores

  new Ext.data.Store({
      //...other config options
      autoLoad: {
  	callback: function(){ ... },
  	scope: aScope //for the callback function after loading the store
      }
  })

• in listeners

  new Ext.Panel({
      listeners: {
  	scope: window, //the scope of all listeners in this config
  	show: function(){ ... },
  	afterrender: function(){ ...this is 'window' }
      }
  })

• in actions

Here is the first one:

Use the ref config option in ExtJS

var win = new Ext.Window({
    layout: 'fit',
    width: 300,
    height: 200,
    title: 'my window',
    items: [{
            ref: 'panel',
            xtype: 'panel', layout: 'form',
            frame: true, defaults: {xtype: 'textfield'},
            items: [
                {ref: '../nameField', fieldLabel: 'Name'},
                {ref: 'age', fieldLabel: 'Age'}
            ]
    }]
});

win.show();
//so now, with the above ref options, you can do:
win.nameField.setValue('name here');
win.panel.age.setValue(20);

Notice in the example above that setting ref age config puts a reference “age” in the panel containing the text field, while puting a ref ../nameField sets a “nameField” reference on the component one more level up, that is, the containing window. In this way, you can navigate many levels, each “/” navigating one more level upwards.
In this next example, I introduce another level of nesting, by artificially adding another panel, in order to illustrate the navigation with multiple slashes.

var win = new Ext.Window({
    layout: 'fit',
    width: 300,
    height: 200,
    title: 'my window',
    items: [{
            ref: 'panel',
            xtype: 'panel', layout: 'form',
            frame: true, defaults: {xtype: 'textfield'},
            items: [

                {
                     xtype: 'panel', fieldLabel: 'Name', layout: 'fit',
                     items: [{xtype: 'textfield', ref: '//nameField'}]
                     //notice above, two slashes, which puts
                     //nameField reference on the containing window (two levels)
                },
                {ref: 'age', fieldLabel: 'Age'}
            ]
    }]
});

win.show();
win.nameField.setValue('name here');
win.panel.age.setValue(20);

Please see Ext.Component “ref” reference from the Ext API.

One of the things I really liked about jQuery was the “live” event.
The jQuery documentation explains it very straightforward:

[with a live event you] attach a handler to the event for all elements which match the current selector, now or in the future

I wanted to have something similar in ExtJS, and, no surprise, Ext has it, but it’s not very obvious for a newcomer.

In jQuery you can easily say:

$('p').live('click', function(){
    // do something on paragraph click
})

As it turns out, the “live” event in ExtJS is even more powerful and customizable.
In ExtJS, the equivalent of the above is:

Ext.getBody().on('click', function(event, target){
        // do something on paragraph click
    }, null, {
        delegate: 'p'
    })

For more options and configuration parameters, see Ext.Element::addListener API (Ext.Element.on() is a shorthand for the Ext.Element.addListener() method)

As can easily be seen, you can add live events not only to the body element, but to any element.

Ext.get('header').on('click', function(){
           //only handle anchors with the "menu" css class,
           //which are in the element with id="header"
     }, this /* the scope */, {
         delegate: 'a.menu'
    })

You can further distinguish between the target elements in the event callback

Ext.get('header').on('click', function(e,target){
         //an anchor with class="menu" has been clicked in
         //an element with id="header"

         // Ext.Element.is(selector) tests the current
         // item for the given selector

         // target is of type HtmlElement, not Ext.Element,
         // so wrap in Ext.get()
         if (Ext.get(target).is('.item')){
             // do smth special with anchors with "item" class
         }
     }, this /* the scope */, {
         delegate: 'a.menu'
    })

You can see a live demo here. Thanks!

Ext.ns('myapp.cars');

(function(){
    var Car = Ext.extend(Object,{
	color: 'red',
	description: {
	    gears: 4,
	    year: 1980
	},

	constructor: function(config){
	    console.log("car constructor");
	    Ext.apply(this, config)
	},

	getColor: function(){
	    return 'actual color ' + this.color;
	},

	getMake: function(){
	    throw 'unimplemented method';
	}
    })

    myapp.cars.Car = Car;
})()

// ---- another file here: myapp.cars.Bmw.js
Ext.ns('myapp.cars');

(function(){

    var BmwCar = Ext.extend(myapp.cars.Car,{

	color: 'blue',

	constructor: function(config){
	    BmwCar.superclass.constructor.apply(this, arguments)
	},

	getMake: function(){
	    return "This is a BMW"
	}
    })

    myapp.cars.Bmw = BmwCar;
})()

First of all notice

(function(){
     // your code here
})()

We never want to populate our global “namespace” of JavaScript objects. So, we put all our code in a anonymous function, which is not only defined, but also executed. We will export only what’s needed, that is, the public API of our app.
Second, notice

Ext.ns('myapp.cars');

outside of our anonymous-function-that-hides-it-all. It is a shorthand for Ext.namespace. What it does is the following: it creates an object myapp, if it doesn’t exist. Then, it creates a property on this object (the newly created or the existing one) named cars, only if it doesn’t exist. I recomend putting a call to Ext.ns('...') at the beginning of every js file, and then, in the anonymous function call, attach what you need to into this public namespacing object. So all your files should look something like

Ext.namespace('myapp.package.subpackage');
(function(){
    var MyClass = // class definition
    ....
    // end of class definition

    //in this way we "export" MyClass to be visible publicly
    myapp.package.subpackage.MyClass = MyClass
})()

Now let’s see our class hierarchy. Use Ext.extend to extend from an existing Object. If you don’t have a specific superclass you want to extend, just extend Object. Then, as a second parameter, provide an object literal, which can contain properties and/or functions. All these properties/functions will be placed in the prototype of your newly created class, overriding (if it is the case) the properties in the prototype of the base class. Notice Ext has a special function, named constructor, which is called when objects are instantiated. If you define a constructor in the subclass, don’t forget to call the superconstructor of the base class (if you want – and probably you do).

constructor: function(config){
   BmwCar.superclass.constructor.apply(this, arguments)
}

Notice how methods from the base class are called: <current_class>.superclass.<method_name>.apply(this, arguments). You could also call it with call and other arguments, but in this way, you just forward the existing arguments, whithout having to explicitly name them.
In this example, in the constructor of the Car class we use a very powerful feature in JavaScript and ExtJS, dynamically applying properties to objects

constructor: function(config){
    console.log("car constructor");
    Ext.apply(this, config)
},

Take all the properties given in the config and apply them to the car object. For instance, you could have a code like:

var bmw = new myapp.cars.Bmw({
	color:'black',
	getColor: function(){
	    return "my custom color";
	}
});

Not only does Bmw overrides the color attribute for the car, but this bmw instance in particular overrides the color attribute to ‘black’. Also override the getColor method. This gives a tremendous flexibility, allowing more than one level of overriding! Subclass overrides superclass, and object instance(of subclass) overrides subclass. So basically you can end up building custom bmw instances, each having it’s own implementation of getColor. Generally you won’t do method overriding at instance level, but you will want to override values in the properties of an instance. So calling your constructor with a config object is very useful when wanting to set values of multiple fields at once.

Another interesting feature is overriding a method at instance level, and also using the previous implementation of the method. Take a look:

var bmw = new myapp.cars.Bmw({
	color:'black',
	getColor: function(){
	    console.log('getColor: ');
            //use previous implementation - notice apply
	    return myapp.cars.Bmw.prototype.getColor.apply(bmw) + ' custom color';
	}
});

Notice the call to the getColor method from the prototype of the Bmw class, applied to the current instance, in order to keep the context of the method call.
All these features of prototypal inheritance with JavaScript in general and ExtJS in particular, allow a great flexibility and many levels of customization.

To recap, don’t forget that when you override a method, if you want to use the implementation in the base class, you have to use something like:

 var BmwCar = Ext.extend(myapp.cars.Car,{
    getMake: function(){
        //use implementation in the superclass and forward any arguments
        BmwCar.superclass.getMake.apply(this, arguments)
    }
})

where superclass is a property set by ExtJS when creating the class, for easy reference to the superclass.

Pitfalls

There are some pitfalls you should be aware of. These appear because of the nature of the prototypal inheritance.
Don’t forget that when you write:

var subclass = Ext.extend(MySuperclass, {
    property1: value1,
    property2: value2,
    method1: function(){ ... },
    method2: function(){ ... }
});

all the properties of the config object given as the second argument to the Ext.extend function go into the prototype of the subclass. Let’s have some examples to see what can happen. Suppose for this example the myapp.cars.Car implementation above and the following Bmw implementation:

var BmwCar = Ext.extend(myapp.cars.Car,{
	model: {
	    name: 'sedan'
	}
})

Now make the following tests:

var bmw = new myapp.cars.Bmw();
var secondBmw = new myapp.cars.Bmw();

secondBmw.color = "orange";
secondBmw.model = { name: 'hatchback'}

//typical behavior
console.log(bmw.color); // outputs "red"
console.log(bmw.model); //outputs Object { name="sedan"}

var bmw = new myapp.cars.Bmw();
var secondBmw = new myapp.cars.Bmw();

//NOTICE change of model name also affects the first bmw instance
secondBmw.model.name = 'hatchback'
console.log(bmw.model); //outputs Object { name="hatchback"}

So we modify the model.name attribute on the secondBmw and it gets propagated to the first bmw instance. Why? Well, the model object belongs to the prototype of the Bmw class, so it is shared between all the bmw instances. Any change in properties of this object affects all instances of the class!
But notice in the first test, changing the model object doesn’t affect all instances of Bmw. This is because the instruction

secondBmw.model = { name: 'hatchback'}

changes the model property on the secondBmw instance to refer to a whole new object, independent of the class prototype.
So you have to be warned. It’s okay to put in the prototype properties which are JavaScript primitive types (strings, numbers), but you have to take special care when dealing with objects! They are allowed, but you should be aware of the facts explained above and handle with care.

This is a summary of prototypal JavaScript inheritance with ExtJS. Play with it, try it, use it!
Have fun!