This is not a correct approach. JTable is an interface control which will present data to the user. JTable uses a TableModel to hold data. What you have to do is to create a class which implements TableModel or extends AbstractTableModel and pass an instance of that class to the JTable instance by calling setModel.
Thanks for your answers. My approach was to have the searching criteria (for name, location, etc..) inside the table (so not as separate JTextFields) - I thought it was somehow a better approach (maybe because I considered it cooler ). Anyway, now I'm thinking that the purpose (of this assignment) is to use as much as possible Sun's JDK and to have as little as possible your(my) own custom implementation. So, extending JTable is not so attractive anymore... Conclusion should be: don't extend JTable (as also stated in other thread).
However, extending DefaultTableModel, the things become really easy, since all I want is to have only one extra feature: so that only one column should be editable and the rest not (BTW: I'm working on URLyBird). If would extend AbstractTableModel then, accroding to the its javadoc:
I also created my own implementation of AbstractTableModel and I think one of the reasons (maybe the main reason) to have that approach is type safety. In my own RoomTableModel I have one method which adds a room to the list of rooms (which will be shown in the table):
This is type-safe. You can add only RoomTO instances to this table model.
In my case when I want to use DefaultTableModel I have to convert my RoomTO into a Vector or an Object, with my own TableModel I don't have to do that.
As a final point I have to admit honestly that I didn't know of the existance of this DefaultTableModel So for me it was very obvious to go for the custom TableModel (a total of 150 lines, comments included), because for me that was the only option. But now (knowing the existance of DefaultTableModel) I'm still convinced I made the best choice.
DefaultTableModel uses a vector of vectors of objects to store data which will be presented in a JTable. So, your business model is transformed into a vector of vectors. You transform every piece of data from model into a vector and add that vector to the DefaultTableModel data structure.
AbstractTableModel let's you implement your own transformation and gives you the possibility to choose a different data structure if you need one. So, very easily you can implement a vector of vectors inside. But, the main purpose and functionality of AbstractTableModel is the fact that can be used as an adapter. You can use the Adapter pattern and adapt your business objects directly by implementation, without the need of another intermediate data structure (as is it the case with DefaultTableNodel, in which case the intermediate data structure is the vector of vectors).
Both ways are good depending on the way they are used.
If a have a CachedRowSet as a business object, is much better to use an extension to AbstractTableModel. You implement the required functions without the need to spend memory and processing on creating the vector of vectors. You can simply redirect the calls to the apropriate methods of CachedRowSet (you simply adapt the contract of CachedRowSet to the contract of TableModel).
Depending on your situation you use one or another.
In my ClientMainWindow class I actually created an private inner class (ContractorTable) extending JTable (so it's still a JTable), just to override the valueChanged() method. That way I'm able to check if the selected record has been booked and enable/disable the book and release buttons accordingly.
I guess that shouldn't be a problem....
(Oh yes, releasing a record is not a requirement )
SCJP 5; SCJD; SCWCD 5.
Joined: Feb 06, 2009
I think you're doing kind of the same thing as I did: overcomplicate your life. Since my original post, I modified the code and now I'm using a JTable with a custom TableModel. The statement says It must present search results in a JTable. and not an extended class of JTable (although the instaceof test will tell that it's still a JTable). The thing is that "must" and "JTable" are in the same sentence, so it seems to me that you don't have too much freedom on that. I really don't know how sensitive are the guys from Sun to this statement; that is you either MUST use a JTable or you can use a customized JTable. I decided not to risk
I don't think that's the best idea or approach. Because in my assignment there is something like "you have to use functionality of the Java core classes instead of an own implementation". So extending the JTable for displaying the matching records is using an own implementation instead of using functionality of the Java core classes (using DefaultTableModel, creating a custom AbstractTableModel or implementing TableModel interface).
But that is just my opinion. I guess you will lose some points in section "General Considerations", but I don't think you will fail automatically (because assignment also says "Your data access class must implement the following interface..." and you are also allowed to create your own interface, extending Sun's interface).