W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [UndoManager] Re-introduce DOMTransaction interface?

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Fri, 6 Jul 2012 19:02:37 -0700
Message-ID: <CABNRm62X232i0n0O_V=D5aB2EqGSf2mUH3GZ9O2N9XBRX-s5dg@mail.gmail.com>
To: Yuval Sadan <sadan.yuval@gmail.com>
Cc: public-webapps <public-webapps@w3.org>, James Graham <jgraham@opera.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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:53 GMT