One missing link in javax.swing.table.* package

R

RC

In javax.swing.table.* package

I can see the link between TableColumn and DefaultTableColumnModel by:

DefaultTableColumnModel tableColumnModel =
new DefaultTableColumnModel();

TableColumn tableColumn = new TableColumn(0, 45);
tavleColumn.setHeaderValue("Column 0");

tableColumnModel.addColumn(tableColumn);

I can also see the link between DefaultTableModel and JTable by

DefaultTableModel tableModel = new DefaultTableModel(columnNames[], 1);
JTable table = new JTable(tableModel);

But I don't see the link between DefaultTableColumnModel and
DefaultTableModel

Why there is no such constructor like

new DefaultTableModel(DefaultTableColumnModel, ...); ?
or setTableColumnModel(TableColumnModel ...);


I try JTableHeader tableHeader = new JTableHeader(DefaultTableModel);
tableHeader.setTable(table);

But that doesn't help me anything at all.

Where is that missing link between DefaultTableColumnModel and
DefaultTableModel?
or between TableColumnModel and TableModel?

Thank Q very much in advance!
 
O

Oliver Wong

RC said:
Where is that missing link between DefaultTableColumnModel and
DefaultTableModel?
or between TableColumnModel and TableModel?

Thank Q very much in advance!

TableModel is an object that can be queried to provide information
about tabular data. This object contains no information about how this
data should be displayed, or what business rules might apply to the
interaction between the user and this data (e.g. this user cannot edit
certain parts of the data, etc.)

TableColumnModel is an object represent a part GUI widget.
Specifically, it represents a single column in a JTable. The
TableColumnModel controls things like what renderer should be used to draw
things on the screen, whether the column is resizable or not, what it's
width should be, etc.

One lives in the data world, the other in the GUI world. There is no
direct link between them. Their commonality is that they both interact
with instances of JTable.

- Oliver
 
E

Eric Sosman

Oliver said:
TableModel is an object that can be queried to provide information
about tabular data. This object contains no information about how this
data should be displayed, or what business rules might apply to the
interaction between the user and this data (e.g. this user cannot edit
certain parts of the data, etc.)

You were doing fine, and I was applauding, right up until
the parenthetical remark. How do you reconcile that remark with
the isCellEditable() method?
 
O

Oliver Wong

Eric Sosman said:
You were doing fine, and I was applauding, right up until
the parenthetical remark. How do you reconcile that remark with
the isCellEditable() method?

Bad design on Sun's part? Surely, the error cannot be mine. ;)

- Oliver
 
B

Bjorn Abelli

Oliver Wong said:
Bad design on Sun's part? Surely, the error cannot be mine. ;)

I'm not sure I get the objections of either part here...

I agree with Oliver that the TableModel should be a "backing unit", separate
from the user interface, but now I'm not quite sure what you mean with
"interaction between the user and this [displayed] data".

As far as I'm concerned there is still a difference between the possibility
to edit displayed data (in the interface) and the isCellEditable() in the
TableModel; the possibility to affect the "backing data".

/// Bjorn A
 
M

Martin Gregorie

Bjorn said:
Oliver Wong said:
Bad design on Sun's part? Surely, the error cannot be mine. ;)

I'm not sure I get the objections of either part here...

I agree with Oliver that the TableModel should be a "backing unit", separate
from the user interface, but now I'm not quite sure what you mean with
"interaction between the user and this [displayed] data".

As far as I'm concerned there is still a difference between the possibility
to edit displayed data (in the interface) and the isCellEditable() in the
TableModel; the possibility to affect the "backing data".
This doesn't seem unreasonable. After all isCellEditable() does control
whether the underlying data can change in response to user input and
hence whether (a) the edited cell content might need to be saved
someplace and (b) whether the display needs updating to show the change.

On a related point, I'm quite prepared to believe that there is a
problem either in the design or documentation of JTable and TableModel.
I haven't been able to discover how to update the display when the
underlying data changes. JTable doesn't seem to respond to repaint() and
I haven't spotted a way of causing a repaint after updating the user
data structure that TableModel is mapped onto.
 
E

Eric Sosman

Bjorn said:
Oliver Wong said:
Bad design on Sun's part? Surely, the error cannot be mine. ;)

I'm not sure I get the objections of either part here...

