Philipp wrote:
Hello,
I just read
http://java.sun.com/products/jfc/tsc/articles/architecture/ which was
recommended in another thread and a question remains as how to
separate the GUI and data.
Suppose you have a boolean value in your application (for example,
"Check for new messages at startup", in an email app), you will need
this value for the app to work correctly. This value may be set by a
checkbox in some Preferences window, but is usually hidden from the
user.
Would you:
- Initialize the GUI without showing it, and get the state by
accessing the GUI component's value (eg. checkbox.isSelected())
- Use directly, or subclass, ButtonModel and use this ButtonModel to
hold this data everywhere in your code, passing it to the JCheckbox
upon construction of the GUI
- Implement your own update mechanism: i.e. storing the data in a
simple boolean somewhere and when the GUI is shown, create a checkbox
with the correct selection state. Update the boolean value only on
close of the Preferences window.
- Any other sensible way I did not think of?
I'd keep the "authoritative" boolean somewhere in the
main part of the app, possibly using a Preferences to preserve
the value from run to run. If the user opens the part of the
GUI that controls this boolean, I'd initialize a checkbox from
the current authoritative value and update that value if the
user changes the checkbox.
I'd try to avoid having the app query the checkbox state
directly, because this would tie the app to the specifics of
the GUI design. Rather, I'd use the GUI as a "knob" to show
and control the real value. This gives me the flexibility to
change the GUI, to implement a non-GUI command-line interface
for use in batch scripts, and so on.
Thanks for your answers. It makes sense to do it that way.
else in the code while the GUI is showing, the GUI will not be updated.