It's getting interesting.
So, to make "config" option to work, you need
Code:
constructor : function(config) {
this.initConfig(config);
this.callParent(arguments);
}
in you base class.
Otherwise even "config" declaration in both classes dosen't matter to framework.
Why default base class constructor can't call magic "initConfig()"-mistery. And as usual unexpected behavior is documented nowhere.
And even though, this strange construction work (who calls constructor(config) for base class and at which moment? I firmly believed, it's only for Ext.create('class', {config}) ), it's not equivalent for base and derived classes. Look that I mean:
Code:
Ext.define('x1', {
extend:'Ext.form.Panel',
config:{
loader:{ url:'a', baseParams: {a:'b0'}}
},
constructor : function(config) {
this.initConfig(config);
this.callParent(arguments);
}
});
Ext.define('x2', {
extend:'x1',
config:{
loader:{ baseParams: {a:'b1'}}
}
});
var x_1= Ext.create('x1'), x_2= Ext.create('x2');
and in console for x_1.loader:
Code:
constructor
autoLoad: null
baseParams: Object
a: "b0"
__proto__: Object
but for x_2.loader we see:
Code:
constructor
autoLoad: null
baseParams: Ext.Object.classify.objectClass
__proto__: Ext.Object.classify.objectClass
a: "b1"
__proto__: Object
simple baseParams becomes cryptic objectClass in derived class x2.
Strange, but loader=ComponentLoader understand it, and component loaded successfully with proper query parameters.
But it seems sometimes framework/third party component will not be such forgiving.Object!=objectClass anyway and can't be used interchangeably. I'm glad it worked for ComponentLoader,but changing object type silently is not the best practice IMHO.
Also, I'm talking not only about confusing practice for work with "config" properties, but about inconsistency in docs.
Where's generated getLoader()/setLoader() methods?
Why I need to declare property as "config" several times only to be recognized as "config" property,although it was already declared in "config" of base class. Even more, you say in one of posts that it's not required for derived classes to have "config" section when base class already declared needed properties. You define class one time and it must derive all properties from base class-logical.
But if you don't use trick presented here, you get simple property(overwrite/not merge effect) treatment from framework, not "config" property as you may expect.
Anyway, it's looks very strange to have construction like this:
Code:
Ext.define('x1', {
extend:'Ext.form.Panel',
title:"test", // this is "config" property too...
config:{
loader:{ url:'a', baseParams: {a:'b0'}}
},
constructor : function(config) {
this.initConfig(config);
this.callParent(arguments);
}
});
only to give "loader" property "config" preprocessor recognition.
Is "title" not in the same category as "loader" config property anymore?
Why enclosing "config" and custom "constructor" is required only to get proper handling?
And not exactly correct,if you ask me,because "title" in example overwrite "title" as property-getTitle()/setTitle() is not available anymore,though panel work...partially,but "title" becomes simple(not "config") property. Strange things happens behind the scenes...principle of least surprise,where are you?
Thanks.