RE: [Rails-devel] OR updates

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

> My main point was that the process of changing the model, 
> then redrawing the affected UI components ought to be just 
> fine for the ORWindow.  If the game-specific logic is getting 
> in the way of the drawing code, that could be moved into a 
> separate controller class, so that the drawing code just 
> reflects decisions made in the controller class. 
> 
> Enabling and disabling panels and buttons automatically calls 
> the objects' repaint() method. I don't see why redrawing the 
> window is a thing to be avoided.

It could be a matter of taste, but I find redrawing not very pretty
for the eye. I fact, earlier this week I discovered, that the StartWindow
(and perhaps also the ORWindow) were completely recreated after each
action, because of a bug in StartWindow. 
I have fixed that and to me it looks a lot quieter now.
I admit that repaint() is probably not as bad as such a complete
replacement.
But I also think that in the StockChart it does not matter much 
because its squares have a fixed size, but that is not so in the other
windows.
 
> > But I wonder how this all would work out in a distributed 
> environment.
> > If the server would only send a message to all clients to 
> have them all 
> > completely rebuild themselves, that will cause a lot of 
> calls to the server!
> 
> > It seems to me that atomic update messages from server to client
> > would do a more efficient job.
> 
> See, now you're getting into a completely different issue.  
> In a client/server setting, I would expect that we want to 
> pass around only updated information about the model and then 
> have clients call their local repaint() to update the UI to 
> reflect the changes.

To me this is the same issue in a different setting.

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

And to enable use of repaint() in the Status, Start and OR windows
I'll have to do some changes anyway.

All variable screen elements in these windows are classes in the ui.elements
package, and each one could repaint() itself if it would know where to find
its value. Currently these elements have no reference to a model class, 
so the value to paint must be provided from the outside.

It seems to me that both in your approach and in mine each screen element
*needs* a reference to a model class, where it could retrieve its
value from: 
- in your approach to retrieve the value it should display on a repaint,
- in mine to retrieve a new value to display after a signal from the model
(to which it has registered as an Observer before).

So I think both approaches would benefit from a model/view connection on
a granular level, i.e. for each value to be displayed.

Seen this way, the Observer pattern would be just a slight extension
from a model/view connection that we have to create anyway!

My proposal is that I rework the three windows mentioned to use repaint(),
passing each field an additional reference to a model class embedding
the value to be displayed. So that would streamline things your way.
And I can throw away the laborious partial window update methods
that I have been creating up to now, and that I want to get rid of.

Once that is done, it would be a minor extension to add the Observer pattern
on top of that. If only as an experiment so see if it makes any difference.

How about that?

Erik.