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.
