First off, when working with TreeTable widget I have found that DefaultTreeTableModel class just accepts instances of TreeTableColumnModel. However this is an implementation rather than an interface. More importantly that implementation determines the type of the row (to be FlattenTreeTableNode). When dealing with heterogeneous data types in the same tree, I often have the need to do something different based on the domain data types.
As an example let’s say we have a tree made up of groups and fields. Besides the tree view itself, we have got another column that needs to know upon invocation of ColumnModel#getValue() which domain type is behind the row it has been asked to retrieve a value for. Let’s say groups can have comments, while fields cannot. So a decision based on the type is required.
Typically I do achieve this by extending TableNode interface so that it becomes generic like
interface CustomTableNode<DomainType> extends TableNode {
data: DomainType;
}
Within the column model implementation (which would implement ColumnModel<CustomTableNode, …>) I can then refer to row.data without the need to cast to that type.
Second, Iam wondering if that widget’ api is flawed since a table node instance carries an identifier (id property) but is lacking type information. My point is, if I do not proceed as explained above (introducing property “data” in extending interface) the alternative is to have just an identifier. In a tree made up of heterogeneous domain types this is not sufficient as I can’t tell the involved types apart.
