- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Fri, 6 Jul 2012 19:02:37 -0700
- To: Yuval Sadan <sadan.yuval@gmail.com>
- Cc: public-webapps <public-webapps@w3.org>, James Graham <jgraham@opera.com>
- Message-ID: <CABNRm62X232i0n0O_V=D5aB2EqGSf2mUH3GZ9O2N9XBRX-s5dg@mail.gmail.com>
On Thu, Jul 5, 2012 at 4:40 PM, Yuval Sadan <sadan.yuval@gmail.com> wrote: > >> > 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. > I've spent some time thinking about pros and cons of this proposal, and it seems like this is indeed a nice interface because it doesn't expose execute as the object's property so that we don't have to treat "native" automatic transactions differently from an ordinary automatic transactions. See the thread titled "What should a "native" automatic transaction expose?". We should probably use the constructor instead of document.transaction though. So we'll have undoManager.execute(new DOMTransaction(function () { ~ })); for automatic transactions and var transaction = new DOMTransaction(function () { ~ }); transaction.onundo = function () { ~ }; transaction.onredo = function () { ~ }; undoManager.execute(t); for manual transactions. It also has an added benefit that now you can listen to undo/redo of a particular DOM transaction instead of all of them. - Ryosuke
Received on Saturday, 7 July 2012 02:03:24 UTC