[whatwg] Fixing undo on the Web - UndoManager and Transaction

On Mon, Sep 12, 2011 at 6:06 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> On Mon, Sep 12, 2011 at 5:19 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> Could you please supply an example where the apply/reapply split leads
>> to cleaner or otherwise better code than using a boolean argument?
>
> apply: function() {
> ? // modify dom
> ? // send data back to server
> },
> unapply: function() {
> ? // ask server what I should do for undo
> ? // modify dom
> },
> reapply: function() {
> ? // ask sever what I should do for redo
> ? // modify dom
> }
> I can't give you a code from existing apps because such apps do not use
> undoManager API.

In what situations would you ask the server what to do for
undo/reapply? I was under the impression that for collaborative
editing the client still held the full list of modifications, but that
you mutated that list as you got events regarding other peoples edits.

This example does bring up an interesting question though. Is it ok
that the undo interface is synchronous? If you have to ask the server
how to do the undo/reapply, then you might be forced to use
synchronous XHR which produces bad UI (since the page locks up for the
duration of the request).

>> Having slightly different signatures for the apply function on both
>> transaction feels like a much smaller problem. Either we can rename
>> 'apply' on automatic transactions, or we can give it a boolean
>> argument too which is passed 'false'. It's easy enough to ignore
>> arguments in JS, simply don't put them in your function signature.
>
> I'm fine with adding a boolean argument if we're splitting the interface for
> automatic and manual transactions because then we don't need to have boolean
> argument in automatic transaction's apply.

Then I think we should go this route.

Maybe rename the property to "execute" or "do" for automatic transactions?

/ Jonas

Received on Thursday, 15 September 2011 11:17:59 UTC