Chapter 15. The JTable Component

Terms you'll need to understand:

• JTable

• Rendering

• Table model

• Observable event model

• Tool tips

Techniques you'll need to master:

• Setting tool tips on cells in a JTable component

• Enabling row, column, or cell selections in a JTable component

• Listening for changes to the rows and columns of a JTable component

• Designing your own table data model

• Reading a data file into a JTable

In this chapter, you review the basics of the JTable Swing component. You'll find lots of examples here, so you will probably be able to adapt some of the code in this chapter for your certification assignment.

A key requirement for the assignment is designing the table into the project so that the user can find a particular row of data, select the row, and change the data in the database based on the selection. There are many ways to approach this task. You can allow the user to actually change the values in the table itself. In that case, you listen for user actions, such as ListSelectionModel.addListSelectionListener() , to monitor a whole row, or JTable.addMouseListener(new MouseAdapter()) , to listen for mouse clicks on a cell. Note that the ListSelectionModel to which you add the listener needs to be the one that has been set as the selection model for the JTable via setSelectionModel() .

One of the problems you must solve is user error. What happens if users try to reserve too many seats, for example? How does your program deal with the situation when a plane or train has no seats available, but the user still requests seats? Whatever the approach, you must at least have a way to give messages to your users. You should tell them when the reservation is successful, but more important for the assignment requirements, you should also inform them of errors and what the application did about them.

In my project submission, I reduced the possibility of errors by designing the GUI so that users selected the item of interest by clicking on the table. This click then populated related Swing components . User actions all involved clicking except for one text box, in which they typed the number of seats. This design seemed simpler for the user and restricted the chance of user error to one field. The input from that field was carefully scrubbed so that it wasn't possible for the system to choke on, say, a request for too many seats. If anything wasn't right, such as too many seats requested , no seats available, or non-numeric input, a message about the error was displayed to the user, who was then allowed to try again. My approach was to completely eliminate exceptions caused by user input. You might allow the user to change data in the JTable itself. That approach is no better or worse than what I did. Just make sure the user input error trapping handles all problems.

There were many JavaRanch forum posts from candidates who used logging to keep a running record of user and system activities. I recommend not doing this, however. Logging is not part of the requirements, so don't introduce an element that can't earn you more points, but could make you lose points if you introduce an error in the logging code. The idea is great, of course. However, evaluators want to know whether you can follow instructions, so they will wonder why you have logging code when that feature isn't required. Some forum posters suggested they added logging for debugging purposes, but took it out before submitting their projects. Again, I strongly recommend skipping extra work that could introduce errors. The certification application is not a large one, so the negative cost of adding logging cancels out any benefits of logging functionality. Stay focused and don't add extra elements; concentrate on only what is required.

Reconsider adding logging to your application. It is not required, but if you add it, you might fail because of an error in the logging code.