Re: [Rails-devel] Undo / Redo design

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

I have committed some basic Action-related classes 
in a new package game.action. 
These classes should enable implementing an undo 
for simple share buying actions (without side effects), 
which I will try to do later this week.

Erik.
 

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of brett lentz
> Sent: 17 July 2006 21:43
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Undo / Redo design
> 
> I think that looks like it would hit most of the important points I
> was thinking of.
> 
> I think that might work.
> 
> ---Brett.
> 
> 
> On 7/17/06, Erik Vos <eri...@hc...> wrote:
> > Please also keep in mind, that some actions sometimes have 
> side effects
> > of a different nature. For instance, buying the first 4-train
> > rusts all 2-trains. Undoing this buy also must move all 
> these 2-trains
> > back from the bit bucket (actually a Bank portfolio named scrapHeap)
> > to the companies that last owned these.
> > All these side effects must be done and undone as one action!
> >
> > It is not practical to define separate action classes for 
> each possible
> > combination of direct and indirect effects. It is much easier
> > to work with very simple "movements" or whatever you would
> > like to call these subactions.
> >
> > So I would propose:
> > - An Action class, with do() and undo() methods, containing an
> > ArrayList of Move objects.
> > - An abtract Move class, which is the parent of all concrete Moves.
> > - A bunch of XxxMove class, e.g. CashMove, TileMove, CertificateMove
> > etc., each of which represents a specific type of minimal change.
> > Each of the Move objects would also have do() and undo() methods,
> > undo() being identical to do() with to and from swapped.
> >
> > Action.do() would call the do() method of each of the
> > contained Move objects. Similar with undo.
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: rai...@li...
> > > [mailto:rai...@li...] On Behalf
> > > Of brett lentz
> > > Sent: 17 July 2006 20:44
> > > To: Development list for Rails: an 18xx game
> > > Subject: Re: [Rails-devel] Undo / Redo design
> > >
> > > I was just thinking, that there's another option that exists.
> > >
> > > I'm thinking that it probably will require more work than 
> the other
> > > options, but it may be beneficial for us to do it because of the
> > > advantages in simplifying some of the complexity of the 
> application.
> > >
> > > We can define a parent object (Action) and/or interface 
> (Actionable)
> > > for our model objects to inherit from.
> > >
> > > Each object then, inherits a basic Do and Undo methods that can be
> > > overridden when needed.  For classes that do more than 
> one thing, the
> > > Do method can take the name of the action to take, and call the
> > > associated methods that will take the desired action.
> > >
> > > Then, the UI code can be reworked to call these Do and 
> Undo methods
> > > and we can make all other methods private to prevent them 
> from being
> > > called directly.
> > >
> > > >From there, we can create a stack and assure that each 
> Do method adds
> > > its parent object to the stack. This makes Undoing a 
> matter of popping
> > > the object off the stack and calling the Undo method. Any calling
> > > parameters can be accessed via an array held by the object.
> > >
> > >
> > > ---Brett
> > >
> > > On 7/17/06, Erik Vos <eri...@hc...> wrote:
> > > > I have also thought about this subject in the past weeks.
> > > >
> > > > Usually an action falls apart in several sub-action
> > > > (which I tend to call moves). An Action can contain any
> > > > number of moves; the determining factor is which combination
> > > > of moves constitute an "atomic" action, i.e. a series of
> > > > moves (changes) that must be executed and possibly undone
> > > as a whole.
> > > >
> > > > For instance, selling a share involves at least:
> > > > 1. The movement of a certificate from a player's portfolio
> > > > to the Bank Pool (another rportfolio),
> > > > 2. The movement of some cash from the Bank to the selling
> > > > player (both are CashHolders).
> > > > 3. A price drop, accompanied by the movement of the
> > > > company's token on the Stock Chart.
> > > >
> > > > One could express this in XML as follows (this does not mean
> > > > that I want to store the Undo stack in that way, although
> > > > it is an option):
> > > > <Action>
> > > >   <MoveCertificate company=PRR seqno=2 from=Player-1 to=Pool/>
> > > >   <MoveCash amount=67 from=bank to=Player-1/>
> > > >   <MovePrice company=PRR from=G6 to=G7/>
> > > > </Action>
> > > >
> > > > For many type of actions this is easy to implement, as many
> > > > movements already exist in much this way in the existing code
> > > > (see for instance Bank.transferCash() and
> > > Portfolio.transferCertificate()).
> > > > Of course, it becomes tricky when state changes enter 
> the picture.
> > > > For instance, a just floated company must be unfloated 
> in an Undo,
> > > > and such an activity does not yet exist.
> > > >
> > > > I am thinking to build up an Action gradually.
> > > > As soon as the user's request has been validated in 
> StockRound or
> > > > OperationRound, Action.start() is called, which creates a
> > > new (empty)
> > > > Action object.
> > > > Then the changes are executed, each being registered in the
> > > > Action object as additional moves,
> > > > e.g. with Action.add(new MoveCash (...)).
> > > > Finally Action.end() is called, closing the action (and perhaps
> > > > executing it, see below).
> > > >
> > > > Action.undo() should then undo the last action.
> > > >
> > > > Stacking can be easily added this way.
> > > >
> > > > One main decision to take is whether the changes should 
> be executed
> > > > parallel to creating the Action object (so that the 
> existing code
> > > > remains much the same), or that it is the Action object that,
> > > > when finished, actually performs the changes.
> > > >
> > > > Perhaps the latter option is better, as it enforces developers
> > > > to implement all changes, including state changes, in a
> > > symmetric way.
> > > >
> > > > I think this is a similar (or perhaps the same) choice as you
> > > > have presented below.
> > > >
> > > > Erik.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: rai...@li...
> > > > > [mailto:rai...@li...] On Behalf
> > > > > Of brett lentz
> > > > > Sent: 17 July 2006 07:31
> > > > > To: Development list for Rails: an 18xx game
> > > > > Subject: [Rails-devel] Undo / Redo design
> > > > >
> > > > > I've been thinking about how to approach implementing 
> Undo/Redo.
> > > > >
> > > > > It seems to me that there are two basic strategies that we
> > > > > can attempt.
> > > > >
> > > > > In each of them, we need to create a stack to store
> > > actions. Then, we
> > > > > can place the stack in front of or after the code to 
> execute the
> > > > > action.
> > > > >
> > > > > The basic flow would look something like this:
> > > > >
> > > > > Stack before Action (Stack as EventHandler):
> > > > > 1. Stack object receives call from UI to take an action.
> > > > > 2. Stack stores action taken
> > > > > 3. Stack object calls model object to resolve action.
> > > > >
> > > > > Stack after Action (Stack as a Listener):
> > > > > 1. Model code receives call to act.
> > > > > 2. Model resolves action
> > > > > 3. Model notifies Stack object of action just taken.
> > > > >
> > > > >
> > > > > I haven't really done much of an analysis of which
> > > approach would be
> > > > > more work or have additional implications.  There also
> > > could be other
> > > > > approaches I haven't thought of, as well.
> > > > >
> > > > > What are your thoughts on this?  Is there a solution with an
> > > > > obvious advantage?
> > > > >
> > > > >
> > > > > ----Brett.
> > > > >
> > >
> > > --------------------------------------------------------------
> > > -----------
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the
> > > chance to share your
> > > opinions on IT & business topics through brief surveys -- and
> > > earn cash
> > > http://www.techsay.com/default.php?page=join.php&p=sourceforge
> > > &CID=DEVDEV
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > >
> > >
> >
> >
> >
> > 
> --------------------------------------------------------------
> -----------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> > opinions on IT & business topics through brief surveys -- 
> and earn cash
> > 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
> &CID=DEVDEV
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> opinions on IT & business topics through brief surveys -- and 
> earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
> &CID=DEVDEV
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>