AutoChild - defining new component - change fields in Listgrid

[lchen]

Hi,

We are using
SmartClient 7.0RC2
Browser: Firefox 3.6.8

We are using Autochild concept for extending one of our components.
Which is working fine while overriding functions etc.

isc.define("BaseClass", "VLayout");

isc.BaseClass.addProperties({
baseGridDefaults: {
_constructor: isc.ListGrid
fields:[
{name: "field1", title: "Title-Field1"
, change: function(){.....}},
{name: "field2", title: "Title-Field2"}
]
}
..............
......
});

Now there is a requirement with the extended class
isc.define("ExtendedClass", "BaseClass");

We need a new field "field3" and remove "field2" in the subcomponent baseGrid in the "ExtendedClass" without touching the baseClass..How can we acheive this?

[Isomorphic]

This isn't something the AutoChild system handles automatically. What you basically want to do is copy the fields definition you're inheriting from the superclass and then add new field definitions to the copy.

[lchen]

What is ListGrid.defaultFields?
I do not find it documented anywhere?

I saw this in my logs which seems to be solving this issue

"To REUSE standard field configuration across multiple ListGrids, use listGrid.defaultFields rather than assigning directly to listGrid.fields."

Comment/Suggest!

If possible point me to location where I can read something about defaultFields

[Isomorphic]

ListGrid.defaultFields is documented in the latest (8.0) release:
http://www.smartclient.com/docs/8.0/....defaultFields

The concept here is that if you have a standard array of fields that you want to apply to all ListGrids in a class, you can't just set "fields" to an array via isc.YourClassName.addProperties({fields:...}) - that would cause all ListGrids within the class to have *the same array* of field objects - leading to all kinds of odd behavior - if you resized a field in one grid, the field would show up at the new size when you redrew other grids, etc.
defaultFields is a quick way around this - when instances of your class are instantiated, the defaultFields will be duplicated and then copied onto the fields attribute for individual instances so you don't end up with the each instance pointing to the same actual array of fields object.

[lchen]

Doesn't this also mean that If we can manipulate and set defaultFields on the run for each subclass, it can work in a way for us.

Adding or removing field on the run will be possible this way.

I expect fields property to be generated only when we create an instance of the base class or extending class(based on (manipulated or generated) defaultFields present for each class).

[Isomorphic]

If you were to manipulate defaultFields from, say, initWidget, you would be manipulating the defaultFields that all instances of the same class are using (wrong).

Whether you are customizing the fields in a particular instance or for a subclass, you need to first copy them, so your copy is unique.