This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Please guys, pardon me if this question is silly. For the client-side application, must the JTable be able to cater for possible future database fields changes? In other words, am I allowed to hard code the column names, as well as the number of columns in the table model?
You can... but it really isn't good design. It is fairly easy to pull this information from the schema section of the datafile, so I would recommend using it.
While it definately wouldn't result in an automatic failure, I wouldn't be surprised if you lose a point or two. [ April 22, 2005: Message edited by: Paul Bourdeaux ]
“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook
Joined: Feb 06, 2005
Thanks for the replies. Yes, it is true that not hard coding the schema is a better approach. I absolutely agree that taking the schema from the server is a better design. But if I do not hard code them, then I have some doubts.
Basically I got the Bodgitt & Scarper assignment. Like the other assignments, this is also some sort of a booking system. The booking depends on a certain field in the database called "owner", which is an 8 digit number representing the customer id. If I do not hard code the schema, isn't it true that I will have to assume that there will be a field called "owner"? If not, I can't think of any way to stop the user from overwriting an existing booking. I was thinking of stopping the user from booking before the RMI transaction takes place. Of course, if I can assume that a column named "owner" will definitely exist, then good. All I need to do is search the table model to find out the column index of "owner" and continue from there. If I can't, then it seems impossible to implement.
Also, I am required to implement searching by name, location or both. Now isn't it true that I will have to assume that 2 columns named "name" and "location" will definitely exist? The position, again, doesn't matter. I can simply search the table model for the index.
So what I am trying to say is, it is definitely possible not to hard code the column names. But, due to certain requirements, I need to assume that some columns exist.
I got a feeling that I am missing something major. Am I? Thanks for any advices. [ April 22, 2005: Message edited by: Stephen Loh ]
I also disagree with the statement that you might lose a point or two. I don't think it is a reasonable expectation to need to "guess" what the booking field is or make all field names in the client code dynamic. This will make the code unduly complicated, especially if you are adding capabilities for record addition or modification.
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1