Java: JTable auto-primary key update

Question

I have this JTable having an AbstractTableModel as its model. The initial contents are parsed to a two-dimensional array Object from a ArrayList generic to a Entity of the system. Also in the model, isCellEditable is overriden with respect to data integrity. After setting the model, I have set some cell editor with specified swing objects.

My problem now is that. How could I fill-up the column[0] of the table once changes on an empty row occurs. Also, once updates happens to the empty row, another empty row will automatically be added to the JTable.

Am I going to use a TableModelListener? How could I implement it without resetting the model of the JTable again.

Most likely this is similar to Microsoft Access - Form presentation to tables/queries.

Your response and comment will be highly appreciated.

Thanks, Cyril H

Answer 1

I have this JTable having an AbstractTableModel as its model.

THe AbstractTableModel is not the tables model. You are extending AbstractTableModel to implement the model storage and other methods that need to be implemented.

I would just use the DefaultTableModel. It already implements these methods and it provides an addRow(...) method that allows you to dynamically increase the number of rows in the model.

Am I going to use a TableModelListener?

That is one way. Every time the data in a cell changes you check the entire row to see if it is full. If it is the last row in the table, then you can just invoke the addRow(...) method on the DefaultTableModel to add another row.

Answer 2

Well, first, don't work on 2-dimensional Object arrays, but on a list of your POJO.

You can have a look at one of my simple sample code here: http://puces-samples.svn.sourceforge.net/viewvc/puces-samples/trunk/sessionstate-suite/sessionstate-sample/src/blogspot/puce/sessionstate/sample/ParticipantTableModel.java?revision=2&view=markup

Are you accessing a local DB? If yes, then you could use JPA entities directly in your table model.

If your accessing a shared DB, then you better of with a 3-tier architecture. You might want to use DTOs which don't expose the PK, in that case.