aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes It must present search results in a JTable. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "It must present search results in a JTable." Watch "It must present search results in a JTable." New topic
Author

It must present search results in a JTable.

Stefan Taranu
Greenhorn

Joined: Feb 06, 2009
Posts: 22
Hi guys,

It must present search results in a JTable.
This is one of the requirements in the assignment. In my approach I extended JTable to build my custom table (so to say). It still conforms with the requirement or I will flawlessly fail ?

Regards,
Stefan


Stefan
Aurelian Tutuianu
Ranch Hand

Joined: May 13, 2004
Posts: 86
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.


http://javasign.blogspot.com/
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2615
    
    9

I agree with Aurelian on this one. The default JTable uses a DefaultTableModel. If you extend JTable what would you really changing? The goal is to change the underlying model (DefaultTableModel). Now if you going to extend DefaultTableModel, how flexible is your code? So using your own table model extending AbstractTableModel is the way to go.


K. Tsang JavaRanch SCJP5 SCJD/OCM-JD OCPJP7 OCPWCD5 OCPBCD5
Stefan Taranu
Greenhorn

Joined: Feb 06, 2009
Posts: 22
Hi,


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:
To create a concrete TableModel as a subclass of AbstractTableModel you need only provide implementations for the following three methods:

public int getRowCount();
public int getColumnCount();
public Object getValueAt(int row, int column);
which in my opinion is a little too much overhead, since in the DefaultTableModel I already have these methods implemented.

One additional thing is that, if one wants to populate the JTable, then it needs somehow an insertRow (which is already in the DefaultTableModel) - yes, of course one can do this by extending AbstractTableModel, but why bother when one has all needed in the DefaultTableModel.

Anyway, what I don't understand so good, is why is better to implement TableModel or extend AbstractTableModel? Where could I be flexible?


Regards,
Stefan
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5597
    
  15

Hi Stefan,

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.

If you use a DefaultTableModel, you will have methods like

which are not type-safe at all.

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.

Kind regards,
Roel


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Aurelian Tutuianu
Ranch Hand

Joined: May 13, 2004
Posts: 86
DefaultTableModel and AbstractTableModel are two very different things and therefore, their usages are different too. First of all, DefaultTableModel is an extension of AbstractTableModel.

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.

One example:
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).

Conclusion:
Depending on your situation you use one or another.
Gert-Jan den Besten
Ranch Hand

Joined: May 02, 2008
Posts: 56

My B&S 2.3.3 has the same requirement.

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.
Stefan Taranu
Greenhorn

Joined: Feb 06, 2009
Posts: 22
Hi Gert-Jan,

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

This is only my interpretation.

Regards,
Stefan
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5597
    
  15

Hallo Gert-Jan (Hi Gert-Jan),

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).

Kind regards,
Roel
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: It must present search results in a JTable.