Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Need help for GUI design

 
Davidd Smith
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, everyone,
I put a input panel with a find button below JTable for user to type in find criteria. My input panel contains every field of the record so that user can find based on whatever combination of conditions. My question is: Should I get the fields from the Data class to build my JLabels and JTextFields and tableHeader or I only hard code it in the GUI or read GUI structure from a file? In the former case, I can only use the JTextField and can not provide JComboBox or JCheckBox which will make the GUI friendly and reduce input error, meanwhile, the JLabel and JtableHeader's content must be the fields' name which may be not clear. In the later two cases, if the schema of database is changed, we must re-write the GUI, so the mantainability is bad.
What is the better choice?
Davidd
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Davidd
In the former case, I can only use the JTextField and can not provide JComboBox or JCheckBox which will make the GUI friendly and reduce input error, meanwhile, the JLabel and JtableHeader's content must be the fields' name which may be not clear.

Going through these one by one:
  • I can only use the JTextField and can not provide JComboBox or JCheckBox
    Why is that? For my assignment I got the fieldnames and initial data from the database, and used them as the title and contents of my JComboBoxes respectively. What is it that is stopping you from doing this?

  • the JLabel and JtableHeader's content must be the fields' name which may be not clear.
    When you say it "may not be clear" do you mean it is not clear, or just that a future change "may not be clear? If it is only a potential future change that you are concerned about, then I would go ahead and use the field names provided, and document the potential future issue.
    Regards, Andrew
  •  
    Bob Reeves
    Ranch Hand
    Posts: 64
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Davidd:
    Perhaps the best approach is to ask yourself what your purpose is in completing the SCJD. If it's to pass the test and get certified: stop at what's specifically required. Do any more and you have schedule, design clutter, testing, documentation, and reliability impacts. If your purpose is to pass, I'd use the fields of the assignment as specified, and search only the fields required.
    If you're interested in building the world's greatest GUI: then you need to explore the rules that make a good GUI. There's a vast library on this topic, and it seems two different people have three different opinions.
    To GUI or not to GUI, that is the question ...
    Tx
     
    Davidd Smith
    Ranch Hand
    Posts: 62
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi, Andrew,
    Thank you very much for your reply.
    Just as you say, using JComboBox is a good idea. Would you like to suggest how to get not duplicate items from the db.db database by a simple method? Should I add new feature in the Data class or pass all the record of the database as a string[][] to the GUI constructor?
    But there are still problems using JcomboBox:
    First, if I choose JComboBox, I must use it on every field and cannot use JTextField or JCheckBox. It is very difficult to choose the suitable component for the database schema by program, isn�t it? But JComboBox is not fit everywhere and sometimes we do not want to use a field to search. Furthermore, the JComboBox�s items list may become very long when database grow up.
    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?
    Thirdly, if new records are added to db after creating of GUI, new items cannot be add.
    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.
    Am I go too far deviating from the test?
    David
     
    Davidd Smith
    Ranch Hand
    Posts: 62
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi, Bob,
    Thanks a lot. You give me a good suggestion. 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.�
    David
     
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander
    Pie
    Posts: 12014
    220
    C++ Firefox Browser IntelliJ IDE Java Mac Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
     
    Davidd Smith
    Ranch Hand
    Posts: 62
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi, Andrew,
    Thank you very much, your answers are very helpful for me.
    Recards, Davidd
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic