PDA

View Full Version : What is the best practice for overriding mixins?



thorben
12 Aug 2011, 1:43 AM
I would like to override Ext.util.Floating, which is mixed into Ext.container.AbstractContainer.

However,

Ext.override(Ext.util.Floating, { getConstrainVector : function() { ... } });

won't change getConstrainVector of Ext.container.AbstractContainer.

It think this makes sense in a way, as mixins are (are they?) copied into the target class on Ext.define, which is called before Ext.override.

Still it would be nice to override mixins; any ideas how to achieve this?

jay@moduscreate.com
12 Aug 2011, 8:23 AM
Normally, when you modify a prototype of a class, the instances of the classes are modified. However the sencha implementation of Mixins breaks that because the keys are duplicated, 'mixing in' the classes.

I'm going to see if I can ask Jackie directly for this. It's an interesting problem.

mberrie
13 Aug 2011, 1:35 AM
I found that overriding a mixin actually worked for me as expected as long as the mixin's prototype is modified BEFORE any class that uses that mixin is defined.

This restriction is actually expected due to how the Mixin system works in Ext (JG has pointed this out already).

So the actual problem is the load order, and guaranteeing that the mixin is modifed before other class definitions are processed.

This worked for me in a setup where I use Ext.Loader!
Follow this pattern:



Ext.require('Ext.util.Floating', function() {
Ext.override(Ext.util.Floating, {
property: ...
}
});


I tried this with Ext.form.Labelable and it worked out. This will trigger a load of the mixin class, then override the class before it is 'mixed in' in any other Ext class.


This will not work with one of the 'precompiled' files (e.g. ext-all.js or bootstrap.js).

Not sure if the SDK does package files according to their load order. If so, it could work. I haven't tried that yet.

thorben
16 Aug 2011, 4:49 AM
Thanks for your answers! Of course, in the current implementation, the loading order is crucial (as always with JavaScript ;)).

As we use the sandboxing version (we use Ext3 and 4 on one page), this gets quite complicated, as mberrie has already pointed out.

In my particular case, overriding the behavior in AbstractContainer was ok, but in general a different implementation of Ext.override (which would need to run through all the classes mixing in the mixin) would be quite interesting, though it might have some drawbacks (especially performance, but that might not be so bad). The different behavior could also be enforced by an additional parameter, so that this is only used when required.

So at the moment, I think this behavior is ok, though not conforming to my intuitive unterstanding of Ext.override. Just something else you need to know about Ext.