Re: [UndoManager] Re-introduce DOMTransaction interface?

On Thu, Jul 5, 2012 at 8:08 AM, James Graham <jgraham@opera.com> wrote:

> On 07/05/2012 12:38 AM, Ryosuke Niwa wrote:
>
>> 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.
>

What makes you say so? If anything, you don't have to have labels like
execute, undo, and redo. So it's less verbose. If you don't like the long
name like AutomaticDOMTransaction, we can come up with a shorter name.

Also, I think consistency matters a lot here. I'm not aware of any other
Web-facing API that takes a pure object with callback functions.

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.


I would like to hear why it's worse with some logical explanation. All
arguments I've heard so far are "ugly" and "verbose" but I'm not seeing
either.

On Thu, Jul 5, 2012 at 11:07 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:
>
> We shouldn't change the UndoManager API because of implementation issues,
> but if event based API ends up being better.


I don't think it's reasonable to agree on an unimplementable design. In
theory, mutation events can be implemented correctly but we couldn't, so
we're moving on and getting rid of it.

- Ryosuke