What are the alternative cluster names for

So int ExtJS we have:

  • "real" type name (the one that goes as the first parameter in Ext.define)
  • pseudonym
  • alternateClassName
  • xtype

The most mysterious for me is alternateClassName. Why do we really need them if we already have such a zoo of type descriptors? Please note that I am not trying to discuss the quality of the ideological approach. The only question is why this was implemented and for what purpose.

+5
source share
3 answers

They are used for backward compatibility. For example, Ext.grid.Panel in ExtJS 4 has

alternateClassName: ['Ext.list.ListView', 'Ext.ListView', 'Ext.grid.GridPanel']

because it replaces the ListView and is used for the name Ext.grid.GridPanel.

+8

, alternateClassName , .

:

Ext.define('Sample', {    
    alternateClassName: ['Example', 'Important'],     
    code: function(msg) {        
        alert('Sample for alternateClassName... ' + msg);     
    },
    renderTo :document.body
});
var hi = Ext.create('Sample');
hi.code('Sample');
var hello = Ext.create('Example');
hello.code('Example');
var imp = Ext.create('Important');
imp.code('Important');

, :

1. Sample, Example, Important .
2. , , .
3. . . , , , , .

:

http://jsfiddle.net/kesamkiran/kVbra/30/

+2

, [namespace]. [name]

- , . , , .. (, "controller.foo", "foo" )

xtype

Ext.Component

,

alternateClassName

, . ,

For a singleton class used to store constants declared as app.util.navigationConstants, you can define a smaller class name, which is shorter, NavConsts. And now you can use NavConsts.CONST_NAME instead of app.util.navigationConstants.CONST_NAME

0
source

All Articles