Sun's swing TableSorter

[VisionSet]

I've just been looking over the newish (Feb '04) TableModel implementation
that Sun have in their swing tutorial.

<http://java.sun.com/docs/books/tutorial/uiswing/components/table.html>

<http://java.sun.com/docs/books/tutorial/uiswing/components/example-1dot4/Ta
bleSorter.java>

It is superb. It Decorates any existing TableModel with very flexible
sorting abilities.

It extracts any Comparators that exist for the given column class types
If that fails it creates its own from your classes comparable
If that fails it uses a default lexical comparator.

You can also add new Comparators to the model for any particular class at
any time.

The only slight niggle I could see, is that the Comparators are stored keyed
by class type, so you can only have one Comparator at a time for each class
type.

You could fit an interface to column classes that need this functionality
and watch for this in the TableSorter, then ask the column class object for
its preferred comparator.

It sorts in both directions and returns the list to the original unsorted
state, by cycling through mouse clicks on the header. It also does compound
sorts if you hold down <ctrl> And you get pretty icons to show column/sorted
state.

And all in 250 lines of code!

 

[Tim Ward]

I've just been looking over the newish (Feb '04) TableModel implementation
that Sun have in their swing tutorial.

It is superb.

Oh, have they fixed it recently then? - it used to get row selections
completely wrong.

 

[Kleopatra]

I tend to disagree: it's better than the last try and now at least seems
to do the sorting correctly. Mixing controller/view issues into the
model was not the best design decision (even for a mere example), IMO.
Some implementation details look a bit suspicious (like not re-wiring
the event source when routing events from the underlying model).

Oh, have they fixed it recently then? - it used to get row selections
completely wrong.

Selections are cleared when sorting.

Might be a starting point, though

Greetings
Jeanette

 

[Tim Ward]

I tend to disagree: it's better than the last try and now at least seems
to do the sorting correctly. Mixing controller/view issues into the
model was not the best design decision (even for a mere example), IMO.
Some implementation details look a bit suspicious (like not re-wiring
the event source when routing events from the underlying model).


Selections are cleared when sorting.

Ah, right, that's a "no" then. I'll continue to use my version which gets
row selections right.

 

[VisionSet]

I tend to disagree: it's better than the last try and now at least seems
to do the sorting correctly. Mixing controller/view issues into the
model was not the best design decision (even for a mere example), IMO.
Some implementation details look a bit suspicious (like not re-wiring
the event source when routing events from the underlying model).

It is an example and I think easy getting it up and running is a prime
concern.
The actual integration of the listener within the class is quite superficial
and can easily be separated. I wouldn't be suprised if this eventually
makes it into SDK 1.5.

If it had no criticisms I guess it would already be in the SDK.

Its main advantage is the decorator approach, which other peoples
implementations seem to avoid.

 

[Kleopatra]

It is an example

That's an old debate: how good in terms of "best practices" should an
example be? My opinion is that it should be damned good - especially if
it's _the_ example in _the_ tutorial.

and I think easy getting it up and running is a prime
concern.
The actual integration of the listener within the class is quite superficial
and can easily be separated.

Maybe - my guess (but really nothing but a guess is that they
decided to move the header into the sorter to guarantee a repaint after
sorting. That would be short-cut around the missing columnUpdated event
.... And firing a tableDataChanged after sorting smells fishy as well. So
I would expect some trouble to get that clean - nothing big nor
unsolvable, but just that sort of accumulated small efforts that are so
annoying at times when trying to make things _really_ work.

I wouldn't be suprised if this eventually
makes it into SDK 1.5.

hope not - at least not without providing support for properly keeping
the selection state. That's a were the real work lurks, I suspect.

Its main advantage is the decorator approach, which other peoples
implementations seem to avoid.

I agree. But that's not quite enough.

Greetings
Jeanette

 

[Shane Petroff]

So Jeanette, is your criticism limited to the design of the newer impl?
I agree that it is poor choice for a tutorial, but if it is functionally
complete, I might be tempted to convert some code. (I can live with
losing selections since mine does the same

hope not - at least not without providing support for properly keeping
the selection state.

How would you handle SINGLE_INTERVAL_SELECTION? Or do you just mean
maintaining the current set of selected indices and 'reselecting' those?

 

[Kleopatra]

Hi Shane,

So Jeanette, is your criticism limited to the design of the newer impl?
I agree that it is poor choice for a tutorial, but if it is functionally
complete, I might be tempted to convert some code. (I can live with
losing selections since mine does the same

How would you handle SINGLE_INTERVAL_SELECTION?

good question. Don't know - but never needed this selection mode anyway,
afair. Just curious: in which situations might it be useful?

Or do you just mean
maintaining the current set of selected indices and 'reselecting' those?

not sure what you mean - but my users/clients want the selection glued
to the row "content", independ of where it is sorted currently. Let's
say they selected the first row, sorted by a column which moved the row
to the last position then the selection should jump to the last row as
well. Seems to be very wide-spread behaviour in applications handling
tabular data (in win at least).

Greetings
Jeanette

 

[Shane Petroff]

good question. Don't know - but never needed this selection mode anyway,
afair. Just curious: in which situations might it be useful?

I just did a search across my two most recent development machines, and
didn't find it used in any of my code.

However, it did make a convenient excuse for not dealing with the same
selection problem that the Sun example exhibits when I developed my
generic sort decorator a couple of years ago.