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

      0  

    Default


    Hello Don,

    Thanks again for your response,

    That helped!

    Using the following code worked perfectly and I'm able to test the app running in 4.1 (I've changed all my overrides to this form)
    Code:
    Ext.define('MM.patch.layout.container.Fit', {   
        override: 'Ext.layout.container.Fit',    
        
        calculate: function (ownerContext) {        
            console.log('override called');
            var me = this,
                childItems = ownerContext.childItems,
                /* begin workaround */
                //length = childItems.length,
                length = childItems !== undefined ? childItems.length : 0,
                /* end workaround */
                targetSize = me.getContainerSize(ownerContext),
                contentSize = { width: 0, height: 0 },
                i;
    
    
            for (i = 0; i < length; ++i) {
                me.fitItem(ownerContext, childItems[i], targetSize, contentSize);
            }
    
    
            if (!ownerContext.setContentSize(contentSize.width, contentSize.height)) {
                me.done = false;
            }
        }
    });
    But just to let you know, using the following code (the < 4.1 way, without the Ext.define('..', { override: ... }) don't...
    Code:
    Ext.override('Ext.layout.container.Fit', {        
          calculate: function (ownerContext) {        
                console.log('override called');
                var me = this,
                childItems = ownerContext.childItems,
                /* begin workaround */
                //length = childItems.length,
                length = childItems !== undefined ? childItems.length : 0,
                /* end workaround */
                targetSize = me.getContainerSize(ownerContext),
                contentSize = { width: 0, height: 0 },
                i;
    
    
            for (i = 0; i < length; ++i) {
                me.fitItem(ownerContext, childItems[i], targetSize, contentSize);
            }
    
    
            if (!ownerContext.setContentSize(contentSize.width, contentSize.height)) {
                me.done = false;
            }
        }
    });
    Don't know if it should be filed as a bug or not... what's even weirder is that I had an override in this old form for the ComboBox constructor and it worked fine there...

    Now that I understand the new way, I quite like it, it's cleaner and easier to include/exclude on builds.

    Thanks again for your help throughout this issue
    Last edited by maksimenko; 3 Nov 2011 at 12:35 PM. Reason: code new lines fix

  2. #22
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,294
    Vote Rating
    121
    dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all

      0  

    Default


    Quote Originally Posted by maksimenko View Post
    But just to let you know, using the following code (the < 4.1 way, without the Ext.define('..', { override: ... }) don't...
    Code:
    Ext.override('Ext.layout.container.Fit', {        
          calculate: function (ownerContext) {        
                console.log('override called');
                var me = this,
                childItems = ownerContext.childItems,
                /* begin workaround */
                //length = childItems.length,
                length = childItems !== undefined ? childItems.length : 0,
                /* end workaround */
                targetSize = me.getContainerSize(ownerContext),
                contentSize = { width: 0, height: 0 },
                i;
    
    
            for (i = 0; i < length; ++i) {
                me.fitItem(ownerContext, childItems[i], targetSize, contentSize);
            }
    
    
            if (!ownerContext.setContentSize(contentSize.width, contentSize.height)) {
                me.done = false;
            }
        }
    });
    Don't know if it should be filed as a bug or not... what's even weirder is that I had an override in this old form for the ComboBox constructor and it worked fine there...

    Now that I understand the new way, I quite like it, it's cleaner and easier to include/exclude on builds.

    Thanks again for your help throughout this issue
    Glad I could help. Try this in the pre-4.1 version:

    Code:
    Ext.override(Ext.layout.container.Fit, {
          calculate: function (ownerContext) {
                console.log('override called');
                var me = this,
                childItems = ownerContext.childItems,
                /* begin workaround */
                //length = childItems.length,
                length = childItems !== undefined ? childItems.length : 0,
                /* end workaround */
                targetSize = me.getContainerSize(ownerContext),
                contentSize = { width: 0, height: 0 },
                i;
    
            for (i = 0; i < length; ++i) {
                me.fitItem(ownerContext, childItems[i], targetSize, contentSize);
            }
    
            if (!ownerContext.setContentSize(contentSize.width, contentSize.height)) {
                me.done = false;
            }
        }
    });
    The quoted class name is I think the problem.
    Don Griffin
    Ext JS Development Team Lead

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

    "Use the source, Luke!"

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

      0  

    Default


    Yup, that was it!,

    I should have copy/pasted an Ext.define('...', {}); and changed the define to override.... because the one that were working and all in 3.4 and 4.0 are without quotes....

    Thanks again for your help!

  4. #24
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,294
    Vote Rating
    121
    dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all

      0  

    Default


    Glad to hear that solved it.
    Don Griffin
    Ext JS Development Team Lead

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

    "Use the source, Luke!"

  5. #25
    Sencha User
    Join Date
    Mar 2009
    Location
    Reading, UK
    Posts
    33
    Vote Rating
    1
    Curtis Fletcher is on a distinguished road

      0  

    Default


    So am I right in assuming that there is _no_ way to dynamically patch an ext object if the method happens to use callParent?

    For example, There is behaviour within Ext.grid.column.Column.initComponent that I want to change (sorting is switched off for grouped columns, which is unnecessary when sorting is done remotely), not on a case-by-case basis but globally, even if the columns are created by ext-internal code. Normally I would use Ext.override but that breaks in 4.1 due to callParent calling the overridden initComponent.

  6. #26
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,499
    Vote Rating
    286
    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


    So am I right in assuming that there is _no_ way to dynamically patch an ext object if the method happens to use callParent?
    I'm not sure this question makes sense. If you use callParent in an override it will call the overridden method. If you don't want to call that method, don't use callParent. You can still call implementations further up the prototype chain by referencing them directly just like you always could.

  7. #27
    Sencha User
    Join Date
    Mar 2009
    Location
    Reading, UK
    Posts
    33
    Vote Rating
    1
    Curtis Fletcher is on a distinguished road

      0  

    Default


    Quote Originally Posted by skirtle View Post
    I'm not sure this question makes sense. If you use callParent in an override it will call the overridden method. If you don't want to call that method, don't use callParent. You can still call implementations further up the prototype chain by referencing them directly just like you always could.
    I'm not choosing to use callParent. I'm replacing an ext method that needs to use callParent to use functionality in it's parent class.

    Full example:
    Grouped grid columns explicitly get "sortable" set to false in Ext.grid.column.Column.initComponent this behaviour is unnecessary if "remoteSort" is set, hence I wan't to change it globally. Previous to Ext 4.1 I would replace Ext.grid.column.Column.initComponent with a version that behaved as I expected using override. If "callParent" was used it would call the method in the parent class not the original Ext.grid.column.Column.initComponent

    tl;dr override used to be usable to "patch" ext without messing with inheritance, now it can't. What can I use to so the same thing that override used to do?

  8. #28
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,294
    Vote Rating
    121
    dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all

      0  

    Default


    Hi @curtis,

    I am not really following what you are describing, sorry. If you have overridden initComponent, how can the original initComponent (the one with callParent you mentioned) be getting called if you are not using callParent or callOverridden?

    It would be best if you would post the content of your override. At least the important parts: the Ext.override (or Ext.define/override) call and the initComponent in your override.
    Don Griffin
    Ext JS Development Team Lead

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

    "Use the source, Luke!"

  9. #29
    Sencha User
    Join Date
    Mar 2009
    Location
    Reading, UK
    Posts
    33
    Vote Rating
    1
    Curtis Fletcher is on a distinguished road

      0  

    Default


    Apologies for failing to explain this. I am using callParent, because I _must_ use it.

    I need to replace initComponent in Ext.grid.column.Column. with a version that is only subtly different.
    initComponent _must_ use callParent to invoke Ext.grid.header.Container.initComponent (and so on) hence my replacement must use callParent

    E.G.
    Code:
    Ext.define('Ext.x.child', {
        extend: 'Ext.x.base',
        initComponent: function() {
            #complex init here
            #code that makes problematic assumptions here
            #more complex init here
            this.callParent()
            #more complex init here
        }
    }

    The call chain was Ext.x.child.initComponent->Ext.x.base.initComponent


    Previously I could


    Code:
    Ext.override(Ext.x.child, {
        initComponent: function() { //overridded
            #complex init here
            #FIXED ASSUMPTION CODE
            #more complex init here
            this.callParent()
            #more complex init here
        }
    }

    The call chain was Ext.x.child.initComponent//overridden->Ext.x.base.initComponent


    Now the callchain is Ext.x.child.initComponent//overridded->Ext.x.child.initComponent->Ext.x.base.initComponent

  10. #30
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,499
    Vote Rating
    286
    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 still don't understand why you think you must use callParent. callParent is just a convenience method for invoking a method on the superclass. There's nothing to stop you calling the method you want directly, like this:

    Code:
    initComponent: function() {
        // Complex init
    
        Ext.grid.column.Column.superclass.initComponent.call(this);
    
        // Complex init
    }