Re: [UndoManager] Re-introduce DOMTransaction interface?

On Jul 5, 2012 2:50 PM, "Yuval Sadan" <sadan.yuval@gmail.com> wrote:
>>
>>
>> > 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?

Yeah, a manual transaction without undo/redo is somewhat oxymoron in that
such an operation can be done completely outside of DOM transactions. If
the only point of calling transact was to add an entry to the undo
transaction history, then one can do so with an automatic transaction with
a trivial function() {}.

I'll that this is very similar to my original proposal where I had transact
decide whether a given transaction was automatic or not based on whether
undo/redo methods are provided or not (back then,they were called unapply
and reapply). However, Jonas and Ehsan didn't like this idea if I remember
correctly. They wanted a more explicit interface.

Also, the interface you proposed behaves somewhat oddly when the undo
manager from which the transaction was created is disconnected since
execute() will fail in such a case.

> 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();

Another approach will be to make the second argument optional and treat all
transactions created without a callback function as manual transactions
since there's no need for manual transaction's execute to be a callback.

- Ryosuke