1

When should I create my own TableModelListeners and DataModelEvents?

I know the difference and use of a DefaultTableModel, AbstractTableModel and TableModel.

I have seen in many online Java examples where TableModelListeners and DataModelEvents are explicitly created while creating a class (custom model) that extends either the DefaultTableModel and the AbstractTableModel class.

This is my understanding:

  1. If I am extending a DefaultTableModel then this model already knows how to create DataModelEvents and the TableModelListeners (so that I do not have to add them) listening/observing to these events and also knows to notify the TableModelListeners.

  2. If I am extending an AbstractTableModel then this model already knows how to create DataModelEvents and the TableModelListeners (so that I do not have to add them) listening/observing to these events. But I have to explicitly invoke the firetablechanged() or similar methods to notify the TableModelListeners about the event.

  3. If I am implementing a TableModel then this model already knows how to create DataModelEvents but does not have any TableModelListeners (so that I have to add them) listening/observing to these events. And also I have to explicitly invoke the firetablechanged() or similar methods to notify the TableModelListeners about the event.

user547453
  • 1,035
  • 6
  • 22
  • 38
  • not clear and nice described question, maybe reason for down_voter, – mKorbel Jan 11 '13 at 21:53
  • may be the person who down voted my question did not read the title. – user547453 Jan 11 '13 at 22:04
  • 1
    You should rarely need to implement `TableModelListener`. I would tend use them if I was performing additional calculations off the table model (such as summing columns or rows) and wanted to know when the data in the table changed. I can't think a reason to ever have to create a `TableModelEvent`, unless you've opted to implement directly from the `TableModel` interface, but, quite frankly, I think you'd have to be mad when `AbstractTableModel` provides all the event notification mechanisms for you. You third point is invalid. `TableModel` has no capacity to create anything... – MadProgrammer Jan 11 '13 at 22:14
  • @MadProgrammer...thanks for clarifying my question. Why is my third point invalid. I did say that it does not have any listeners and I have to add them. I believe you are saying that it does not even have the firetablechanged() or similar methods to notify and I have to create them as well. – user547453 Jan 11 '13 at 22:19
  • 1
    @user547453 TableModel is an interface, it has no capacity to create anything, nor does it define any functionality for firing events. It has methods adding/removing listeners, but how that is achieved is up to the implementations – MadProgrammer Jan 11 '13 at 23:56

2 Answers2

3

  1. DefaultTableModel (extends AbstractTableModel), by default all notifiers (DataModelEvents) are implemented and correctly, by default to have to override only editable (for TableCellEditor and if needed) and Column Class (not required in most cases)

  2. AbstractTableModel, have to override all required methods, otherwise they don't work in compare with DefaultTableModel, and work only how these methods are implemented, by default all notifiers (DataModelEvents) is required to override too, otherwise JTables view doesn't shows proper or expected value

  3. DefaultTableModel is based on premature Arrays (even I saw HashMap in DefaultTableModel, no issue), AbstractTableModel allows to implements various arrays types without any restrictions (implemented in concrete arrays API)

  4. by using DefaultTableModel is everything allowed, everything is accessible (methods implemented in API), in compare with AbstractTableModel,

  5. AbstractTableModel is about restictions, modifying, add or override methods,

  6. for JTable without any definitions for XxxTableModel is used DefaultTableModel

mKorbel
  • 109,525
  • 20
  • 134
  • 319
3

I defer to @mKorbel on DefaultTableModel, which is well suited to cases that can rely on its straightforward mutators. It is limited by the internal use of Vector, a supported but obsolescent Collection that carries (possibly) needless synchronization overhead.

AbstractTableModel offers much more flexibility in exposing your application's data model to a JTable view. It should be used in cases for which DefaultTableModel is unsuitable.

Focusing on your question, JTable implements TableModelListener, and it listens to its own TableModel. An arbitrary number of other views can also listens to the same model; DisplayPanel is an example that listens to an AbstractTableModel named CheckModel. Your TableModel should fire a suitable TableModelEvent if it contains the data needed by your view(s) to update themselves. If not, you can define your own event types using the same EventListenerList mechanism used by JTable, described here, and mentioned here.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
  • Thanks @trashgod....This is what I was missing. I also did not realize the JTable is the one that implements the TableModelListener. – user547453 Jan 12 '13 at 07:09
  • 1
    Exactly; _all_ class instances listening to a given `TableModel`, including the `JTable` itself, receive the fired event. – trashgod Jan 12 '13 at 07:56