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

Re: [UndoManager] Re-introduce DOMTransaction interface?

From: James Graham <jgraham@opera.com>
Date: Thu, 05 Jul 2012 17:08:36 +0200
Message-ID: <4FF5ADF4.2@opera.com>
To: public-webapps@w3.org
On 07/05/2012 12:38 AM, Ryosuke Niwa wrote:
> Hi all,
>
> Sukolsak has been implementing the Undo Manager API in WebKit but the fact
> undoManager.transact() takes a pure JS object with callback functions is
> making it very challenging.  The problem is that this object needs to be
> kept alive by either JS reference or DOM but doesn't have a backing C++
> object.  Also, as far as we've looked, there are no other specification
> that uses the same mechanism.

I am given to understand that this kind of construct is not a big 
problem for Opera.

> Since I want to make the API consistent with the rest of the platform and
> the implementation maintainable in WebKit, I propose the following changes:
>
>     - Re-introduce DOMTransaction interface so that scripts can instantiate
>     new DOMTransaction().
>     - Introduce AutomaticDOMTransaction that inherits from DOMTransaction
>     and has a constructor that takes two arguments: a function and an optional
>     label
>
> After this change, authors can write:
> scope.undoManager.transact(new AutomaticDOMTransaction{function () {
>      scope.appendChild("foo");
> }, 'append "foo"'));
>
> instead of:
>
> scope.undoManager.transact({executeAutomatic: function () {
>      scope.appendChild("foo");
> }, label: 'append "foo"'});
>
> And
>
> document.undoManager.transact(new DOMTransaction({function () {
>          // Draw a line on canvas
>      }, function () {
>          // Undraw a line
>      }, function () { this.execute(); },
>      'Draw a line'
> }));
>
> instead of:
>
> document.undoManager.transact({ execute: function () {
>          // Draw a line on canvas
>      }, undo: function () {
>          // Undraw a line
>      }, redo: function () { this.execute(); },
>      label: 'Draw a line'
> });
>

I think this proposed API looks particularly verbose and ugly. I thought 
we wanted to make new APIs more author friendly and less like refugees 
from Java-land.

Changing the design here seems fine as long as it is not to something 
that is worse for authors; priority of constituencies suggests that we 
favour authors over implementers. I think this proposed design is worse. 
Perhaps an event based approach is not, but I would need to see the 
detailed proposal.
Received on Thursday, 5 July 2012 15:09:12 GMT

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