1. #1
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    228
    Vote Rating
    4
    XASD is on a distinguished road

      1  

    Default Ext.define() "config" inconsistency

    Ext.define() "config" inconsistency


    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:
    Code:
    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.
    Code:
    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
    Code:
    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
    Code:
    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.

  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    36,780
    Vote Rating
    833
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      1  

    Default


    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):

    Code:
    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.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  3. #3
    Touch Premium Member
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    1,310
    Vote Rating
    109
    LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light

      0  

    Default


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

  4. #4
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    36,780
    Vote Rating
    833
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      1  

    Default


    Quote Originally Posted by LesJ View Post
    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.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  5. #5
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    228
    Vote Rating
    4
    XASD is on a distinguished road

      0  

    Default


    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.

  6. #6
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    228
    Vote Rating
    4
    XASD is on a distinguished road

      0  

    Default


    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.

  7. #7
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    36,780
    Vote Rating
    833
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    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.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  8. #8
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    228
    Vote Rating
    4
    XASD is on a distinguished road

      0  

    Default


    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:
    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.

  9. #9
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    36,780
    Vote Rating
    833
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    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.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  10. #10
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    228
    Vote Rating
    4
    XASD is on a distinguished road

      0  

    Default


    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.

Thread Participants: 2

Turkiyenin en sevilen filmlerinin yer aldigi xnxx internet sitemiz olan ve porn sex tarzi bir site olan mobil porno izle sitemiz gercekten dillere destan bir durumda herkesin sevdigi bir site olarak tarihe gececege benziyor. Sitenin en belirgin ozelliklerinden birisi de Turkiyede gercekten kaliteli ve muntazam, duzenli porno izle siteleri olmamasidir. Bu yuzden iste. Ayrica en net goruntu kalitesine sahip adresinde yayinlanmaktadir. Mesela diğer sitelerimizden bahsedecek olursak, en iyi hd porno video arşivine sahip bir siteyiz. "The Best anal porn videos and slut anus, big asses movies set..." hd porno faketaxi