[xwiki-devs] [Proposal] New GWT-based WYSIWYG editor

Ludovic Dubost ludovic at xwiki.org
Tue Sep 11 10:35:31 CEST 2007


Hi,


Sergiu Dumitriu a écrit :
> Hi,
>
> I was thinking that having a GWT based editor has some advantages, but
> also some disadvantages.
>
> Pro:
> - We don't need to duplicate (or triplicate) the rendering code, as
> the TinyMCE based editor almost reimplemented Radeox in Javascript,
> just that in an ugly manner. The regular expression for rendering
> headings, for example, had to be written once in the resource files,
> for Radeox, once in Javascript for transforming wiki markup to html,
> and once in Javascript to transform html back into wiki markup.
>   
This one is really important.. we see a lot of work to keep things working

> - We write only one plain old Java code, but it works and looks the
> same across most browser, since GWT handles the differences
>   
Yes also.. we loose a lot of time in browser compatibility

> - No problems with popup blockers, since GWT uses internal frames (afaik)
>   
Also this is much faster. Currently popups are slow in FF in tinyMCE

> - We can write nice clean code on the server side, since it is Java.
> With JS it takes a lot more effort to write nice code, especially when
> you have to deal with all the browser bugs and differences in
> behavior.
>   
All the code will be cleaner and more modularized. It will be easier to 
embed the editor in other situations.

> - With a little more effort, we should be able to make real-time
> collaborative editing possible. No more edit locks, no more edit
> conflicts.
>
>   
Yes..

> Con:
> - Editing a document will create a lot of connections to the server,
> since it is Ajax based. How well does it scale? Ludovic should be able
> to tell from the Curriki experiences, and Curriki is a large scale
> test platform for GWT on XWiki. We could reduce this problem by making
> the code less dependent on server processing, if that's possible.
>   
I don't think we need a lot of connections. Only a few in the beginning 
then a few when we switch from wysiwyg to wiki and vice versa.
The additional ones on Copy Pasting. The good thing with GWT is that we 
can keep AJAX calls to the data set and with less server work

What we see is that editing is a less frequent task than viewing.. So 
scaling is not so much an issue. Curriki loads quite a lot of info from 
the server and it works well.

> - We don't control the generated javascript/html anymore, so we can
> say goodbye to xhtml-validity, accessibility, standards compliance.
>   
Normally GWT should generate standard compliant code. It is possible to 
use mostly FlowPanel to work mainly with div. This is what we do not 
most of the time in Curriki and it works well.
It's just the GWT documentation is misleading by proposing so many 
controls using tables..

> - It was said that the current editor takes a lot to start. Will there
> really be a sensitive speedup when we'll use GWT? I don't think so,
> actually it could be worse for small documents. Indeed, the current
> editor has an O(e^(size)) loading time, while the GWT editor will
> (hopefully) have a linear loading time, but for small sizes I'm not
> sure it will be better. I had some bad experiences with some GWT
> interfaces in Curriki. We'll have to try it and see how it goes.
> Moreover, I'm sure that the tinyMCE regular expressions could be
> optimized to reduce the loading time.
>
>   
I don't think it's the regular expression that takes long for the 
tinyMCE to load.. It has itself a lot of code..
GWT 1.4 has been greatly improved in loading time (around 1 or 2 
requests instead of more than 5).
Also GWT optimizes your JS code (get's rid of unnecessary code) which 
will also greatly reduce loading time.
We could speed up loading by passing the intial conversion in the wiki 
page instead of making a server query.

Once you're in, GWT is going to be very fast.

> So, my major reasons why I'd go for the new editor is that we don't
> need to duplicate code anymore, and we don't need to deal with browser
> differences/bugs.
>
>   
Also move to WikiModel and make something very clean in terms of Wysiwyg 
to syntax handling, better Copy Pasting (from Word), Real time editing, 
auto complete, visual macros, etc..

> But I think that the major showstopper is the performance issue.
> Ludovic, how well does GWT work? How much stress does it put on the
> server? How does the server load change with GWT?
>
>   
I think that we can limit server queries to the necessary. Realtime is 
going to cost more.

Ludovic
> On 9/10/07, Vincent Massol <vincent at massol.net> wrote:
>   
>> Hi,
>>
>> I'd like us all to welcome Marius Dumitru Florea who has joined the
>> XWiki dev community to work on a new GWT-based WYSIWYG editor. Marius
>> is very new to the XWiki team so I'd like all of us to support him
>> for this very important work.
>>
>> This is really just the start of this project so we need everyone's
>> help in designing it and for providing feedbacks and ideas.
>>
>> I've started a page on it there:
>> http://www.xwiki.org/xwiki/bin/view/Idea/NewWysiwygEditorBasedOnGwt
>>
>> I'll we working with Marius on this for the time being and Jean-
>> Vincent will probably help us in the future too. And anyone willing
>> to help is most welcome.
>>
>> As I've mentioned on that page we have 3 main issues with the current
>> WYSIWYG editor so it's time to start fixing them. The current Tiny-
>> MCE based editor as the following deficiencies:
>> * Slow
>> * Complex code using complex regexs. This leads to a fragility that
>> makes it break somewhere whenever someone adds a modification to it.
>> * Lots of bug reports consistently for the past year, showing a non-
>> optimal design
>>
>> I'll kick-start the discussion with some open questions I've listed
>> on that page:
>>
>> * Is there a GWT editor component we can/should reuse?
>> * Check WikiModel capabilities for conversions in both directions and
>> especially from HTML to wiki syntax.
>> * How to integrate WikiModel in the Rendering layer of XWiki?
>> * Is there any code to be salvaged from the work done by Christian
>> and Nam in that branch: svn+ssh://svn.forge.objectweb.org/svnroot/
>> xwiki/xwiki-platform/core/branches/XWIKI_WYSIWYG_NEWARCHI
>>
>> If anyone has any insight on these questions, please speak up! :)
>>
>> Thanks everyone,
>> -Vincent
>>     
>
> Sergiu
>   


-- 
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost 
AIM: nvludo Yahoo: ludovic



More information about the devs mailing list