[whatwg] Exceptions in UndoManager
Ryosuke Niwa
rniwa at webkit.org
Wed Jul 4 14:42:27 PDT 2012
On Wed, May 30, 2012 at 8:43 AM, Alex Vincent <ajvincent at gmail.com> wrote:
>
> 1. "What state will the UndoManager be in when an exception happens?"
> There may be transactions that were undone, cropped off by the transact()
> call, which per the spec are now unrecoverable. Also, in the undo or redo
> cases, we might be in the middle of a merged transaction. The spec says we
> can't call undo while we're unapplying a transaction... nor can we call
> redo. So where will we be - both during the event dispatch and in the
> aftermath?
> 2. "What information about the exception will be included with the
> event - or with the UndoManager?"
> 3. "If the UndoManager can recover somehow to a known good state
> without intervention, how can it indicate that - and possibly, what that
> good state would look like?"
> 4. "If no recovery is completed, is it acceptable to mark the
> UndoManager in an error state and prevent further transactions from either
> happening or being recorded until both undo and redo stacks have been
> completely cleared?" (I'm thinking of a fatal error state, which can be
> recovered if you throw away all your history.)
> 5. If there is a recovery by one event listener, should another event
> indicating that recovery be dispatched, so that earlier event listeners are
> aware of the new good state?
>
> I can write up a simple HTML + SVG document illustrating the UndoManager
> Exception cases I can dream up, if anyone's interested. There's four main
> areas: during transact with no undone transactions, during undo where we
> may be in the middle of a transaction group, during redo where we may be in
> the middle of a transaction group, and during transact where some
> transactions have been undone.
>
> For question 3, I would propose including an UndoManager mockup without
> methods: a static data representation of the default after-state. Note
> that it is perfectly okay in my opinion for the UndoManager to report "I
> cannot recover from this on my own," and not provide this mockup at all.
>
For point 1, we should move step 2 (clear all redo) in the definition of
transact() to after step 3.
Points 2 and 5 makes me think that we should just propagate the exception
instead of firing an event. Whoever is catching the exception can take
appropriate actions then.
I don't understand what you mean in point 3.
What's the use case for point 4.
In general, I don't want to make the spec too complicated. I want to
provide the simplest API that gets job done. If there are some use cases
that require elaborate exception handling, then I would like to let
scripts/libraries provide such an API instead of baking it natively into
the spec. Of course, the native UndoManager should be flexible enough to
accommodate such needs.
- Ryosuke
More information about the whatwg
mailing list