Re: [whatwg] Exceptions in UndoManager

On Wed, May 30, 2012 at 8:43 AM, Alex Vincent <ajvincent@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

Received on Wednesday, 4 July 2012 21:43:14 UTC