This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Until very recently, I never considered making the server part of the assignment run a GUI. Reason being that I would expect (well in the real world) the server to be deployed on a server machine in a rack. Hence there is usually no windowing capabilities to display a GUI (or run the application at all).
Of course it's all about assumptions and stating that in your submission, but I am curious as to what everyone else ended up doing (or are planning to do).
I was just reading the thread about configuration settings and allowing the user to specify settings at runtime through a GUI. Makes obvious sense for the client app, but I wasn't so sure about the server part.
Hmmm ... actually now that I think about it, the part of the spec that says something to the effect of: "user must not need to edit configuration files directly" makes it clearer now.
That's what I use and it works well. If I can do so I display a Swing dialog and let the user enter details there, then press a button to start the server. If I can't display the dialog I just start the server with the last saved details or the defaults (if no config file exists).
I've of course recorded that well. The headless mode is purely an extra, it's not required.
Regards, Mihai [ May 31, 2006: Message edited by: Mihai Radulescu ]
Jeroen T Wenting
Joined: Apr 21, 2006
What you describe in your last message there is similar to what I do. try to read properties. if found, display those as defaults. if not found, display hardcoded defaults. when user selects to connect/start, try to do so and if successful, save the entered values.