Sorting a JTable with a delegating TableModel

B

Brian J. Sayatovic

I've found nearly every reference to sorting tablesin Java to be one
of two things: (1) using the delegating model presentign in the Swing
Tutorial or (2) sorting the actual data in the actual model.

Because a model is a model of data, it is not unexpected that one
would use their own custom model that more accurately represents their
data. This is the approach I'm taking. Thus, my model represents a
List of objects. Each row represents an object,and each c olumn in
the row represents the obejct's value for a certain property (i.e.
name, date, color, etc.).

When the system needs to delete one of those objects, I delete it from
the list in my model and fire a table model change event indiciating a
deleted row.

However, I think I'm encountering a problem when I wrap my model in a
SortableTableModel. The problem is that the deleted row could be
mapped through the sorted table model wrapper. Thus, if I delete
object 2 (located in row 2 in the real data model), the event fired
will be that row 2 was deleted. However, from the point of view of
the JTable, it may have been row 1 that was deleted (assuming teh
sortable table model had sorted such that row 2 was in the first row).

I don't believe Sun's example handles this. Perhaps they expect all
changes to the data model to happen through the model's
setValueAt(y,x) method. But in my case, the objects in the model
could be edited in another dialog, and when OK is pressed, I want the
changes reflected in the JTable representing the list of all objects.
So, the changes would not go through the sortable table model at all,
but rather, through the acutal underlying data model.

I'm guessing the solution is to intercept the table model change
events with a listener designed to re-map the row indices in the event
(which may have to be more than 1 event once mapped if the re-sorted
indices are not contiguous). But I'm concerned that I may be going
down the wrong path if Su themselves didn't forsee this for their
example.

Thoughts?

Regards,
Brian.
 
D

Dave Glasser

(e-mail address removed) (Brian J. Sayatovic) wrote on 10 Jul 2003 08:09:21 -0700
in comp.lang.java.gui:
I've found nearly every reference to sorting tablesin Java to be one
of two things: (1) using the delegating model presentign in the Swing
Tutorial or (2) sorting the actual data in the actual model.

Because a model is a model of data, it is not unexpected that one
would use their own custom model that more accurately represents their
data. This is the approach I'm taking. Thus, my model represents a
List of objects. Each row represents an object,and each c olumn in
the row represents the obejct's value for a certain property (i.e.
name, date, color, etc.).

When the system needs to delete one of those objects, I delete it from
the list in my model and fire a table model change event indiciating a
deleted row.

However, I think I'm encountering a problem when I wrap my model in a
SortableTableModel. The problem is that the deleted row could be
mapped through the sorted table model wrapper. Thus, if I delete
object 2 (located in row 2 in the real data model), the event fired
will be that row 2 was deleted. However, from the point of view of
the JTable, it may have been row 1 that was deleted (assuming teh
sortable table model had sorted such that row 2 was in the first row).

I don't believe Sun's example handles this. Perhaps they expect all
changes to the data model to happen through the model's
setValueAt(y,x) method. But in my case, the objects in the model
could be edited in another dialog, and when OK is pressed, I want the
changes reflected in the JTable representing the list of all objects.
So, the changes would not go through the sortable table model at all,
but rather, through the acutal underlying data model.

I'm guessing the solution is to intercept the table model change
events with a listener designed to re-map the row indices in the event
(which may have to be more than 1 event once mapped if the re-sorted
indices are not contiguous). But I'm concerned that I may be going
down the wrong path if Su themselves didn't forsee this for their
example.

I think Sun's example was only intended as a quick proof-of-concept.
Your guess about intercepting the events of the actual table model is
the right approach, IMO. But in my experience, unless your JTable is
strictly read-only--no updating, adding or deleting rows--then using a
wrapper TableModel to handle sorting can lead to more problems than
it's worth. Is there a compelling reason *not* to just sort the list
of data objects? If not, you'll probably save yourself a lot of grief
by doing it that way, even though you'll lose the benefit of a
"one-size-fits-all" table sorter.
 
K

Kleopatra

Brian J. Sayatovic said:
I've found nearly every reference to sorting tablesin Java to be one
of two things: (1) using the delegating model presentign in the Swing
Tutorial or (2) sorting the actual data in the actual model.

Because a model is a model of data, it is not unexpected that one
would use their own custom model that more accurately represents their
data. This is the approach I'm taking. Thus, my model represents a
List of objects. Each row represents an object,and each c olumn in
the row represents the obejct's value for a certain property (i.e.
name, date, color, etc.).

When the system needs to delete one of those objects, I delete it from
the list in my model and fire a table model change event indiciating a
deleted row.

However, I think I'm encountering a problem when I wrap my model in a
SortableTableModel. The problem is that the deleted row could be
mapped through the sorted table model wrapper. Thus, if I delete
object 2 (located in row 2 in the real data model), the event fired
will be that row 2 was deleted. However, from the point of view of
the JTable, it may have been row 1 that was deleted (assuming teh
sortable table model had sorted such that row 2 was in the first row).

I don't believe Sun's example handles this.

Agreed - but then: it's only an example (as Dave already mentioned).

One problem with sun's example (last time I looked) is in the
TableModelListener section of TableMap: tableChanged simply routes the
events from the original model. Instead it should convert the received
event into the coordinates of the filter and then fire the adjusted
event btw: the filter should _not_ delegate the listeners to the
original but manage them itself.
I'm guessing the solution is to intercept the table model change
events with a listener designed to re-map the row indices in the event
(which may have to be more than 1 event once mapped if the re-sorted
indices are not contiguous). But I'm concerned that I may be going
down the wrong path if Su themselves didn't forsee this for their
example.

Exactly (at least that's the path I go :) As for block inserts/deletes
(in the original) that are non-contiguous after sorting: IMO the only
way to cope with them is to fire a dataChanged. If you map such a
blocked event into several rowsDeleted f.i. then a client listening to
the filter might try to access parts of the model that are no longer
available in the original.


Greetings
Jeanette
 

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,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top