TreeNode.attributes, Record.data, and every other object

[mschwartz]

TreeNode has .attributes where much of the initialConfig of the node is stored - things you add that aren't part of the node base object.

Record has .data where all the record's data fields are stored.

First of all, there's no consistency here. Why not TreeNode.data instead of .attributes? It would be orthagonal, IMO, to use the same property name.

Second, since every other object (ok, maybe I'm overlooking one here/there) uses neither .data or .attributes kind of thing, our custom fields/properties we add risk a namespace (within the object) collision with what the ExtJS core programmers might add in ExtJS 9.x.

I know it's way too late in the ballgame, but this is probably something that should be considered. A very *rough* proposal would be something like:

1. Choose a property name reserved for applications. How about appData.
2. Record.data -> Record.appData
3. TreeNode.attributes -> TreeNode.appData
4. Ext.extend -> Container.appData (for non functions?)

Even adding functions to Ext classes via Ext.extend is a risk of namespace collision. Today, onFooBar() is perfectly fine, yet in ExtJS 9.x, they decide to implement onFooBar() in the class you extended.

Anyhow, just throwing this out there to see if there's anything to discuss.

[Eric24]

+1

Although I think just using "data" is fine. What I've typically done (specifically to avoid collisions and also to group my extra properties for convenience) is using "$data".