• Post Reply Bookmark Topic Watch Topic
  • New Topic

JTable, Table Models, Vectors & Objects : Confused  RSS feed

 
Darren Wilkinson
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

Can someone help me get a clear understanding of JTables.

I have a TestRecord class which creates TestRecords


I have an application which displays the table and creates some TestRecords


I have a table model...


The table model is a mess because I began with the record data being stored as a vector but (and here is where I am confused) this seemed to make the actual record object itself redundant.

I admit to being a java beginner however I thought that one of the key activities was to abstract things (in this case a record) into classes and objects (in this case a TestRecord class that creates TestRecord objects).

It makes sense to me to store these TestRecord objects into a vector as they are created, but I dont understand how to get the Table Model to use this vector of stored TestRecord objects. I understand how to get and set the fields within each TestRecord object (as the above code shows) and I can see a possible link between the objects data and its display in the table...

Table rows link to objects in vector
Table columns link to fields in object

... but I have no idea how to...

A) make the Table Model handle the display of the object data in this way
B) whether I am wasting my time as Table Models (and JTables) simply do not work this way

I think there is something about JTables, Table Models and (in this case) the TestRecord objects they display, that I have not grasped and if someone could help clear this up for me then I would be really grateful.

Thank you.

Darren
 
Terence Doyle
Ranch Hand
Posts: 328
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI

Look at all the constructors of JTable in the API. You'll see there's one that takes a Vector of Vectors as data - which it automatically puts into the data model and another as columnn headers.

You only need to handle your own Table model if you plan to update and transform data to presentable results in realtime over an existing JTable - which is in fact easy by subclassing DefaultTable model etc. Try just using the default table model and updating the data as needed with "yourTable".getModel().setValueAt()....

Hope this helps,
[ September 06, 2004: Message edited by: Terence Doyle ]
 
Darren Wilkinson
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for the reply Terry

I'm not sure it answers my question though as I know that my TestRecord class could have its data stored in a vector (field) as opposed to being stored in seperate fields and then this vector could be passed and stored in the Table Models vector 'rows' - I have already done this and had it working.

The thing is, this approach appears to me to go against the rule of designing classes and the objects they produce with seperate fields that hold the data of the object.

I have been taught to design the classes as follows (simplified)

// constants

// instance variables

// static variables

// constructor - accepting field values

// getters and setters

// utility methods

not...

// vector

// constructor - accepting 'field' values

// vector methods : add, remove, etc

The vector approach seems to make the TestRecord object only really work for the JTable and TableModel, whereas I thought the point of designing classes was that they can be used (accessed, updated, etc) by other objects using the getters and setters.

How does the current design and functionality of my TestRecord class/object fit into the vector of vector requirements of the JTable constructor?

Thank you.

Darren
 
Eddie Vanda
Ranch Hand
Posts: 283
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Darren,


Not sure if this helps, but if you were to extend AbstractTableModel you would be totally responsible for the way your data is stored and you could make a structure around your existing data to interface with your table via your tablemodel.

Ed
 
Darren Wilkinson
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Eddie

I will try this and see how I get on

Darren
 
Darren Wilkinson
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello :-)

I have been busy working on this and I think I am making progress. I just wanted to make sure I am heading in the right direction, so if anyone could spare the time to look through this code and comment upon it, I would be grateful.

The MyTableModel class isn't perfect and neither is the behaviour of the JTable, but after checking that I am heading in the right direction, I will start to sort out those problems.

Code below:




[ September 11, 2004: Message edited by: Darren Wilkinson ]
 
Eddie Vanda
Ranch Hand
Posts: 283
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Darren,

My previous response was a little rushed. I should have realized that you were already extending AbstracTableModel.

One of the objects of object oriented programming is to group things in such a way to improve code maintainability and reliability. The model/view/controller construct is reduced to model/view in this case and it separates the data model from the display model. Each can be modified without unduly affecting the other. You have added another wriggle to this by introducing a very tight link between AbstractTableModel and your data record. The table model should "know" as little as possible about your data structure and all cells should be Object types. So your test record should provide your table model with objects. The table model should get the type of each cell from the data it contains.

Just a little comment on your record generator, when stepping through loop values we usually test whether a value is less than the final value, not whether it's equal (or not). If by mistake you have put in a second or even third incrementor on the loop control variable, you could sail right past the terminal value and wonder where your program "froze".
So I would replace
while (x != 10)
with
while (x < 10)


Anyway, I think you're on the right track. Feel free to disagree with me. The test I would apply is whether you can change something in your test record without needing to change the table model.


Ed
[ September 11, 2004: Message edited by: Eddie Vanda ]
 
Darren Wilkinson
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ed :-)

re: your comments about the tight link between the TestRecord and the MyTableModel were very enlightening. I was starting to suspect I was doing something wrong whilst I was working but decided to ignore it for now and come back to it when I had something that worked. Your explanation of the need to avoid such tight 'linking' has both confirmed my suspicions and gently nudged me in the right direction for the solution.

I will post my re-design later for you (and any others) to comment on.

Thanks for taking the time to look through my work. It has been a bit of a struggle for me but it is very rewarding to hear from more experienced programmers that I am on the right path.

 
Darren Wilkinson
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello

Am I going in the right direction with this?

I think the TableModel is now less tightly linked to the data structure of the data in the TestRecord's.


My next step (assuming the above is right) is to try to make the TestRecord methods setRecordData() and getRecordData() less hard coded by somehow using the class type of the data in a given column determine which TestRecord field to update... but I am not sure if this is the right approach to take.

Any comments are appreciated.

Darren
 
Darren Wilkinson
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
bump
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!