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

I'm having two sets of doubts about this:

1. I think decoupling transactions and the Undo Manager could also be potentially bad, since it's not immediately obvious which undo manager (if any) ends up tracking those transactions.

2. This seems to shift the execution time of the transaction to the object creation time, as opposed to when transact is called.  I'm not sure if this is a good idea.

Cheers,
Ehsan


----- Original Message -----
> From: "Ryosuke Niwa" <rniwa at webkit.org>
> To: "Jonas Sicking" <jonas at sicking.cc>, "Aryeh Gregor" <ayg at aryeh.name>, "Ehsan Akhgari" <ehsan at mozilla.com>, "Ojan
> Vafai" <ojan at chromium.org>, "Anne van Kesteren" <annevk at opera.com>, "Alex Russell" <slightlyoff at chromium.org>, "Annie
> Sullivan" <sullivan at chromium.org>
> Cc: whatwg at lists.whatwg.org
> Sent: Monday, November 28, 2011 1:33:37 AM
> Subject: 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.

-- 
--
Ehsan Akhgari
ehsan at mozilla.com
http://ehsanakhgari.org/

Received on Wednesday, 30 November 2011 12:36:07 UTC