See also:
- Writing a Big Application in Ext
- Abstract classes with Ext JS
- Factory Functions in Ext Extensions (Abstract Classes)
// vim: ts=4:sw=4:nu:fdc=2:nospell
/*global Ext:true, AbstractPanel:true */
/*jslint browser:true, laxbreak:true */
// create namespace
Ext.ns('AbstractPanel');
/**
* @class AbstractPanel
* @extends Ext.Panel
*
* AbstractPanel File Pattern
*
* @author Ing. Jozef Sakáloš
* @copyright (c) 2010, Ing. Jozef Sakáloš
* @version 1.0
* @revision $Id$
* @depends
*
* @see http://tdg-i.com/364/abstract-classes-with-ext-js
* @see http://extjs-eu.omni8.net/writing-a-big-application-in-ext/
* @see http://extjs-eu.omni8.net/factory-functions-in-ext-extensions/
*
* @license This file is released under the
* <a href="http://www.gnu.org/licenses/gpl.html" target="_blank" data-mce-href="http://www.gnu.org/licenses/gpl.html">GNU GPL 3.0</a>
* license. It’s free for use in GPL and GPL compatible open source software,
* but if you want to use the component in a commercial software (closed source),
* you have to get a commercial license.
*/
AbstractPanel = Ext.extend(Ext.Panel, {
// default options - can be overridden on instantiation
// Do NOT put arrays or objects here
border:false
// {{{
// private
,initComponent:function() {
// create config object
var config = {};
// build config
this.buildConfig(config);
// apply config
Ext.apply(this, Ext.apply(this.initialConfig, config));
// call parent
AbstractPanel.superclass.initComponent.call(this);
} // eo function initComponent
// }}}
// {{{
/**
* Builds the config object
* @param {Object} config The config object is passed here
* from initComponent by reference. Do not create or return
* a new config object, add to the passed one instead.
*
* You can override this function if you need to customize it
* or you can override individual build functions called.
*/
,buildConfig:function(config) {
this.buildItems(config);
this.buildButtons(config);
this.buildTbar(config);
this.buildBbar(config);
} // eo function buildConfig
// }}}
// {{{
/**
* Builds items
* @param {Object} config The config object is passed here
* from buildConfig by reference. Do not create or return
* a new config object, add to the passed one instead.
*
* You can override this function if you need to customize it.
*/
,buildItems:function(config) {
config.items = undefined;
} // eo function buildItems
// }}}
// {{{
/**
* Builds buttons
* @param {Object} config The config object is passed here
* from buildConfig by reference. Do not create or return
* a new config object, add to the passed one instead.
*
* You can override this function if you need to customize it.
*/
,buildButtons:function(config) {
config.buttons = undefined;
} // eo function buildButtons
// }}}
// {{{
/**
* Builds top toolbar and its items
* @param {Object} config The config object is passed here
* from buildConfig by reference. Do not create or return
* a new config object, add to the passed one instead.
*
* You can override this function if you need to customize it.
*/
,buildTbar:function(config) {
config.tbar = undefined;
} // eo function buildTbar
// }}}
// {{{
/**
* Builds bottom toolbar and its items
* @param {Object} config The config object is passed here
* from buildConfig by reference. Do not create or return
* a new config object, add to the passed one instead.
*
* You can override this function if you need to customize it.
*/
,buildBbar:function(config) {
config.bbar = undefined;
} // eo function buildBbar
// }}}
}); // eo extend
// eof
I'm a well seasoned developer, consultant and educator of web applications based mainly on Sencha libraries, PHP, MySQL and Node.js. Besides (Apple) computers, I love photography and mountain biking.
Latest posts by saki (see all)
- Ext, Angular, React, and Vue - 27. June 2019
- The Site Resurgence - 11. February 2018
- Configuring ViewModel Hierarchy - 19. June 2015
9 Responses
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.
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();
The example is purely academic, we have flaws here and we need to put those things to use.
Thanks saki,it much better than use many if {..} else{..} in initComponent function.
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
Oh I see what you mean. Well this could be used for
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();
},
@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
@Xam335, see Writing a Big Applications in Ext – part 3 on this blog. It contains the full explanation.
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.
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)?