Instead, Selenium tests for ExtJS should rely on CSS selectors. For every button, grid, label, tab or any significant UI element, I simply chose to use the cls attribute and specify a CSS class.

new Ext.Button({
    text: 'Ok',
    cls: 'seleniumOkButton', //can have more classes, separated by space
    scope: this,
    handler: function(){ ... }
})

This is how a basic button that is used in automation testing looks like. And I use the following XPath selector in Selenium:

//table[contains(@class,'seleniumOkButton')]

Happy automated testing!

Or do something smart. Like call the slice method from Array.prototype on the arguments, something like:

//this makes a copy of the arguments and returns a true array
Array.prototype.slice.call(arguments, 0) 

//pushes the value '5' in the arguments
Array.prototype.push(arguments, 5)
//this is not valid: arguments.push(5)

Well, maybe most of you expert JavaScript programmers have thought about this, and this is not a news. But, let’s share from our experience to the more novice/newcomers to JavaScript and show them the beauty of this language!

JavaScript is a great language! It’s expressive! It’s powerful! That’s why we love JavaScript.

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!

Beyond simply shortening variable names, Closure Compiler with ADVANCED_OPTIMIZATIONS, does three other important steps:

• aggresive renaming – not only renaming local variables and functions, but it renames GLOBAL variables and functions. In this way, it can ruin your public API
• dead code removal – it removes functions you are not using and segments of unreachable code. This can be fine for some apps, but it is definitely risky for JavaScript libraries, that expose some functions which are supposed to be called only by client code.
• function inlining – inserting the function’s body instead of the function call, where appropriate

So it is true that without some additional work, the ADVANCED_OPTIMIZATIONS option will just ruin your code and your public API. Of course the solutions are at hand, but the question is if they worth the effort.

Keep your public API

If you provide ONLY the code below to Google Compiler, it produces empty output:

function hello(name){
    alert("Hello " + name);
}

What? Empty output? Well… yes, as you never call your function. Instead, for the next code:

function hello(name){
    alert("Hello " + name);
}
hello('jslog');

it produces the following output:

alert("Hello jslog");

This is smart! But we want to preserve our API (by the way, in the tutorial for Google Closure Compiler Advanced Optimizations, Google says on this page that the hello function is preserved, while it is NOT – see section Removal of code you want to keep and try the code online at Closure Compiler UI Tool)

So if the hello method above would be part of the public API, it would break third parties using it. Google proposes a solution for this: export the public objects/functions into the global namespace using the window object:

function hello(name){
    alert("Hello " + name);
}
hello('jslog');
window['hello'] = hello;

//and the output is:
function a(b){alert("Hello "+b)}a("jslog");window.hello=a;
//so the hello function is kept as a property on the global window object

Instead, if you use:

window.hello = hello;

you get

function b(c){alert("Hello "+c)}b("jslog");window.a=b;

which is surely not what you want. So make sure you use the window['public_name'] notation. You should also standardize the way you access properties in your objects, either using the array notation, or the dotted notation, otherwise the compiler could be mislead by a mix of the two. But sometimes we just need to use both, as properties may be automatically generated at runtime.

Other problems with the Google Closure Compiler ADVANCED_OPTIMIZATIONS are separately compiling blocks of code with dependencies to external JavaScript. The solution for this is

• using either exports like the above or with the goog.exportSymbol() or
• using extern files specifically provided as a compilation option

In any case, I think this is just a bit too clumsy.

Moreover, having a class and export all its properties/functions is quite a job to to if your app is already a large one. Just have a short example:

MyClass = function(name) {
  this.myName = name;
};
MyClass.prototype.myMethod = function() {
  alert(this.myName);
};
window['MyClass'] = MyClass; // <-- Constructor
MyClass.prototype['myMethod'] = MyClass.prototype.myMethod; <-- export mechanism

//the above compiles to
MyClass=function(a){this.b=a};MyClass.prototype.a=function(){alert(this.b)};window.MyClass=MyClass;MyClass.prototype.myMethod=MyClass.prototype.a;

Conclusions

After this short overview of the ADVANCED_OPTIMIZATIONS flag, I really think most people won't need it. If you already have a large library, having it compiled with advanced optimizations would be a total nightmare, as it would require a review of all public methods and properties and additional work for each. And the gain? Just a few kilobytes. I have tried compiling ExtJS Core with advanced optimizations and got aprox 62 KB, while with simple optimizations it is 74 KB. Not very well for the amount of effort it would require, in my opinion.

But if you still think advanced optimizations is for you, you are probably wanting to optimize a lot, and you should first start seaching for other ways to optimize - first, make sure you combine all your js code into one file. It's better to have one js file of 100KB rather than have 10 files each of 5 KB. So make sure you are doing every other possible optimization before moving to the advanced optimizations flag.

After all, it's up to you to decide if it's worth the effort!

PS: You can follow me on twitter @extjslog.

PS: I am preparing the promised post on Google Closure Compiler ADVANCED_OPTIMIZATIONS.

.

• 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!

Over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 as well as other older browsers that are not supported by their own manufacturers.

We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010. After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Google Apps will continue to support Internet Explorer 7.0 and above, Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 and above.

We will certainly not miss you, IE6!
Waiting for comments from happy developers!