[whatwg] Re-introducing AutomaticDOMTransaction interface to decouple automatic transaction from UndoManager

I started to think automatic DOM transaction's ability to record DOM
mutations and then being able to unapply/reapply them later is useful even
outside of UndoManager.

For example, such DOM mutation can be used as a DOM-mutating animation or
transition effect. e.g. a web app can add a widget inside an automatic
transaction upon some user action, and then tear it down using "unapply" to
hide the widget. It can then "reapply" the transaction to reshow the widget.

And we can make this possible very easily by re-introducing
AutomaticDOMTransaction interface. i.e. we do:
editor.undoManager.transact(AutomaticDOMTransaction(function () {...}, {
someProperty: 'someValue', ... }));
instead of:
editor.undoManager.transact({apply: function () {...}, isAutomatic: true,
someProperty: 'someValue', ... });

Then the constructor of AutomaticDOMTransaction will automatically execute
the function and create unapply and reapply methods. Then the author can
call unapply/reapply on the automatic DOM transaction at any moment (as
long as they're in right order):
myTransaction = AutomaticDOMTransaction(function () {...}, {hello:
"world"}).apply();
myTransaction.unapply();
myTransaction.reapply();
alert(myTransaction.hello); // This will alert "world".

With this approach, we don't even need "apply" on transaction objects since
transact() is no longer responsible for storing information for automatic
transaction; it eliminates the whole argument about having apply/reapply
vs. having a boolean/string argument in apply, and aligns the design of our
undo manager more closely with that of other platforms such as .net, Cocoa,
Qt, etc..

Any thoughts/opinions?

Best,
Ryosuke Niwa
Software Engineer
Google Inc.

Received on Sunday, 27 November 2011 22:33:37 UTC