[Dev] Undo and commit()

[Philippe Bossut]

Alec Flett wrote:

> So at the moment, I think one decision we need to make is when exactly 
> an undoable action "ends" It sounds like there are a few possibilities:
> 1) open-ended: Transactions begin when particular CPIA events fire, 
> and stay "open" until the next transaction starts. The advantage here 
> is that UI changes get automatically bundled with their previous 
> action, allowing the UI to return to exactly the previous state when 
> the command ran. This is also the disadvantage, since many UI changes 
> shouldn't be undone.
> 2) explicitly closed: transactions end either when someone calls 
> EndTransaction(), or automatically with the CPIA events mechanism. The 
> advantage is that undoable transactions aren't going to "leak" by 
> staying open - i.e. an "open" transaction wouldn't start to accumulate 
> irrelevant changes
> 3) Some hybrid, where CPIA events Begin transactions, and certain 
> types of CPIA events could also "end" open transactions without 
> starting a new one...

I think I'd go with possibility number 2: as expressed by others in this 
thread, there are too many scenarios that come to mind where an 
unbounded undo (possibility number 1) will backfire on the user.

Just to add one example not UI related: sending an e-mail or an invite 
for an event. Clearly, a repository based undo mechanism will be able to 
get the local repo to the pre send state but that's not a recall email 
mechanism, a subtlety surely missed by most users.

For some actions (like send invites or email), it's important to show 
users that those are *not* "undoable" (in a user centric sense) and make 
that very explicit. I think solution 2 gives us all the flexibility we 
need to make careful user centric choices on what's seen as undoable and 
what's not.

Cheers,
- Philippe