Understanding JTable
I am struggling with my first exposure to JTable, by trying to modify some third party code.
I have a table, and need to be able to add/remove columns from the display at will. The basic procedure that I do is this
1) Set up the table model for ALL columns. The model has a Vector for the column names (there is good reason for this).
2) To add/remove a column, I remove all the columns from the JTableColumnModel, and add in the ones I want. (I need to keep them in a known order).
3) Modify the list of column names in the table to match the new columns
4) call the setModel() method on JTable to re-assert the table model
Is this basically the right approach, or am I over complicating it?
I'm happy to hack at the code, which i am starting to understand, it's the methodology I am unsure of.
Thanks in anticipation
[875 byte] By [
Stevefkia] at [2007-11-27 10:49:02]
# 1
Dont worry too much. Working with JTable in right way is a bit complicated at first but after some work you will idea about swing and how to use event firing effectively.
I think your approach is a bit complex and a bit performance costly (esp. removing all columns and adding them again).
Let's make it nice and easy way (a little long though). First you have to use model and view methodology. JTable is view of your table like data structure. When you say you add/remove columns, I am guess just from view point of view you are hiding/showing columns. Rather you are hiding/showing data.
So in short answer, all you need to do to write TableModel to reflect your will and just fire some event so that Table will update the view based upon what you want to achieve. This way here all you need to do is to repaint/revalidate the JTable and you are all set.
What do you think about this approach? It is costlier in terms of code point of view. So if you want something quick and easy, your approach will give you fast results. However if you want to do things in correct manner and want expandability in code/architecture, you have to do a little planning and working in early stages.
Let me know your thoughts.
Regards,
D
# 2
Thanks for your answer. I was tending to think that what I was doing was a bit more involved than necessary, and I am struggling a bit here.
So to adopt your suggested approach, what do I need to do to the TableModel? Or do I need to do something with the JTable? It's the view that I need to change, i.e. the table is fully populated, then I just see the columns that I want to see.
Many thanks
# 3
Not a problem. Glad that you like my suggestion.
Currently I am at work so I can not give you more details about code. I might have code/example written at home. So you might have to wait for 7-8 hours (long day today :( )
In the mean time, take a look at following links:
http://www.codeguru.com/java/articles/660.shtml
http://www.stephenkelvin.de/XTableColumnModel/
It will give you a little idea about our approach to change view only. I will follow up in evening.
Regards,
D
# 4
The basic approach is to play with the TableColumnManager. There is no need to touch the TableModel.
My code in this posting may give you some ideas:
http://forum.java.sun.com/thread.jspa?forumID=57&threadID=743041
# 5
I have implemented the suggestion in http://www.codeguru.com/java/articles/660.shtml, which does seem to help a bit. However, I am using a cell renederer, as each cell of my table holds 4 bits of data, which in turn is held in a holding class.
The suggestion in the above example is to use fireTableStructureChanged(), which I believe from earlier questions and answers forces the TableModel to be rebuilt from scratch, and will destroy the configured CellRenderer, i.e. I lose the reference. This seems to be the case, because my cells just render using the toString() method from the cell data class.
I think then I need to rebuild the CellRenderer every time the table is changed. This leaves me with a chicken and egg thought, if I rebuild the renderer after the fireTableStructureChanged() call, that will be too late, and if I do it before, that is too sonn, because it will be lost.
Any suggestions, or am I way off?
# 6
> The suggestion in the above example is to use fireTableStructureChanged(),
No it doesn't. In fact it explicitly says not to use it.
# 7
Sorry camickr, I was referring to the example before yours. Your example of course says you don't need to use it. I shall investigate your method.
Thanks
# 8
> Any suggestions, or am I way off?
> I shall investigate your method
Then why did you ask for new suggestions when you haven't even looked at the solution I suggested 4 hours ago? Its frustrating when we take the time to help and you don't even look at the suggestion before asking for more help.
# 9
Because I was till working on the suggestion before, and asking for a suggestion as to how I could overcome the fireTableStructureChanged() problem. It appears there is no ready solution, so I have now moved on to yours.
# 10
A question then camickr on your solution. Before I commit some time to re-work my code again, can I clarify what I need to do.
I have a custom table model. If I create this as a 'full table' I should be able to leave this alone, this is then the Model in MVC terms.
Then, as per your example I manipulate the View by tweaking JTable, or more precisely the TableColumnModel, as in your example. i.e. I should be able to just add/remove columns as required. Since I need to keep the columns in order, I should be able to do this by removing them all, then re-adding them as required. Yes?
The re-painting of the table happens automatically I assume (?)
Thanks
# 11
> I should be able to just add/remove columns as required.
Yes.
> Since I need to keep the columns in order, I should be able to do this
> by removing them all, then re-adding them as required. Yes?
Yes, it should work.
