Re: [Rails-devel] Some (multi-)undo related bugs

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

Stefan -

I see what you're driving at, and it sounds a lot like MVC to me. ;-)

So... I feel I should caveat this with the usual disclaimer:  the guy
writing the code, ultimately, will get to make most of these
decisions. As I haven't had time to directly touch the code, I feel
that yours and Erik's opinions should weigh a bit more than mine at
this point. :-)

That said... I think your view and mine align pretty closely. Most of
my suggestion really comes down to clarifying the distinction between
model and controller, and reflecting that distinction in the code's
organization. To be honest, I've spent the last week at $dayjob coding
a TurboGears app, which is heavily MVC structured, so this is probably
influencing my perspective.

Basically, the 'model' should be the current state of the game. It's
stored in some sort of data structure that could translate to a
database, or a segment of RAM, or a set of flat files. How it's stored
isn't relevant so much as _that_ it's stored as *data*. To me, this is
stuff like Company A's share price is $100, Company B has 2 5-Trains,
and Company C just played Tile #7 into MapHex A5.

The Controller layer receives requests from the user through the
View's UI, and operates on the Model. It's the "glue" between UI and
Data. Much of our game engine code could be considered "controllers".
It takes the instructions from the UI, interprets the request through
the game's ruleset, then applies the relevant changes to the data
store to update the state of the game to reflect those changes.

The View is what the user sees. It may access Model objects for
read-only display purposes, but it should *not* change model objects.
All changes to the model's data should route through the various
Controllers because all of the logic on _how_ to update the game state
should be in the controller.

So... in our case, it is likely that we could further specify layers
in terms of function or based on how they interconnect, but the basic
design should look something like this:

Game State Data -> Data storage interface -> Game Engine and other
App-specific logic -> Public API -> UI.

I have a feeling that it may be time to do some housekeeping and more
clearly define the boundaries of each domain so that if we want to
swap out the Swing UI for Web-based, or swap our current in-memory
data store for a database, we can without needing to touch the other
parts of the code.

---Brett.



On Thu, Sep 2, 2010 at 2:12 PM, Stefan Frey <ste...@we...> wrote:
> Brett & Erik:
> Depending on the interpretation of model and state (general idea, pattern
> context, Rails context) I can agree/disagree with all your statements below.
>
> Example: If model is simply the whole set of data/structure of an 18xx game,
> and if state is defined as something that change its structure /behavior
> /properties at runtime, then I disagree (think definition of tracks on tiles).
> If we define model as all classes that inherit ModelObject and state as above,
> than I easily agree.
>
> So I try to clearly identify my interpretation my take simply is: Parts of the
> (game) model, which change their state (as defined above) directly/indirectly,
> extend ModelObject. There is no substantial difference, if the UI subscribe to
> the object or if only other part of the (game) model.
>
> Thus I suggest do derive all three cases below from ModelObject:
> A) First-class model objects (have state of its own, update UI directly)
> B) Derived model objects (derive their state from A) or C) type objects, but
> update UI directly)
> C) State objects  (have state of its own, but do not update UI directly)
>
> >From my point of view the difference between A and C is irrelevant on the
> model (MVC context here) level, as the model should not care which elements
> the UI/view subscribes.
>
> The difference between B and C might be somehow more
> relevant, especially if the only composite information for specific UI
> elements. Then it would make sense to move those into a controller layer, but
> they could still follow the ModelObject observer pattern.
>
> Another suggestion is those objects that have a state of their owns (type A
> and C thus get changed by Moves) implement a Moveable interface to identify
> those.
>
> Stefan
>
> On Thursday, September 02, 2010 10:19:35 pm brett lentz wrote:
>> On Thu, Sep 2, 2010 at 11:46 AM, Erik Vos <eri...@xs...> wrote:
>> > Turn-based boardgames are effectively state machines.  I'm not sure I
>> > can think of a model object that should be stateless.
>> >
>> > Certain parts of the view (in an MVC world) can and should be
>> > stateless, but the model *is* the state of the application (read:
>> > game).
>> >
>> > [EV] Of course there is always some form of state behind a model, but
>> > often it is not a single state. For instance, the views that give you a
>> > list of available trains, or the player worth, or a share percentage,
>> > have models that depend on some calculated value, which is not an
>> > independent state itself.
>>
>> Correct. This is where MVC tends to be an improvement to just an MV
>> design. Typically, the controller possesses the "business rules" that
>> derives those calculated values from the model.
>>
>> Originally, we started with a Model-View design. It's probably time to
>> work on cleaning up the distinction between Model and Controller, and
>> making that distinction to help clarify which is which.
>>
>> > Erik.
>>
>> ---Brett.