B&S Initial thoughts about the DB and GUI

[Nikolay Gannev]

Hello ranchers,

Actually this is my first post...I started recently researching the SCJD (to be honest do not have too much time to work on it)))...
My questions relate to DB, GUI design...I started with parsing the db file. Thinking about how to design the DB and GUI have the following concerns:
The assignment says that the interface should be designed with the future functionality enhancements...Does this mean changing the information contained in the schema description section? - field name or field length or adding new field and so on...On the other hand the assignment describes Database schema with fixed values for field name and length. By my understanding there is a duplicate information - once this is described here and also this information is contained in the file. Describing all that I have doubts on if I can assume that this is the meta data or this could be changed in the future. And if I want to design my value object say Contractor and want to create constants for its fields - is this a good idea or I should parse the information and dynamically set those values..? Also how about designing a framework to abstract the meta data or this just add another layer of complexity....
I am sorry for my long post..I tried to be as detailed as I could...
Any ideas on this issue is greatly appreciated..
Thanks

[chris bajada]

Hi Nikolay,

As regards the 'future functionality' enhancements, i think they are referring to extra buttons on the GUI, as your data.java will support record creation and record deletion- however only BOOK is required for the user interface. This is a bit of contradiction really- as in the application overview section - the project specs say that

the it director does not anticipate much reuse of the first Java techology system

Well to be honest i did use the header information to obtain the field names and sizes for my columns. However then i hardcoded the UI in terms of column names etc.

I think that you can actually hard code the values, that's why they were given to us anyway :roll: ... if they expected us to parse the info from the file, they would tell us that the dbfile has the schema information and that our program has to extract that info from the dbfile.

One advice, is to document all your stuff in the choices.txt and do the javadoc from the beginning! I have NO documentation, just some rough sketches, and its going to be hell to document everything.

cheers,

chris

[Nikolay Gannev]

Hi Chris,

Thanks for your reply.
I think you are right that for future enhancements they refer to changing the UI functionality. I also found that issue - in my DB interface provided by SUN there are create and delete methods and in the same time this functionality is not required in the client?!?! I leave this issue for now because I have not thought on this.. :roll:
Let's go back to my previous concern of parsing the db file:

Well to be honest i did use the header information to obtain the field names and sizes for my columns. However then i hardcoded the UI in terms of column names etc.

Now what if someone changes column name?? you need to change your code ah?
So you are getting part of the information dynamically and other part static hardcoded! Do you think it is a good idea?
Some people say hardcode is not good - I could not agree with that statement in a way that if a constant is designed to be a constant it must me hardcoded. If this value may be changed in the future it is not a constant and I agree hardcoded is not good)). Having said all that I'm thinking on 2 approaches here:
1. SUN never say explicitly that the format of the file would be changed! Considering the data provided like
Subcontractor ---- name ---- 32 I can hardcode those values and my code will be simple and will work. Now if something changes field length or new field added - code will break ))).
On the other hand:
2. I can parse the db file during the initialization and put the data in HashMap or whatever.. and use this values later to set in JTable. This approach I agree is more flexible but add another layer of complexity...

Did SUN intentionally make this vague enough or they would like either approach if this is documented detailed in the doc...?
It took me a couple of hours to create a small program to parse the file. Now it will take me days to research what approach to take...
Please guys tell me if I am on the right road or not? and what approaches you made regarding this?

Regards,
Nick

[chris bajada]

Nicolay, I understand perfectly your concern.

I chose to give some meanings to my classes. For example, if you choose to adopt an all flexible approach, your Subcontractors (if you're doing B&S) cannot have a .setName(), .setLocation() or a .getName() method, simply because you're not sure which column is the 'name'.

In the GUI, how can you search by name, or location if you are not sure which columns are the name and location ?

Check the following thread which i had started, it should help you- i was in your same exact position when I started it.


Best of luck

Chris

[Nikolay Gannev]

Chris,

That's a good thread!
Well the more I go in the details the more I realize that I can not do 100% dynamic approach. At least from the perspective of adding new field - SUN specifies the type of all 6 fields that I have in my assignment. The schema section does not contain information about the type so I will not have this information and do not know how to render, validate, write to db and so on...On the other hand removing a column like name or location that involve searching will break my code unless I check if I have this or that column...All those changes would make the implementation more complicated and think this is an overkill.
Changes to the schema section like column name or size is the only reason why we can parse the schema section and get all this information dynamically. Otherwise based on the specification I could hardcode everything - even the column names and sizes...
So my assumption is that I accept by the specification that I have these 6 columns and do not expect more to be added or removed, only get dynamically those values - size and column names.
This is the simplest way based on my current understanding...

What do you guys think of all that?

Nick

[Anton Golovin]

Nikolai, the best advice i can give you is to use software patterns. Instead of just creating a database schema class, create it and create a factory that will serve it on demand, for instance. As for threading, I would use a queue with objects in it and threads waiting on those objects...