Re: what is the purpose of a table model?
fgerrvsbfwnhhy@mailinator.com wrote:
Hi all
apologies for a dorky question...
but could someone tell me (or point me to a webpage that explains)
what is the purpose of a table model in Java?
From the information I gathered so far it looks like table models were
referred to in the SGML standard in the late 80's. I guess when it
comes to SGML it is more like a reference or example on specifications
that a table should have, in order for it to adhere to the SGML
standard.
But in Java the table model is a class, from which object instances
and, I am guessing, tables can be created. So I am a bit confused
about what the term "table model" represents in Java.
If anyone can clarify this, thanks in advance
I'll assume you are asking about javax.swing.table.TableModel,
in connection with javax.swing.JTable.
Most Swing things have this same kind of division into "view"
and "model" parts. The view is responsible for what you see on the
screen and how you interact with it, while the model is responsible
for storing the data and keeping track of changes to it. A JTable
is concerned with formatting, scrolling, resizing, and other such
presentation-related things, while the TableModel serves up the data
that the JTable presents.
Why separate them? It's not hard to imagine having all the
functions bundled into one big JMotherOfAllTables class, but some
flexibility is sacrificed in the process. For example, suppose you
have a very long table and you would like to let the user to open two
windows on it simultaneously, one showing a few rows near the top
and the other showing some rows near the bottom. If you're using a
JMotherOfAllTables instance, an object that actually contains all
the data being displayed, it's going to be quite awkward to get this
setup to work. You'd need to make two copies of the data, one for
each JMotherOfAllTables, and then worry about how to propagate changes
from one to the other as the user makes entries in both windows. Or
else you'd need a JMotherOfAllTables that supported multiple windows,
scrolling them independently and allowing the user to select two rows
in the top table and one in the bottom and somehow making sense of it.
But with the division between view and model, all is sweetness
and light. You park the data in a TableModel, with no worries about
reconciling differences between divergent copies, and you create two
or three or twenty JTables all using the same TableModel instance.
If the user makes a change in one window, the JTable sends it to the
TableModel for validation and processing, and the TableModel notifies
all its JTables of the change. If the same row happens to be visible
in another JTable's window, the change automatically shows up there
with no effort on your part. Or if the other JTable isn't displaying
that row at the moment but scrolls to it later, it shows the up-to-date
information obtained from the TableModel.
So: Roughly speaking, the TableModel manages the data and the
JTable manages the display. That's perhaps an oversimplification, but
it's a useful way to think about the relationship and the two roles
within it. There's more about the model/view division in the Swing
section of the on-line Java Tutorial; you might find it helpful. When
you understand why a JButton has a ButtonModel, you will have achieved
enlightenment.
--
Eric.Sosman@sun.com