[Dev] Undo and commit()
pbossut at osafoundation.org
Wed Jan 4 09:10:52 PST 2006
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
More information about the Dev