Re: [Rails-devel] Undo / Redo design

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

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.
> 
> 
> --------------------------------------------------------------
> -----------
> Using Tomcat but need to do more? Need to support web 
> services, security?
> Get stuff done quickly with pre-integrated technology to make 
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on 
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&
dat=121642
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>