Ext.define() "config" inconsistency

[XASD]

It seems something is wrong with such important part of new class system as "config" declaration.

1) Somewhere on forum was information about proper usage of "config" option in class definition.
"config" option in define() must be used only to create "new" config properties. If you define class which "extend" another class with properties already exists,you don't have to specify it in "config" section.
Something like:

Ext.define('my.view.XForm', {
    extend:'Ext.form.Panel',
    loader:{
       url:'test',
       baseParams:{a:'b'}
    },
...

is enough-"loader" already defined upper in the hierarchy.Or is it?

But if you want to redefine "default" value for "config" property,then that do you need to do?
Hot to change only "url" or "baseParams" leaving rest of declaration intact?

I've heard about "deeply merge" functionality for "config" preprocessor,but it only work if "config" option declared in "define()"-it looks for "config" property to make it's work(invoke addConfig()).
So,if I define "loader" option directly,not enclosed in "config", it wouldn't be handled as "config" property, but as simple "field" member. That's not correct IMHO.

If you declare something as "config" property earlier, it's natural to expect it to be handled that way in derived class. So, "config" preprocessor must lookup already defined "config" properties,search them in new"extend" class definition and treat them as same type of property-execute deep merge,for example.
I mean,it's not become simple "field"-it declares default value for existent "config" property.
Now it's not work this way. To trigger preprocessor to see properties as "config" you must declare "config" option in define(), even though it maybe be already defined on level above as "config" property.

2) OK. let's define every customizable property as "config" to get needed functionality-deep merge.

Ext.define('my.view.XForm', {
    extend:'Ext.form.Panel',
config:{
    loader:{
       url:'test',
       baseParams:{a:'b'}
    }
},
...
Ext.define('qqq', {
    extend:'my.view.XForm',
config:{
    loader:{
       baseParams:{a:'c'}
    }
},
...

but this will not work too...

'qqq's prototype.loader contains something called objectClass which in turn contains old declared "url" and "baseParams" AND separate new "merged" baseParams property,something like

objectClass{
  properties:{
     url:'test',
    baseParams:{a:'b'}
  },
  baseParams:{a:'c'}
}

Ext.create('qqq') can't figure out what to do with such mix and as result you never see correct loader

loader:{
     url:'test',
     baseParams:{a:'c'}
}

so,as you can understand "merge" functionality is not correctly handled too.

3) What about promised setLoader()/getLoader() accessors for loader "config" type property? There's nowhere in sight,though 'loader' declared as 'config' property.

Thanks.

[mitchellsimoens]

Here is a full test case I created that should be similar to what you are talking about (you provided snippets but not a full test case):

Ext.define('A', {
    config : {
        foo : {
            bar : {
                test    : 'good',
                another : 'test'
            }
        }
    },

    constructor : function(config) {
        this.initConfig(config);

        this.callParent(arguments);
    }
});

Ext.define('B', {
    extend : 'A',

    config : {
        foo : {
            bar : {
                test    : 'bad'
            }
        }
    }
});

var a = new A();

console.log(a.getFoo().bar.test);
console.log(a.getFoo().bar.another);

console.log('-----');

var b = new B();

console.log(b.getFoo().bar.test);
console.log(b.getFoo().bar.another);

This outputs:

good
test
-----
bad
test

as expected.

[LesJ]

Is it required to call callParent in A's constructor? The Base constructor is not doing much.

[mitchellsimoens]

Is it required to call callParent in A's constructor? The Base constructor is not doing much.

I always do as you never know if we will ever add something in Base's constructor so this adds a little future confidence.

[XASD]

It's getting interesting.
So, to make "config" option to work, you need

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:

                    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:

   constructor
      autoLoad: null
      baseParams: Object
        a: "b0"
        __proto__: Object

but for x_2.loader we see:

  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:

                   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.

[XASD]

Even better, it seems most of "config" properties in framework does not have declared accessors,such as get*/set*,though docs says it must be auto generated for "config" properties.Look at "title" in panel.
So, until you explicitly define "config"(already declared for panel,for example) properties using method above,you will see simple property treatment even for documented "config" properties.
As it turns out "title" does not have getTitle()/setTitle() by default.

[mitchellsimoens]

I haven't seen a guide or an example that uses (correct me if I walked over some) so we don't recommend it.

Here is the back story on the config object in Ext JS 4... when 4 was first being created we started working on this config system but to get Ext JS 4 out the door we couldn't implement it throughout the framework so none of our widgets support it so it's really just an application feature for Ext JS 4.

In Sencha Touch 2, the framework was really built around the config object and it works fantastically but the framework started off by using it.

Since we haven't fully implemented it throughout the framework for Ext JS 4, no class in Ext JS 4 executes this.

I'm not saying you can't use it, I use it in my own app utility classes but I wouldn't expect the Ext JS 4 classes to support it yet.

[XASD]

Several links about "config" from google:

http://www.sencha.com/blog/countdown...-class-system/
http://edspencer.net/2011/01/classes...-the-hood.html
http://blogs.microsoft.co.il/blogs/p...c-methods.aspx
http://php.refulz.com/auto-getters-a...s-in-ext-js-4/
http://liadprog.blogspot.com/2012/01...em-object.html
http://stackoverflow.com/questions/9...sencha-touch-2

latter talking about

new class system (much like Ext JS 4)

its author understand extjs4 as "prior art",as many of us.

Every single article about new class system touch "config" subject somehow,starting from 2011.
But official documentation mixing and matching "property" and "config" freely,exchanging context-in one case it will be class definition in another place it's instance related.Very confusing.

About "Touch 2.0". I looked at app generated code:

Ext.define('GS.view.Main', {
    extend: 'Ext.tab.Panel',
    xtype: 'main',
    requires: [
        'Ext.TitleBar',
        'Ext.Video'
    ],
    config: {
        tabBarPosition: 'bottom',

        items: [
            {
                title: 'Welcome',
                iconCls: 'home',
...

OK,so according to new rules EVERYTHING related to class definition must be enclosed in "config"? Why "title" in first item not enclosed in "config"? It's not "config" property? It's somehow known "config" property? If I write "items" without wrapping it into "config",component stop working?
"config" property suddenly becomes "simple" instance property?
Why "config" preprocessor can't walk up the class hierarchy and determine what properties "config" and which not by itself?
Where's the logic? Why I must act that way and not the other?

Does I feel better about "Touch 2.0"? Maybe...but not so much.
I really appreciate all hard work you make,but all cornerstone disputable concepts must be defined upfront cleanly,not be afterthought consideration.

Thanks.

[mitchellsimoens]

I'm not sure you have a strong grasp on what the config object really does in ST2. There is no logic of what is a config or what isn't. Properties in the config object get the getter and setter created so if there is code that uses getItems and you put items outside the config, that items array you are trying to use isn't part of what getItems returns. The items within the config get prefixed with an underscore so you have the items property you use and the _items that came from what was inside the config object likely in a superclass.

[XASD]

Probably you're right about my "touch" skill set, but I'm sure it would be better for all to have common denominator for extjs and touch platforms-working core class and component system.
http://mobile.smashingmagazine.com/2...ial-smackdown/ time to merge?

Thanks.