View Full Version : Why use preconfigured classes?

27 Jun 2008, 12:39 PM
It seems like the best practice is to create page components as pre-configured classes, as opposed to creating a new component instance and defining everything as a config option. Someone even recommends putting these components in their own include files, even if they are specific to one page and will not be shared. (Thats my understanding anyway)

What's the reason for this?

27 Jun 2008, 12:48 PM
I don't know. Why not just use a factory method which spits out correctly configured objects rather than creating subclasses?

I think this has caught on because of cargo cult programming.

27 Jun 2008, 1:13 PM
I think it depends on your end goals. If your classes have 90% the same configs, it makes sense to keep that stuff in the same place and applying the last 10% upon instantiation - instead of having to pass it in every time. It makes business level component logic just a tad bit smaller.

27 Jun 2008, 11:14 PM
WHat's the difference between that and having a function?

funtion getProductGrid() {
return new Ext.Grid.GridPanel({
// predefined configuration here!

28 Jun 2008, 4:36 AM
I must agree with Animal on this one.
Pre-configured classes (especially when they involve scoped event/button/menu handlers) cause confusion for the novice.

There is something to be said for simplicity: (pseudo'ed here)


function getProductGrid(config) {

var PG = new Ext.Grid.GridPanel(
Ext.apply( {
// predefined configuration here!
,config||{}); //last minute tweaks

Ext.apply(PG, GPClassFixes); //any custom behavior/bug fixes applied to the instance

//cleanup for next instance (there will be only one of these)
PG.on( 'destroy' , function(grid) { App.ProductsGrid = null; }, null, {single:true});

//any custom actions to perform ?

//set a public reference at the same time
return (App.ProductsGrid = PG);

tabs.add( getProductGrid({title:'BackOrdered'}) );
tabs.setActiveTab(App.ProductsGrid); //start using the namespace references

//or, concentrate on run-time behavior here:

(App.ProductsGrid || getProductGrid({
title :'BackOrdered',
renderTo :'someWhereSpecial',
height : 500,
width : 700,
plugins : [ new SomeFancyPlugin() ], //only for this instance
bbar : false, //exclude the default PagingToolBar
_loadParams : { products:'BO' },
//use the same approach to hook up a form definition:
listeners :{
'rowclick' : function(grid, rowIndex, e){ getMaintForm().editGridRecord.apply(null, arguments); }
}) ).show();
All the same goods, just a syntax that documents the App behaviour a bit more clearly; possible a bit less code? :-?

IMHO: I would have to say a large percentage of Ext developers are not here to learn the nuances of true class-based development. They often just want to get the job done.

Luckily, the framework allows for either(and other) approaches.

29 Jun 2008, 7:20 AM
I'm coming from the point of view that newbs to OO JS have. For most of 'em, the pre-configured class is perfect because it does not too overly complicated for them. There are many approaches to doing the same thing - mainly because there are people of all different levels of understanding of development in general. Each approach has it's advantages and disadvantages. One person may favor one over the other for their own reason, etc.

Now, there are folks who are just using the patterns without really knowing that there are better/other ways of accomplishing their tasks,etc. For them, eh - i don't know what to say but - read? :)