Swing-agnostic Table&Tree models
Hello,
several questions in one, really. They assume familiarity with Swing's Model classes, but are hopefully more general.
Swing's JTable widget displays data found in an instance of a class implementing TableModel. Swing provides a default implementation (a Vector of Vector), but I find it safer to provide custom TableModel classes for providing my data.
To expose your app-specific data through a custom TableModel class, you can either:
1) store the data in an app-specific TableModel implementation
2) store your data in an app-specific structure, with no dependency on Swing interfaces, and provide a custom TableModel implementation as an Adapter over your app-specific structure.
3) = 2) plus a Controller/Mediator that knows when data is modified
I find solution 1 clumsy, as this makes the business data model depend on a UI package.
But solution2 is a bit tedious. The adapter has to be both ways, so that you can provide the data when the JTable asks them (e.g. to repaint() the table) , and also notify the JTable when your data has changed (the JTable is an observer of its TableModel).
You end up designing a tabular data structure with much of the TableModel functionalities (get() accessors and fireXxxChanged() notifiers), in addition to the the adapter.
Solution 3 uses Controller or Mediator classes, through which all of the data modification requests should flow.
Such classes know about both the app-specific model and the Adapter, and notify the latter when they modify the former.
That spares the app-specific data to worry about notifying changes, but is not much cheaper that solution 2 in terms of maintenance overhead (after each data modification, the controller has to notify the TableModel, much like in solution 2, the business model has to notify the adapter).
Questions:
- Do you have a recommended approach?
- Specifically, do you go for solution 1, or are you worried that a business data class has dependencies on Swing classes (be they model classes)?
- Do you think it would make sense to add Tree and Table classes in the standard collection classes? I have started filing a similar RFE and I wonder whether it deserves lobbying :o)
The afterthought of the last question is, if such classes as the XxxModel had been standard java.util classes, I wouldn't be worried at all by solution 1.
