overriding / callParent behavior change (bug?)

[maksimenko]

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)

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

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

[dongryphon]

But just to let you know, using the following code (the < 4.1 way, without the Ext.define('..', { override: ... }) don't...

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:

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.

[maksimenko]

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!

[dongryphon]

Glad to hear that solved it.

[Curtis Fletcher]

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.

[skirtle]

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.

[Curtis Fletcher]

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?

[dongryphon]

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.

[Curtis Fletcher]

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.

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

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

[skirtle]

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:

initComponent: function() {
    // Complex init

    Ext.grid.column.Column.superclass.initComponent.call(this);

    // Complex init
}