1. #1
    Ext JS Premium Member
    Join Date
    May 2009
    Posts
    41
    Vote Rating
    0
    maksimenko is on a distinguished road

      0  

    Default overriding / callParent behavior change (bug?)

    overriding / callParent behavior change (bug?)


    Hello there,

    When overriding a constructor in ExtJS 4.1, the overridden constructor gets called when this.callParent() (instead of on this.callOverriden()) is used on the new function.

    Code:
    Ext.override(Ext.data.Store, {
         constructor: function () {
               ...... 
               this.callParent(); // this calls the overridden Ext.data.Store constructor instead of the Ext.data.AbstractStore constructor
               ....
         }
    });
    Is this an intentional behavior change or an unnoticed bug?

    The problem with this behavior is that if I try to override a constructor to provide custom functionality or fix a bug, the overridden constructor with the undesired code is getting called too, thus giving unexpected results...

    Let me know if you need more info

  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    37,549
    Vote Rating
    873
    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


    Have you tried callOverridden()?
    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
    Ext JS Premium Member
    Join Date
    May 2009
    Posts
    41
    Vote Rating
    0
    maksimenko is on a distinguished road

      0  

    Default


    Hello Mitchell,

    Maybe I didn't explain myself correctly.

    I don't want to call the overriden Ext.data.Store constructor, in fact, I expect it to not be called.

    The problem is that, now in the 4.1 branch, with the changes made to the callParent function code, the this.callParent() is calling the overriden constructor and I expect it not to do so, instead I expect it to call the Ext.data.AbstractStore constructor...

    Hope I explained myself better this time,

  4. #4
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Location
    Kansas
    Posts
    1,429
    Vote Rating
    151
    dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold

      0  

    Default


    Yes, this was changed as part of the Ext.define/override functionality. I will add it to the API changes page. If you haven't seen this yet, you might find it useful:

    PHP Code:
        Ext.define('My.patch.Store', {
            
    override'Ext.data.Store',

            
    constructor: function () {
            }
        }); 
    The override can then be "required" and dynamically loaded or brought into an optimized build. If an override is required (say 'My.patch.*'), it won't actually be used unless the target class is also used.

    From a design perspective, overrides in 4.1 are almost like partial classes and will allow a single class to be implemented in multiple, independent pieces (rather than the problematic approach of "AbstractFoo" and "Foo" classes).

    Is this need very common in your overrides?

    To bypass the original method, in 4.1, you have to go old-school:

    PHP Code:
        constructor: function () {
            ... 
            
    Ext.data.AbstractStore.prototype.constructor.call(this);
            ...
        } 
    Don Griffin
    Engineering Manager - Frameworks (Ext JS / Sencha Touch)

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"

  5. #5
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,616
    Vote Rating
    327
    skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future

      0  

    Default


    I only use overrides to patch bugs. It's pretty common to need to skip the buggy overridden method in such circumstances. Personally I always used the 'old-school' prototype approach when I was doing this anyway, relying on the callParent() magic always struck me as a bit risky when I'm subverting a class's original methods.

  6. #6
    Touch Premium Member
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    1,414
    Vote Rating
    179
    LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold LesJ is a splendid one to behold

      0  

    Default


    Quote Originally Posted by dongryphon View Post
    From a design perspective, overrides in 4.1 are almost like partial classes and will allow a single class to be implemented in multiple, independent pieces (rather than the problematic approach of "AbstractFoo" and "Foo" classes).

    Is this need very common in your overrides?
    Don, hi!

    I use the "AbstractFoo" and "Foo" approach. Can you explain (in more detail) why this approach is problematic and how I could use overrides in 4.1?

    Also, does it mean that classes such as AbstractComponent or AbstractContainer will be eliminated?

    I still don't understand why for example there is the AbstractComponent class... why not fold its content into the Component class?

  7. #7
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,616
    Vote Rating
    327
    skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future

      0  

    Default


    I believe AbstractComponent and AbstractContainer exist so that the code can be shared with Sencha Touch.

    If I've understood what Don said correctly, I believe these classes will disappear because the new style of overrides allow this code to be reused without the need for the abstract classes. They are still there in 4.1-pr1 though.

  8. #8
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    37,549
    Vote Rating
    873
    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


    Abstract classes are still a good idea IMO... Creating your own components sometimes you can just extend the abstract to accomplish what you need.
    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.

  9. #9
    Ext JS Premium Member
    Join Date
    May 2009
    Posts
    41
    Vote Rating
    0
    maksimenko is on a distinguished road

      0  

    Default


    Hello Don,

    Thanks for your response.

    As skirtle do, I mostly use overrides to patch bugs, so, in those cases I'd like the overridden method not to be called.

    I've a few overrides in 4.0 and now I had to do a few for 4.1 so I could test the app ( and I've seen great perf. improvements in every browser... but still couldn't test on IE6 with a surface error )

    Anyway, now I understand the reasoning behind the change. And the workaround of using the old school way of calling the superclass method works fine, so it's OK.

    Thanks again for your response

  10. #10
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Location
    Kansas
    Posts
    1,429
    Vote Rating
    151
    dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold dongryphon is a splendid one to behold

      0  

    Default


    @LesJ,

    The AbstractFoo/Foo approach can still be valid in many cases, don't get me wrong. Inheritance is still a Good Thing.

    AbstractElement/Element and AbstractComponent/Component, however, were really "artifacts of implementation" where we were trying to share code between Touch and Ext JS. An app should never create an AbstractElement or AbstractComponent and really nothing other than Element or Component should even derive from them. This is not really what inheritance is all about, but it was the only tool at hand at the time. The problem is that this rippled through everything, including the docs, forcing these details to be in front of everyone.

    It is possible that we will fold such things together in the future and maintain aliases for the old names. If we did this, the AbstractElement class would be renamed to Element and the current Element class would become an override.
    Don Griffin
    Engineering Manager - Frameworks (Ext JS / Sencha Touch)

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"