File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Hard code columns in JTable Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Hard code columns in JTable" Watch "Hard code columns in JTable" New topic
Author

Hard code columns in JTable

Stephen Loh
Greenhorn

Joined: Feb 06, 2005
Posts: 17
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

Joined: Jul 20, 2004
Posts: 128
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.


SCJP 1.4<br />SCWCD 1.3<br />SCJD<br />SCBCD<br />IBM Xml Cert in progress
Paul Bourdeaux
Ranch Hand

Joined: May 24, 2004
Posts: 783
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
Stephen Loh
Greenhorn

Joined: Feb 06, 2005
Posts: 17
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

Joined: Feb 01, 2005
Posts: 580
    
    5
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Hard code columns in JTable
 
Similar Threads
JTable
JTable
JTable
JTABLE
jtable