File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Do we have to hardcode the fields (order, index values) in the client 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 "Do we have to hardcode the fields (order, index values) in the client" Watch "Do we have to hardcode the fields (order, index values) in the client" New topic

Do we have to hardcode the fields (order, index values) in the client

Don Burke

Joined: Sep 20, 2005
Posts: 14

Probably the ugliest, least flexible part of my current design is the way i'm handling fields. At the moment, my code is assumming that the given order i.e. Hotel, City etc... will never change. In doing so my code in all layers depends on this order of fields.

If the order was scrambled my program would break..entirely!!! Is this OK? I'd like for the code to handle this but has anyone done this?

When reading the file i am filling a factory class that holds the schema information..such as field name, and size. Which i use to read the data from the file. apart from that, no schema of field names, order, sizes is passed to the client.

any help would be excellent


[ November 23, 2005: Message edited by: Don Burke ]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11778

Hi Don,

It is difficult to handle this with any guarantee of success, and I am not sure that it is even worth trying: if at some later stage the field order / sizes were changed then it is likely that other things might change as well (perhaps adding unique indexes, or adding other fields). It is rare that a database structure gets changed for something as trivial as just changing the order of fields around. With that basic premise - any change to the database structure is likely to require non trivial changes to your application anyway. Since you cannot possibly anticipate all the possible changes, any work you put into trying to cater for it might be wasted. (This is even an eXtreme Programming core value: simplicity)

Having just tried to convince you not to do it, how could you do it?

You could have some way for your program to access the schema - either adding a method to the Data class specifically to allow access, or using a magic number to retrieve the schema through the normal read() method (e.g. read record number -1 to retrieve the schema). Both options have their pros and cons. If you can retrieve the schema you can later verify that fields are in their right place and possibly handle any changes later. Personally I am not much in favour of this - in my opinion it offers too little for too much work.

A better option (IMHO) is to pack the data retrieved from each read() call into a Transfer Object (or Value Object to use it's older name). All your higher level functions will then access that Transfer Object, so they will not be aware if the field order has changed or if a field has been added. All you will need to do in such cases is change the code that populates the Transfer Object.

Regards, Andrew

The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Steven Schmidt

Joined: Nov 25, 2005
Posts: 1

Right now I am working on the URLYBird design. In my opinion it is easy to access the table structure dynamically without hardcoding the column names. When I read the schema section from the database file, I save the column name and width in an ArrayList. Therefore, I could easily iterate trough this ArrayList without knowing the column name and index position:
for (int i = 0; i < dbSchema.getNumberOfRecords(); i++){
while (dbSchema.hasNextCol()){
/* getNextCol() returns an object that contains
* the field name and length
The only drawback would be that the column/field type is unknown. Therefore, the data access class could return only strings. In my opinion this would fit with the DB interface (String Arrays as return values). However, transfer objects would be not needed at all in the DAL. What do you think Andrew � is such a generic DAL worth its effort?

Mo Negargar

Joined: Dec 13, 2002
Posts: 6

I have done my design exactly like this. There is a class that contains name of the field, size of the field and how much data the field can hold e.g 64bytes; and a collection of these value objects are passed to the client in an ArrayList. The user interface can then use this ArrayList to create column headers. However, now I am having second thoughts. Yes, you gain flexibility in that the actual database fields can change name and the client won't be affected. But there is a clash between having this flexibility and good interface design. For example, in interface design the upper left corner is very important and should contain important data. This means that that in case of URLYBird, the first column (upper left corner) should be name of the hotel. However, if in the database file, the first field is something unimportant like 'Smoking', you don't want to display this as the first column in your user interface.

So the question is: (and Andrews opinion would be appreciated here)
Shall the backend database be allowed to dictate the order of columns-headers in the user interface? The alternative is to hard-code column headers in user interface and sacrifice the flexibility that you gain by creating the column-headers using data retrieved from the backend database at startup.


Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11778

Hi Steven and Yacob,

Welcome to JavaRanch and this forum.

I mentioned earlier that it is possible to have your program access the schema, and try and work from there.

But even then, I would still have my program do some additional work - I would not use the column names / order directly from the schema.

Another of the potential disadvantages of using the column names from the database (in addition to Yacob's comment about order) is that they may not be the most descriptive of names. If somebody gave the Smoking column the internal name of "S" - would you really want that appearing in your GUI? (Or even worse, if some programmer gave it a rude title)

Even with the titles that appear in the database at the moment, you have in the B&S assignment the internal name of "size" with a descriptive title of "Number of staff in organization", or for URLyBird "size" = "Maximum occupancy of this room". Isn't it better to use this descriptive name (or have it as a tool tip text)?

Regards, Andrew
I agree. Here's the link:
subject: Do we have to hardcode the fields (order, index values) in the client
It's not a secret anymore!