I'm sorry for this newb question but,
why
// Do NOT put arrays or objects here
in the default options?
Is it relative to the extend method (this function is hard to read)?
Andrés SerrónOctober 27, 2010archive
Thanks saki, amazing work here.
I would keep build function Private by using a clousure as overrides object.
This way we could keep object api clean.
Despite the little dom cleanup you get a more clean documentation doing this.
@Andrés, build function(s) are public on purpose. Developers can override them as they want.
BTW, I'd be quite interested in your code with the private part...
Saki
about this, in every method that we access to the cofig object we could modify it, I think that´s a little dangerous and kind of messy because if we want we can modify the config object in every abstract method we override,
maybe to prevent this we should do
_getConfig:function(config){
config.items = this.getItems();
config.buttons = this.getButtons();
config.tbar = this.getTbar();
config.bbar = this.getBbar();
},
Xam335November 16, 2010archive
Oh I see what you mean. Well this could be used for
Xam335November 16, 2010archive
Oh I see what you mean. Well this could be used for static content, specialy for a factory pattern.
But ok, I didn't get that this comment was this warning. thanks
silvernetDecember 4, 2010archive
Thanks saki,it much better than use many if {..} else{..} in initComponent function.
Andrés SerrónFebruary 7, 2011archive
Sorry for the delay, I forget about this post.
The code I created comes from gathering some know how and doing some testing.
The idea is the Ext.extend has either
- Superclass, overrides
- Constructor, superclass, overrides
Either constructor or overrides could be a clousure with their own local variables.
The only thing I couldn’t emulate properly is the static methods.
“getCount” is visible in each instance, and should be visible in the object that holds the definition of the class.
I will check Crockford words in this, but at first sight seems that the ext class flow and the prototype chain ways has a grey area in that issue.
Back to the factory.
The idea of building without mistake is clearly needed, my quote point to the fact that in each subclassing we add props and methods to the object, that’s a limitation of the current js implementation, and my quote was only in an attempt to clear the DOM a little.
Here is the code.
<code>
SampleClass = function(){
// static
var count = 0;
return {
getCount : function(){
return count;
},
// flaw: won\'t find privateValue as defined inside constructor.
getPriv2 : function(){
return privateValue;
},
constructor: function(){
count++;
// prop, setter, getter will work as they are in the same clousure.
var privateValue = \'Mary\';
this.getPriv = function(){
return privateValue;
}
this.setPriv = function(v){
privateValue = v;
}
SampleClass.superclass.constructor.call(this);
}
}
}
SampleClass = Ext.extend(Ext.Panel,SampleClass());
var t1 = new SampleClass();
var t2 = new SampleClass();
t1.getPriv();
t2.getPriv();
t2.setPriv(\'lulu\');
t1.getPriv();
t2.getPriv();
</code>
The example is purely academic, we have flaws here and we need to put those things to use.
9 comments
Comments are closed on archived posts.