From: Erik V. <eri...@hc...> - 2005-12-09 23:44:29
|
> >> However, I really hope you're not proposing to start > >> refactoring our code into client and server before the game > >> code is complete. > > >Hmm, to me this is exactly what we have been preparing ourselves > >for from the start by applying a strict model/view separation! > > Agreed, but I'm hoping you'll wait to start writing > networking code until after we've gotten the hotseat game working. ;-) Sure, but it will pay off to be prepared! <snip> > Sounds good. Once you start working with using repaint() I > think you'll find that adding on Observers will be > unnecessary because the painting system already provides the > notification to each object that uses the common painting methods. The prime purpose of the Observable would not be send a signal to redraw (that is a UI concern) but to send a signal that the Observable's value has changed (that is a model concern). Whether the UI field then immediately repaints itself, or waits for a repaint of its container, is a secondary matter. In fact I think the latter is better. > In other words, when we set a HexMap as visible, HexMap's > paint() method is invoked. Because HexMap is a JFrame, it > also invokes the paint() method of every Swing object beneath > itself. So, HexMap will call the paint() method of the > JScrollPane we use, and in turn, the JScrollPane will call > the paint() method of the JPanel contained within its > Viewport, which in turn calls the paint() methods of each > GUIHex in the panel. > > So, as you can see, the fundamental question that you're > trying to answer for ORWindow, "When do I draw things?" is > answered with, "Whenever someone calls your paint() method." No, the fundamental question actually was: *what* to draw when it is time for drawing. How to tell a field in these windows that its *value* has changed. OK, needed for any good solution (mine or yours) is that we give each UI field a reference to a model that holds the value to be displayed. We seem to agree on that, and that is the first thing I'm going to add now. Once that is done I think we'll be a lot more flexible. Where we still differ is on the question as to whether a UI field on a repaint() should *always* call its model for the current value (your way), or would have that value already received before through observance of its model (my way). But that is not a big difference anymore, the details will be hidden in a few specialized classes. Good discussion this was! At least it has sharpened *my* thoughts a lot. Erik. |