Hi Davidd,
I agree with Bob - you do have to decide for yourself how far you are willing to go on this project. Your instructions should tell you that you wont get extra marks for going beyond the specifications. Some (not all) of your questions do appear to be going beyond the specifications, but I am quite happy to discuss them, and I think you will find others here are also willing to do that. Kathy Sierra has noted that one of the biggest problems Sun encounters with this assignment is people going beyond what is required.
Would you like to suggest how to get not duplicate items from the db.db database by a simple method?
Adding the items to a Set will ensure you have only unique items. Adding them to a TreeSet will also sort them.
Should I add new feature in the Data class or pass all the record of the database as a string[][] to the GUI constructor?
Sounds like a design decision
There are good and bad points for each option. As long as you document why you chose to implement a certain why (hopefully stating why you decided
against the alternative(s) you shouldn't have any problems.
First, if I choose JComboBox, I must use it on every field and cannot use JTextField or JCheckBox
Only if you decide to allow searching on every field. From memory you are doing the Hotel assignment. They way I read this assignment, you only have to allow searching on name and location fields.
It is very difficult to choose the suitable component for the database schema by program, isn't it?
For
this particular database, yes. Most databases will provide better field types, and tell you what a specific field is supposed to contain.
If you did decide to to allow searching on every field, and you want to override the default string type of the field, then you will possibly need to code to
either specific column positions (problem if ever the order of fields changes)or code against the expected column name (for example, if column name = "size" then set type to int) - this at least will mean that if the column name changes, then the application may still work, although integers will no longer be treated as such
Furthermore, the JComboBox�s items list may become very long when database grow up.
Yes, this is a reason to be careful with JComboBoxes. But there will have to be some tradeoff between making the system idiot proof (with a JComboBox the user cannot enter bad data) and having too many items in your list. The JComboBox is fairly good about how it handles large numbers of items though - if there are too many items, it will display a scrollbar, you can set how many items can exist without a scrollbar, and the user can press a key to jump to the appropriate point in the list (so they can press "M" to jump to Metropolis).
Secondly, if I use the data of the database as items, we must search for the whole database before we create our GUI. It decreases the performance, increases the burden of the network, what to do when the amount of records become vast?
Well the user must be able to search for all records anyway, so you have to accept that this may happen regardless of how you feel about it.
This might be a reason for doing your search for unique values for your JComboBoxes on the server.
I am not sure how much we should worry about what happens when the amount of records becomes vast. By the time that happens, there are likely to be other issues as well. What the user then decides to do is unknown (upgrade to a commercial database / upgrade to a 1Gb network / change network protocols ....). I think (I can't be bothered counting) that there are around 132 bytes per record at the moment (complete record including spaces); which means about 1Kb of data per record. On a 100Mb network using sockets
you should be able to transfer almost 100,000 records per second. Of course we should probably take into account other network traffic and collisions etc., so I am going to reduce that to 50% or 50,000 records a second. If you do a bad RMI implementation, then we might only get 1/5 of that, or say 10,000 records per second. I think with these sorts of numbers, we are going to have to deal with other issues long before we start worrying about the amount of data we are transferring over the network.
Thirdly, if new records are added to db after creating of GUI, new items cannot be add.
I don't think it is a requirement that you handle this. I certainly didn't, and I got 100% for my GUI.
If you did want to handle this, you could set up an Observer-Observable link between the GUI and the Database, so that the Database will notify the client if the list of searchable items has changed. I think this is well outside of scope though.
I say �it may not be clear� because in the instructions �database schema�, there are �Field descriptive name� and �Database field name�, I think it may suggest we should use the field descriptive name in GUI.
That can be a valid design decision (and therefore something you should document
).
If you do this, you might still want to extract the Database field name so that your searches will work with the fieldname in the database - your decision.
But I am still puzzled at the instructions: �Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.�
Try and think about what might happen in the future. I don't think you can cater for all possible changes, but you might want to ensure that changes are not going to cause major rewrites or major changes to your interface.
So if UrlyBird want to add a second database, can they do that? Or have you written your server in such a way that they would have to duplicate all your code to get a second database?
If an extra field was added to the database, will your GUI display it?
If you decide to only allow searching on the two required fields, and the users want to add searching on another field, can this be added without creating a whole new screen?
These are just some examples - there are many more potential areas for change that you could think about.
Regards, Andrew