I agree with Oliver that the TableModel should be a "backing unit", separate
from the user interface, but now I'm not quite sure what you mean with
"interaction between the user and this [displayed] data".

As far as I'm concerned there is still a difference between the possibility
to edit displayed data (in the interface) and the isCellEditable() in the
TableModel; the possibility to affect the "backing data".

If you could change the displayed data without changing
the model's data, in what sense would the model be "backing"
the display?

If you edit the content of a displayed cell (and the edit
passes whatever validity checks are in force), the table eventually
calls the model's setValueAt() method with the newly-entered data.
It is conceivable that setValueAt() might be a no-op and leave the
model unchanged, but that's a pretty strange thing to do -- if the
table subsequently called getValueAt() on the cell, perhaps during
a repaint while scrolling or something, the edit would "softly and
silently vanish away!"
 
E

Eric Sosman

Martin said:
[...]
On a related point, I'm quite prepared to believe that there is a
problem either in the design or documentation of JTable and TableModel.
I haven't been able to discover how to update the display when the
underlying data changes. JTable doesn't seem to respond to repaint() and
I haven't spotted a way of causing a repaint after updating the user
data structure that TableModel is mapped onto.

Extend AbstractTableModel, and call fireTableDataChanged,
fireTableRowsInserted, etc., methods. These are convenience
methods that eventually call the tableChanged method of the
TableModelListener interface; the JTable listens to its model.
 
E

Esmond Pitt

Martin said:
I haven't been able to discover how to update the display when the
underlying data changes. JTable doesn't seem to respond to repaint() and
I haven't spotted a way of causing a repaint after updating the user
data structure that TableModel is mapped onto.

(i) As Eric said, extend AbstractTableModel and call the appopriate
fireTableXXXChanged() method, or (ii) extend DefaultTableModel and it
happens automatically when you call setValueAt(). If you override that,
be sure to call super.setValueAt() so the firing still happens.
 
B

Bjorn Abelli

Eric Sosman said:
Bjorn Abelli wrote:
I agree with Oliver that the TableModel should be a "backing unit",
separate from the user interface, but now I'm not quite sure what you
mean with "interaction between the user and this [displayed] data".

As far as I'm concerned there is still a difference between the
possibility to edit displayed data (in the interface) and the
isCellEditable() in the TableModel; the possibility to affect the
"backing data".

If you could change the displayed data without changing
the model's data, in what sense would the model be "backing"
the display?

As it's the data "backing" the displayed data, not "being" the displayed
data... ;-)

In any application using "tabular data", or other types of data for that
matter, there are numerous ways of relating the display to that data; when
and how changes in the "backing data" should be manipulated, viewed and
committed.

In that sense, the displayed data could (and maybe even should) be
considered a "working copy" of the data provided by the TableModel, but...
If you edit the content of a displayed cell (and the edit
passes whatever validity checks are in force), the table eventually
calls the model's setValueAt() method with the newly-entered data.
It is conceivable that setValueAt() might be a no-op and leave the
model unchanged, but that's a pretty strange thing to do -- if the
table subsequently called getValueAt() on the cell, perhaps during
a repaint while scrolling or something, the edit would "softly and
silently vanish away!"

....in my opinion, a JTable and its TableModel are too tightly coupled.

(But that's only my opinion, and it really doesn't bother me that much
either).

Consider, e.g., a table where possible values in some cells are constrained
by values in some other cells in the same table. You have to change all
involved values "at the same time", before committing them, which becomes
slightly more complicated with this tight coupling.

In practice, this makes the TableModel used in a JTable the "working copy"
of the data, while the diplayed data becomes a "view of the data in the
working copy", which means that you in many cases must have (at least) yet
another layer of data, of which the TableModel is the "working copy"...

Howevere you look at it, the displayed data and the data provided by the
TableModel are still two different things, even considering the
"autocommitting" mechanisms coupling the two.

/// Bjorn A
 
M

Martin Gregorie

Esmond said:
(i) As Eric said, extend AbstractTableModel and call the appopriate
fireTableXXXChanged() method, or (ii) extend DefaultTableModel and it
happens automatically when you call setValueAt(). If you override that,
be sure to call super.setValueAt() so the firing still happens.
Thanks to you and Eric for that pointer.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,480
Members
44,900
Latest member
Nell636132

Latest Threads

Top