Re: [Rails-devel] Screen messages

[brett l. <wak...@gm...>]

> > > 4. The tile and token laying steps are now explicitly
> > defined (in HexMap),
> > > and the messages are directly related to these steps. The
> > code is somewhat
> > > reorganised around these steps.
> > >
> >
> > I saw this...  I'm not sure I completely agree with the
> > implementation details.
> >
> > I think it may be time to move toward using AbstractActions rather
> > than static integers to interact with the state of the model.
>
> Huh? The integers *are* (better: represent) the state
> (not of the model but of the UI, see below).
> Actions are fine and we already have some. I'm not sure how more
> actions would help us, but I'm open to suggestions.
>


I think maybe I'm talking about one thing and meaning another. I
tossed off that reply rather quickly from work yesterday, so it
probably didn't get as much thought as I should have put into it.

I realize that we need to track the state of the UI somehow.  I'm more
looking at the organization of the ORWindow.

Right now things are a bit of a mess between HexMap, UpgradePanel, and
ORWindow.  We have HexMap manipulating things in the UpgradePanel, and
UpgradePanel calling a processDone method in HexMap.

It's all a bit too... incestuous.

I think that HexMap shouldn't need to know about UpgradePanel, and
UpgradePanel shouldn't need to know about HexMap. The ORWindow should
be taking care of governing that when actions are taken, the proper
information is propagated downward to each Panel that needs affecting.

---Brett.