JXTable - some grumbling...
it's exciting to see some real code and working examples with many new
features after a year of waiting.
Being a JTable freak the first place I went was the JXTable - very nice,
all those decorations :-) It looks like being the most mature of the
"collection views" (list, tree, combo), those will eventually be
Searchable as well?
I would like to comment on some design/implementation issues - though
I'm aware that the code is still raw, I view that more as a chance than
a obstacle. Basically they relate to TableColumnEx and its enhanced
1) getting some responsibility to provide reasonable widths
A quote from getPrefWidth(..): "// .. do we want to calculate every
time?" - my answer to this is a clear "no" and going further even a
One reason is that the "pref" is a "preference" controlled by context:
one is the preference as a component might return in prefSize, the other
is the preference a user does express by resizing the column. The
TableColumn cannot decide which is meant, currently it assumes to be the
first kind of pref which makes is not-resizable with a prototype and the
table in autoresizeoff mode.
Another aspect is that there's need for something much smarter which
includes min/max sizes and resizing behaviour of the columns as well -
some means to really "layout" the columns. All size requirements might
depend on the TableModel. Too much burden for a simple data-storing
class, I think. Any effort to make it "smarter" will introduce
additional coupling into realms it should not have any knowledge of.
Yet another reason is that binding any tableModel-related "layout-info"
into a TableColumn is possible only after the table is filled with some
data and is lost whenever the model changes. That's at least annoying
though not un-resolvable.
2) taking control about the renderers to use
Until now JTable has full control about choosing the renderers. The
implemented strategy is to ask the column first which gives clients an
emergency hook - in my experience setting a renderer on the tableColumn
is rare event (most unliked because they are lost on model changes) and
used as a last resort, f.i. if choosing the renderer by column class is
not fine-grained enough. So the main route of choosing is through the
JTable's mapping of default renderes to column class.
TableColumnEx snatches that control from JTable if labelProperties are
applied, it insists on returning a renderer of its _own_ choosing if
none is set in the column. Tssss ...
3) back-referencing into JTable makes me feel very uneasy.
It's a necessity if the TableColumn is burdened with its new tasks.
Nevertheless it "smells" strongly on a general level, introducing a very
strong coupling somewhere hidden in the bowels. As a consequence,
ColumnModels are no longer shareable across tables. Which is a
showstopper in certain contexts (a lot of mine at least).
A lot of nagging - I know, but have seen it all, have been exactly there
half a year ago :-) - IMO moving those enhanced responsibilities into
the TableColumn is a dead end. An alternative is to move it out into a
dedicated handler which can be easily configured by client code at any
time and is used by the table (or some adapter) when it comes to
actually configuring the renderers/columns. Currently I'm tweaking
JXTable to use my approach - and it looks promising :-)
Amy, if you are interested, please pass me a note: I can mail you a link
to a not (yet) published analysis/summary about the issues involved. I'm
_very_ interested in the JDNC Swing extensions, sounds like lots of fun