On Wednesday, March 7, 2012 4:41:20 PM UTC+1, Damien Picard wrote:
>
>
>
> Le 7 mars 2012 15:54, Thomas Broyer a écrit :
>
>>
>> On Wednesday, March 7, 2012 2:07:38 PM UTC+1, Damien Picard wrote:
>>>
>>> Hi,
>>>
>>> You can find a demo here :
>>> http://surface-sample.**elasticbeanstalk.com/<http://surface-sample.elasticbeanstalk.com/>
>>
>>
>> Thanks.
>>
>> It's indeed a very young project: you cannot apply style across
>> paragraphs or other styles' boundaries (typical example: "fo<b>o b<i>a</b>r
>> b</i>az" → fo*o b**ar b*az)
>> That's one of the hardest things to handle in an editor, and the very
>> first thing I try out ;-)
>>
>
> Thank you to notice this problem ; in fact this is a selection range bug
> (sometimes the range is not set correctly, but only in prod mode :( I
> think I will spent a long time on this...) But the behavior you notice
> works fine, when the Range works... This is also the first thing I've
> implemented
>
>
>>
>>> Indeed, I'm reinventing the wheel. I did not known the Wave editor, I
>>> will take a look at it, but I'm not sure that handling something else than
>>> HTML is the right thing to do in my use case. There is some existing
>>> wysiwyg editors that uses the same idea of creating inserters instead of
>>> using execCommand (Aloha, as an example).
>>> But there is always something missing to me :
>>>
>>> - I need a GWT based wysiwyg (Wave editor, XWiki editor are
>>> candidates)
>>> - I need to create specific inserters
>>> - I need to control strictly the HTML output (because the HTML is
>>> exported with XSLT processors in my use case)
>>>
>>> Wave is based on documents that can easily be serialized as XML (that's
>> what we use for persistence).
>> Because it has to to handle "operational
>> transformation<http://www.waveprotocol.org/whitepapers/operational-transform>",
>>
>> inline styling (bold, italic, links, etc.) and paragraphs are represented
>> by "markers". Styling is represented by "annotations", so the markers are
>> "annotation boundaries", serialized in XML as processing instructions.
>> Paragraph boundaries are representing by <line/> elements (similar to <br>
>> in HTML except a <line/> marks the beginning of a paragraph, and can have a
>> "type" and "level": title, ordered list, unordered list). These are just
>> the built-in representations though, you're free to implement whatever you
>> want (it'd just require a bit more work).
>> The "persistent document" is first processed to build a "local document"
>> (<line/>xxx is transformed to <l:p>xxx</l:p>, annotations are transformed
>> to <l:s> spans, etc.), then each element of this document is rendered into
>> HTML. Each modification made on the document (either persistent or local)
>> is passed to the renderer to update the view.
>> Have a look at
>> http://www.waveprotocol.org/code/tutorials/writing-a-doodad and
>> http://www.waveprotocol.org/wave-protocol-summit/wave-summit-talks
>> (particularly
>> “Wave model deep dive” by Alex North, and “Wave panel and rendering” and
>> “Real-time editor & Doodads” by Dave Hearnden), and search for my mails on
>> the Wave mailing lists, where people answered with many valuable
>> information and links. Re. the code, start with the EditorHarness GWT app.
>>
>> In our case, we chose to keep the paragraphs-via-<line/> and
>> styling-via-annotations (because it was easier), and added table rendering,
>> links (handled as elements so we can easily make sure we don't nest them),
>> "semantic annotations" (same as links), and illustrations (similar to an
>> image, but links to an entity that carries both the image and legend, among
>> many other things).
>> In some "rich text areas", we're able to limit available features: some
>> areas a "single paragraph" with only styling a "semantic markup", others
>> allow several paragraphs but no titles, etc.
>> Finally, by listening to document changes, we keep a document outline,
>> index of "semantic markup" (as CellTree widgets), and lists of tables and
>> illustrations (as CellList widgets) in real-time.
>>
>> The only thing needing real work is the copy/paste handling, which in
>> Wave is tightly bound to Wave's "wavelet" document schema. In our case, we
>> simply shadowed the class to strip every formatting and paste as plain text.
>>
>
> I've checked out the code ; I will try to extract and use only the editor
> in a sample project. Maybe you've already done this work ?
>
I'm building Wave out-of-the-box ("ant dist-libraries" IIRC) and then
picking the client, client-common, client-scheduler, common, media, model,
and util JARs.
Maybe some of them are only needed for the EditorToolbar which we're also
using, but I doubt so.
>
>
>> Overall, the code is complex but very well thought out, so once you
>> grasped the concepts, it reads fairly easily.
>>
>>>
>>> - I need to process the HTML "in-place", by DOM manipulation
>>>
>>>
>> Not sure what you mean by that, but Wave uses DOM manipulations
>> exclusively (see above).
>>
> In fact, I want to launch a command that make some changes on the
> currently editing content. If this is the only thing missing in Wave
> editor, I think I can do it. This is not really difficult.
>
If you're thinking along the way of your "add line" and "drop line" for the
table, then that can already be done (and we did it). If you look at the
EditorToolbar and how it's used in Wave, you'll see that various buttons
(bold, italic, heading level, etc.) are selected/unselected depending on
selection in near-real-time.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/4NYFk63uQ0IJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
