Re: Efficiency/Reliablility of Scaled Up JTable
On 5/1/2013 3:41 PM, clusardi2k@aol.com wrote:
On Monday, April 29, 2013 12:01:11 PM UTC-4, Eric Sosman wrote:
However, didn't the O.P. have a question a day or so ago about
a "horizontally scrolling" table, where new columns appeared at the right
while old ones vanished from the left (maybe with a few leftmost columns
inviolate)? If that's the table in question, I think he'd do better to use a
column-oriented model, where the vectors (not necessarily Vectors) run top-to-
bottom instead of left-to-right. A benefit would be that inserting, deleting,
and permuting columns could be done by I/D/P'ing the vector references
instead of mucking with the individual cell contents. It all depends on which
axis gets more activity.
Q1. Can anyone point me towards example code that uses a column-oriented model, that would help me think about developing a table like I want. How many different types of column-oriented models are there anyway.
*I* can't, but it seems straightforward enough. DefaultTableModel
uses a Vector for each table row (at least, that's what methods like
getDataVector() produce). When the model refers to the cell at row r,
column c, it uses something like
Vector<Vector<Object>> allRows = ...
...
Vector<Object> rthRow = allRows.get(r);
Object cell = rthRow.get(c);
With this arrangment it's easy to add a row, delete a row, or
rearrange the rows: You do everything to the allRows Vector, and
the individual row contents move around as units. But column
operations are harder: To delete a column, for example, you've
got to go through all the row Vectors deleting one cell from each.
If the column operations are what's important, you could turn
things around:
Vector<Vector<Object>> allCols= ...;
...
Vector<Object> cthCol = allCols.get(c); // note r/c reversal
Object cell = cthCol.get(r);
Now it's easy to manipulate the columns as units -- but it's
harder to fiddle with the rows. TANSTAAFL.
Alternatively, a HashMap<Pair<Integer,Integer>,Object> might serve as model
supporting both access directions equally well, and could handle row/column
rearrangements quickly by storing "virtual" coordinates translated through a > pair of arrays for the permutation of the moment.
Q2. Can anyone point me towards example code that uses a HashMap model (colors cells etc) for my table (containing textural data), and be able of helping me think about this efficiency problem some more.
As I mentioned elsethread, it's just an idea: I haven't actually
tried it, nor seen it used. My thought was that this could be a way
to handle both row and column operations with comparable ease.
(You keep mentioning cell colors, as if you somehow expect them
to affect the performance. I cannot imagine why you'd think they
would, so I suspect I'm failing to understand all of your problem.)
Q3. Not considering efficiency, would I gain or lose "anything" else if I switched from the regular JTable model to either a column-oriented or HashMap model. For example, would one of the alternatives require more code to do things.
Either alternative would probably require you to write more code
than if you just used DefaultTableModel.
At this point I think I should echo (or paraphrase) Daniel
Pitts: Is this work necessary? That is, do you have evidence that
a plain vanilla JTable with DefaultTableModel is inadequate? If
you don't, all this fretting may be doing nothing except raise your
blood pressure: Just write the plain-vanilla version, measure how
well or poorly it works, and *then* decide whether to do extra work.
--
Eric Sosman
esosman@comcast-dot-net.invalid