In the current developer preview 1 the treestore has a private inner class TreeModel.
When trying to extend things you run into the problem that a) TreeModel is not visible to outer classes and b) is not a ModelData (or Map-style) class any more.
Maintaining additional information in other way then applying it to the wrapper directly is possible, but also more complex.
It would be of great use if one could overwrite a delegate creating the TreeModel to be able to create additional data/behavior by subclassing the TreeModel class.
ModelData does not exist anymore, nor do any of the basic subclasses, including the TreeModel class. In all cases, any bean-like class is supported, as in GWT's 2.1 editor framework, and instead of string-keyed map lookups, data can be stored any way the developer chooses. For the ListStore, this poses little problem, but providing tree structure is more complex.
The TreeStore needs to be able to support both the case where a service provides the tree structure and where the models provide their own structure. We started with the former, with the idea that a trivial Loader can be implemented to read from the models themselves – see the FullTreeLoader for the first draft of this idea. Both cases will be supported in the final release.
The FullTreeLoader.TreeModel<M> interface is designed to allow a tree of similarly typed object to be loaded. In contrast, the TreeStore.TreeNode<P extends TreeNode<?, ?>, C> interface is intended to allow the type of parents and children to be part of the tree structure. The former allows for simpler type declarations, but only homogeneous trees can be assembled, whereas the latter allows the developer to indicate the special tree hierarchies, with certain types wrapping other types, but would be overkill and possibly confusing if used to provide a homogeneous tree structure, which is why we didn't make it public or provide a way to indicate this structure.
Very likely the FullTreeLoad.TreeModel approach, where a node can describe its children, will be the final approach, but even in a case like that (as in GXT 2), the API can be somewhat confusing, as modifying the list returned by getChildren() has no effect without also calling store.update(M) on the model, and using the TreeStore add methods have no effect on the list in getChildren().
If you have suggestions or feedback for how to keep this as flexible as possible but still have the API make sense to beginners, please share it here. The approach taken so far is to fulfill the service-based use case until we can decide on an approach to use for models. The TreeModel in TreeStore is only there to contain inner tree details, and is not suitable for being extended as a model object, unless you intended this 'delegate' to handle sorting and filtering?
Thanks for your feedback, and looking forward to any thoughts you may have.