Fred Schauer wrote:Thank for any help/suggestions you can give.
Not being a GUI expert, I doubt I can better Ulf's suggestion, but here's my tip:
Keep the GUI and your application logic
completely separate. A
Member, for example, is likely to be a
data (or 'business') object, not a
display item, so I wouldn't expect it to contain ANY code for displaying; apart from possibly a
toString() method for debugging purposes.
That doesn't mean that you can't pass one to a class that
does know how to display it (or part of it) properly, but don't mix the two together.
A nice side-effect of this is that you can write
and test your application classes and logic (possibly including database access) without even worrying about the display - apart from making sure that it's readable on a console. This allows you to focus on
one thing at a time.
Displays are notoriously fiddly and verbose beasts, and, while I understand that Java FX has greatly reduced the amount of faffing about you have to do, it's natural that when you're writing screens, you'll be concerned with things like format and placement and "feel", which have nothing whatsoever to do with what a
Member does.
You may be interested in reading up about the
MVC pattern, which goes into a bit more detail about this.
HIH
Winston
1
