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(a)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