- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Thu, 05 Jul 2012 03:35:42 +0300
- To: Ryosuke Niwa <rniwa@webkit.org>
- CC: public-webapps <public-webapps@w3.org>, Ojan Vafai <ojan@chromium.org>, Jonas Sicking <jonas@sicking.cc>, Ehsan Akhgari <ehsan@mozilla.com>, Erik Arvidsson <arv@chromium.org>, Adam Barth <w3c@adambarth.com>, Sukolsak Sakshuwong <sukolsak@gmail.com>, Aryeh Gregor <ayg@aryeh.name>
On 07/05/2012 03:25 AM, Olli Pettay wrote:
> On 07/05/2012 03:11 AM, Ryosuke Niwa wrote:
>> On Wed, Jul 4, 2012 at 5:00 PM, Olli Pettay <Olli.Pettay@helsinki.fi <mailto:Olli.Pettay@helsinki.fi>> wrote:
>>
>> On 07/05/2012 01: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 don't understand what is difficult.
>> How is that any different to
>> target.addEventListener("foo", { handleEvent: function() {}})
>>
>>
>> It will be very similar to that except this object is going to have 3 callbacks instead of one.
>>
>> The problem is that the event listener is a very special object in WebKit for which we have a lot of custom binding code. We don't want to implement a
>> similar behavior for the DOM transaction because it's very error prone.
>
> So, it is very much implementation detail.
> (And I still don't understand how a callback can be so hard in this case. There are plenty of different kinds of callback objects.
> new MutationObserver(some_callback_function_object) )
>
>
>>
>> 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"'));
>>
>>
>> Looks somewhat odd. DOMTransaction would be just a container for a callback?
>>
>>
>> Right. If we wanted, we can make DOMTransaction an event target and implement execute, undo, & redo as event listeners to further simplify the matter.
>
> That could make the code more consistent with rest of the platform, but the API would become harder to use.
>
Perhaps API could be something like
undomanager.transact("foo"); That would return Transaction object which implements EventTarget.
Then in common case
undomanager.transact("foo").onundo = function(evt) { /* do something.*/}
>>
>> - Ryosuke
>>
>
>
Received on Thursday, 5 July 2012 00:36:20 UTC