Le 7 mars 2012 18:53, Thomas Broyer <[email protected]> a écrit :

>
>
> 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.**elasticb**
>>>> eanstalk.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
>>
>  I've fixed the problem, you can play with it ;) (there is some other
bugs, but there are all dues to Ranges)

>
>>
>>>
>>>> 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 <http://www.waveprotocol.org/code/tutorials/writing-a-doodad>
>>>  and http://www.**waveprotocol.org/wave-**protocol-summit/wave-summit-**
>>> talks<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.
>

In fact I would like to add Table, Images, etc. facilities, as Aloha uses
(The table UI is very useful in Aloha) . And I want to add such behaviours.

>  --
> 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.
>



-- 
Damien Picard
Axeiya Services : http://axeiya.com/
stillcollab-surface : http://code.google.com/p/stillcollab-surface/
Mon livre sur GWT : http://axeiya.com/index.php/ouvrage-gwt.html

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
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.

Reply via email to