Advanced GUI design

[Burk Hufnagel]

I've been considering implementing some GUI "extras" and I'd like some feedback -- especially from people who have already passed (surprise, surprise).
1) Record the order and size of the JTable columns and restore them when the application is re-started
2) Allow a menu selection for "Advanced Search Criteria which expands the JPanel containing the starndard search criteria (Departing city, Arriving city) with Airline and # of seats. This setting would be remembered as well and used as the default on start up.
3) Sstoring the location of the local db.db file and remote db server in a properties file and giving the user a nice dialog box to change those values - in addition to the required command line interface
4) Allow the user to switch between local and remote database connections without re-starting the application. Remembering which was used last and using it as the dafault (with command line override, of course).
5) A splash page detailing the application version number, whether the connection is local or remote, and the location of the database in use -- either a directory, or the URL of the remote server. This panel is also displayed as part of the About dialog box.
6) A status bar indicating whether the current connection is remote ot local.
I get the feeling that most people don't implement these things, but maybe that's why they lose points on the GUI part of the project.
I've been a pro programmer for many years and for a professional project, this kind of stuff is pretty standard.
Thanks for your comments,
Burk

[Michael Morris]

Hi Burk,
I don't want to throw cold water on your idea here, but it seems to me that you may be going overboard on the GUI. The total points for the GUI is only 24 (possibly a little more from general considerations) and you could lose points under clarity and maintainablity. Remeber, one of the requirements is that junior level programmers be able to understand and maintain your code. Complexity of the GUI could also interfere with scalabilty.
But this is just my opinion and if you want to do it that way go for it.
Michael Morris
SCJP

[Mark Spritzler]

Burk, I had absolutely none of that in my submission and I got 24/24 on GUI. I went real simple.
Three comboboxes for criteria selecting. 1 JTable for displaying search results. 1 JTextField to enter number of seats, and 1 JButton for booking.
I do listen to the Table changes and enable the JTextField based on available seats. The JTextField only allowed positive numbers to be entered. And when legal # of seats where entered, it would enable the Book button.
When the user clicked book, a dialog would pop up saying successful and shows the flight info, or just a Failure message.
The only argument at the command line I had was URL address of Remote Server. If no Arg passed then it was local mode. In all cases the db.db file resided in the jar directory, and therefore no user input on location of the db.db file was needed.
Mark

[Michael Morris]

Mark,
How did you handle security (policy file)? I'm glad I read this, because keeping everything in a jar sure makes it easy. What system did you work on? I've been testing some RMI on Win 2K and Win 98 and have to do different things to get each to grant access. Win2K requires a policy to at least grant socket access for the server, Win98 doesn't. Both require a policy file for the client to run. I plan to run cross platform tests on the final product between Windows and Linux.
Being an old timer, my first instinct was to go with serialized objects over sockets (got plenty of experience with old Unix sockets) but that is a self-limiting approach and knowing about RMI would make it difficult to defend. Anyway, any advice you can give to this "old dog" would be appreciated.
Michael Morris

[Mark Spritzler]

First, my db.db was not in a jar file, but just in the same directory as the 2 jar files.
As far as securityManager and policy file. I only use it on the client. and the Policy file has only one entry, and that is for AllPermissions, as in:

 grant {
 permission java.security.AllPermission "", "";
}; 

Mark

[Sarada Bhasker]

Three comboboxes for criteria selecting. 1 JTable for displaying search results. 1 JTextField to enter number of seats, and 1 JButton for booking.

Three Combo Boxes for what?

[Mark Spritzler]

Three Combo Boxes for what?

Carrier, Origin Airport, and Arrival Airport. This was for the search. User could select values from the drop down. The first value in each of the dropdowns where "Any"
If any was chosen, I did not include that field in the criteriaFind String.
Mark

[Adam Roberts]

Carrier, Origin Airport, and Arrival Airport. This was for the search. User could select values from the drop down. The first value in each of the dropdowns where "Any"

Was this a design decision as to not include searching for the other fields (ie Flight Number ,etc.) ? Obviously exact search for the price would be pointless, but there are a few others that might be useful. Not knocking your choice, just curious about your decision

[Burk Hufnagel]

You guys are right, and I knew that it's was more than the requirements - mostly I just think it's the kind of UI a real-world app would need.
As part of the "Advanced Search Criteria" I was including Carrier and # of seats - seems to me that many people have an airline preference, and even if they don't they at least know how many seats they'll need.
Maybe I should just make them standard and default to "ANY" and "1".
Does that make sense to anyone else?

[Mark Spritzler]

but there are a few others that might be useful.

Yes there are but I only put in those that were in the specs. Arrival and Origin because it specifically said those, and carrier because in the criteriaFind string they gave as an example it had carrier in it. Lik I said before I guess it was enough to get 24/24 points in GUI.
Mark