• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Hard code columns in JTable

 
Stephen Loh
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Zee Ho
Ranch Hand
Posts: 128
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yes, you can, since sun state all the necessary information for us and don't use the word "must not" to prevent us to do so. but I think you'd better address this choice in your choice.txt.

for me, I get all that info from database file itself.
 
Paul Bourdeaux
Ranch Hand
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Stephen Loh
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic