Skip to main content

TreeTable revisited

3 replies [Last post]
Joined: 2009-11-20

It might be scary to think about starting an implementation by extending JComponent, but I wanted to try something new and that just happens to be where I started. Ironically it doesn't reinvent the wheel as much as Netbean's Outline component but that's only because I used a dedicated JTable and JTree under the hood. Right now everything is implemented in the JComponent as opposed to a BasicTreeTableUI. I'd like to move the UI stuff so that creating a SwingX or other JTable/JTree extension compatible TreeTable would be possible (for example, in SwingX, the dedicated tree/tables would be JXTree/JXTable). Also, a TreeTableUI from scratch should be able to start its implementation without prerequisites; though I don't know if any L&F's actually do start from javax.swing.plaf. instead of javax.swing.plaf.basic.

Anyway onto some of the implementations that have been changed:

There is one thing that I really liked with Outline's implementation and that is the TreeModel, RowModel separation. So that is more of a change from JXTreeTable.

Variable row heights are supported. The JTable's row heights are kept in sync with the JTree's row heights. The JTree's calculated row height takes into account all cell renderer's preferred size in the row.

No more clumsy TableModelEvents that utilize fireTableDataChanged or delayedFireTableChanged when all the data has in fact not changed. The most minimalistic TableModelEvent that can be determined is produced for changes to the TableModel. There is a public getTableModel() method so that changes to the TableModel can be heard in terms of a TableModelListener. It differs from listening to the TreeModel/RowModel as rows inserted/deleted due to expansion/collapse can be listened to, which provides more information that TreeExpansionEvents (you get the number of rows that have came into/fallen out of view).

The JTable's ListSelectionModel is implemented by wrapping the JTree's TreeSelectionModel, literally. It doesn't duplicate the data into a DefaultListSelectionModel. This is also queryable via getRowSelectionModel() so that the selection can be listened to with a ListSelectionListener if desired.

Editing has been butchered. Or rather, nothing custom in the way of editing has been implemented yet.

The source is in

With dependencies in the treetable and event folders.

Any opinions? Is the painting mechanism bad (aside from not being in a UI delegate)?

Edit: Moved UI details to BasicTreeTableUI:

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2009-11-20

I've updated with a view-based RowSorter for TreeTable. Just as is with JTable, all that is required is to call setAutoCreateRowSorter(true).

The actual RowSorter has to be a TreeTableSorter instance. Probably should make it an interface and put the actual implementation in DefaultTreeTableSorter.

There is one limitation: Each node has to have its own RowSorter which is maintained in an IdentityHashMap. This means duplicate nodes that are the exact same object (comparison by == operator returns true) will overwrite each others' sorter in the map. It is an issue even if the nodes are supposed to have the same sort/filter results because the sorter's are set visible/hidden depending on the expanded state. Also removal of one from the model will destroy the others' sort state. So, if duplicate nodes are required anywhere in the tree, then they have to be wrapped in unique objects; they can be equal by the equals() method, but not by the == operator.

Example can be seen in the test area:

Joined: 2006-01-26

I have tried your TreeTableTest program and the sorting mechanism seems to fit my needs.
I have not time to look into the details of your implementation. My problem (no criticism!) is that the swingx JXTreeTable and your TreeTable are incompatible and would require a large migration effort for my application. So that's no option for me.
But I recommend to all swingx developers to have a look on it so that some of your ideas may be integrated to the existing JXTreeTable component.

Joined: 2009-11-20

The only suggestion I can offer you is to extend TreeTable to include all the JXTreeTable constructors/methods you use. That too may require a bit of time. Of course, you can always wait for the Swingx developers to do your work for you :)