Re: [UndoManager] Re-introduce DOMTransaction interface?

>
>
> > 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?
>
> 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.
>
What I find appealing in this example is that the transaction is an
operation which is indeed disconnected from the UndoManager. Perhaps I'm
missing something here, but what do we gain by having UndoManager being the
place of both creation and execution of the DOMTransaction object? If I may
take the notion further, it might as well originate elsewhere, and connect
to an UndoManager only on execute(), e.g.

t = document.transaction("foo", function() {  }); // or new
DOMTransaction(), actually
t.onundo = function() {   };
undoManager.execute(t);

I realize as I'm writing that this is a hybrid suggestion between new
DOMTransaction() and the event handler version. It gives reason for
introduction of the DOMTransaction() standalone instantiation.
Perhaps I'm going to far. It just seems logical.

It encapsulates the action as well as the reverse action. I find this to be
explicit and simple enough to write without confusion. Every idea is
specified once and in a clear place - (a) what to do, (b) how to undo and
(c) execute. More specific than this would be verbose imho.


> 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.
>
I fear that changing placement of the execute function in different
circumstances will cause confusion and that it is indeed too implicit.