Re: [UndoManager] Re-introduce DOMTransaction interface?

>
>
> > To sum up, as an author I vote for--
> > var t = undoManager.transact("foo");
> > t.onundo = function() { ... };
> > OR t.setUndo(function() { .... });
>
> How do you envision it should work with an automatic transaction?
>
> We need some mechanism to tell the UA "record DOM mutations while I'm
> calling this function".
>
My preliminary thought is that transactions should be automatic unless
otherwise stated. Following that rationale, perhaps

var t;
// performs automatic transaction, no undo or redo needs specifying
t = undoManager.transact("foo", function() { ... });
t.execute();

t = undoManager.transact("bar", function() { ... });
t.onundo = function() { /* custom undo */ };
t.execute();

t = undoManager.transact("foobar", function() { ... });
t.onredo = function() { /* custom redo */ };
t.execute();

Whether onundo/onredo are assigned upon execute() is well defined, so
basing behavior on that is clear enough for me. Plus, I wonder - what is a
non-automatic transaction without an undo? A freak?

Some more ideas -- besides the other more verbose solutions (having
executeAutomatic(), a special property e.g. isAutomatic), you might extend
the vocabulary of UndoManager: either offer an additional argument for
transact (e.g. transact("foo", function() { ... }, true) ), or better imho,
have transact() specify a custom transaction and introduce record() (just
to avoid autoTransact()) which will specify an automatic transaction, thus
having:

t = undoManager.transact("lala", function() { });
t.execute(); // error, transact() with no undo()

t = undoManager.record("baba", function() {});
t.onundo = function() { }; // will be ignored/error thrown, since we're on
record()
t.execute();

Received on Thursday, 5 July 2012 21:50:43 UTC