incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Danilatos <dan...@danilatos.com>
Subject Re: editor handling events vs tracking DOM changes
Date Thu, 10 May 2012 23:15:18 GMT
That's right.

The one sentence summary is: as it's more reliable to handle the
events and make the changes explicitly, prefer that, but fall back to
"diffing" only where the alternative doesn't work or is too slow.

As Pat said that is almost never needed anymore.

Dan

On Fri, May 11, 2012 at 8:09 AM, Patrick Coleman <patcoleman@google.com> wrote:
> That's a good summary -
> For Wave we had the approach that we should take the approach of leaving
> some stuff to the browser, and doing some stuff manually;
> so for things like keyboard navigation, we let the browser do what it does,
> then figure out what changed - it's possible to do that manually in code,
> but laying out the contents manually and finding the position the cursor
> should go in JS seemed overkill.
>
> We also had Typing extractor to do that so we could try to mitigate
> slowness during typing (which is annoying) but as the project went on and
> browsers
> got faster, it ended up tolerable to process each insert/delete
> character(s) event in turn. This also turns out to be vital for when you
> want logic that the browser
> doesn't provide - e.g. if you select a particular document range and press
> delete, the default thing is to delete all the DOM selected which can also
> leave you with
> a tricky extraction step to line up what remains with your DOM
> (particularly tricky if you're allowing arbitrary custom elements in wave
> dom)
> whereas handling the event manually gives the ability to apply custom
> delete logic, and the wave -> html DOM mapping will stay correct.
>
> HTH - as mentioned above, there's no hard requirement either way, so if
> browser APIs change it might be worth moving some features between the two
> styles.
> (e.g. one thing we were considering was implementing keyboard navigation to
> allow 'smart' up/down presses, or alt/up-down to reorder lines, and if
> browsers
> implement APIs that give JS the ability to find the position of a cursor if
> the event were to be processed, that'd make those simpler).
>
> - Pat
>
> On 10 May 2012 14:44, Pratik Paranjape <pratikparanjape@gmail.com> wrote:
>
>> I am sure someone will correct me if I am wrong...
>>
>> The editor does not handle all user events.The use a hybrid model.
>>
>> There are things that are taken out by watching changes in DOM (e.g.
>> typing, pasting..).
>> Extractors are used for this...like Typing Extractor. These changes are
>> then applied to
>> underlying XML model, in turn used to calculate operations.
>>
>> Other things are handled before broswer does, like hitting Enter, bullets
>> etc
>> XML model is modified first in this case then rendered to HTML in DOM.
>>
>> There is also a third case, like in pasting. Browser is allowed to paste
>> somewhere off screen,
>> paste is observed , XML model is modified, then DOM is updated.
>>
>> It seems it has more to do with flexibility of allowing such Rich Text
>> interaction
>> than performance improvements for OT. Etherpad was plain text (adding rich
>> text slowly now?)
>> and prolly did not care of this level of control on how contents are
>> handled.
>>
>> More here:  http://www.youtube.com/watch?v=EuXApEulIzc
>>
>> On Fri, May 11, 2012 at 2:23 AM, Paulo Pires <pjpires@ubiwhere.com> wrote:
>>
>> > As far as I can tell, and if I'm not misunderstanding your question, a
>> > local local operation happens immediately, following the intent of
>> > having an "Optimistic UI", as Google called it. Only remote operations
>> > are transformed and then redrawn.
>> >
>> > Could it be that Etherpad has no such distinction?
>> >
>> > Btw, have you read the Operational Transform (OT) whitepaper?
>> >
>> > Cheers,
>> > PP
>> >
>> > On 10/05/12 21:21, Dylan Dandelion wrote:
>> > > If I understand correctly, the Wave editor handles user events and
>> > > processes them to generate operations, which are then applied to the
>> > > document result in the visual rendering of the operation.
>> > >
>> > > This approach is different from Etherpad, which finds DOM nodes that
>> have
>> > > changed at regular intervals, and then generates operations, sanitizes
>> > the
>> > > input and redraws the actual DOM.
>> > >
>> > > What are some of the advantages and disadvantages of the event-driven
>> > > approach versus the diff-ing approach? Why did Wave choose to implement
>> > the
>> > > editor using the event-driven approach?
>> > >
>> >
>> > --
>> > Paulo Pires
>> >
>> >
>>

Mime
View raw message