RE: [Rails-devel] OR updates

[Erik V. <eri...@hc...>]

> >> 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.