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

[Ludovic Dubost]

Hi Marius,

Marius Dumitru Florea a écrit :
> Hi,
>
> As you may know I'm working on designing the new GWT-based WYSIWYG editor.
> Since my last mail on this subject, I've been reading about GWT's
> architecture and the WikiModel because these are the main underlying
> technologies that will be used for the new AJAX editor.
>
> The idea behind this design proposal is to make a lightweight and
> extensible editor, both for WYSIWYG editing and for Wiki-syntax editing.
> More precisely, the editor should have a lightweight core and should offer
> the possibility of adding new features (plug-ins), making it extensible.
>
>
> The Core
> ========
>
> The core's architecture is split in two: the client side and the server
> side. Both of them will be written in Java, but the client side will be
> translated in JavaScript with the help of GWT.
>
> The client side has the following components:
>
> 1. The tool bar handles a collection of action widgets, affecting the way
> we view and edit the content of the text area. It should be displayed at
> the top of the text area.
>
> 2. The rich text area allows us to view and edit formatted text, as in the
> case of a word processor application.
>
> 3. The status bar is a way of displaying to the user information such as:
> number of lines, connection status, time elapsed since last save operation
> etc. In a way, it is similar to the tool bar, but having only static
> widgets. The status bar should be positioned at the bottom of the text
> area.
>
> 4. The context menu has a list of menu entries which allow us to do
> context sensible actions, such as 'Paste here'. It should become visible
> on mouse right click.
>
> 5. The floating context tool bar is needed when we do a complex operation
> (like editing a table or an image) which has some options we can chose
> from and these options can't be found on the tool bar. Being context
> sensitive, it should be displayed when we 'activate' some object from the
> text area, and must be draggable.
>
>   
I like the floating context tool.. It can be very cool to display help 
or additional tools usable in the context..

> 6. The plug-in configuration panel should offer the possibility of
> configuring the editor's available features. For instance, in the case of
> the auto save feature, the user might want to set the save interval.
> (NOTE: I don't know if right now this preferences can be saved on a user's
> profile)
>   
It doesn't exist yet.. We can create settings fields for what is necessary

> Each of the components above will have an interface and at least one
> implementation of it. For instance, in the case of the rich text area one
> implementation could wrap the RichTextArea widget provided by the last
> version of the GWT.
>
> The server-side will be implemented as a GWT service (a servlet in
> reality). Here we have two options: we either create a new service facade
> (something like XWikiEditorServiceFacade) specific to our needs, or extend
> the XWikiService and XWikiGWTApp interfaces (which are used within XWiki
> Watch) with the needed functionality.
>   
The wysiwyg editor is part of the core, so I think it make sense to put 
it's api in the core XWikiService.. we don't need another servlet..

> The editor's core shouldn't offer any feature at all. Instead, it should
> allows us to install and uninstall features (plug-ins) depending on the
> displayed/edited content (WYSIWYG/Wiki-syntax). These plug-ins could be
> developed independent of the core.
>
>   
great
> The Plug-ins
> ============
>
> The plug-ins add functionality to the core. They are registered for a type
> of content: some plug-ins are available for the WYSIWYG editing (HTML
> content) and some are for the Wiki-syntax editing (XWiki, Creole,
> Confluence etc.). Also, the plug-ins can either act on the client-side
> only (make text bold, change font-family) or act both on the client side
> and on the server-side (auto save, add macro).
>
> Before the editor loads a document it installs all the available plug-ins
> associated with its content. When a plug-in is being installed it can: add
> an action widget to tool bar, add an entry to the context menu, add a
> static widget to the status bar, add a page (composite widget) to the
> configuration panel.
>
> Some plug-ins depend on a specific functionality on the server-side and
> because of this they need a way of accessing it. The editor's core should
> provide an API for this: Object executePlugin(String pluginName, Object
> args); this way the 'add macro' plug-in could retrieve from the server the
> list of the available macros and the 'auto save' plug-in could send the
> new content to the server, to be saved.
>
>   
Great..

I haven't see anything about realtime features.. Will this be done as a 
plugin (it might not be easy) or is this going to be part of the core 
editor.
With the realtime features there are things like "chat" that could be 
added..

Also we should also plan for embedding an editor inside another editor. 
For example we could embed a table AJAX editor inside the Wysiwyg editor.

Ludovic

> WDYT?
> -Marius
>
>
> _______________________________________________
> devs mailing list
> devs at xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
>   


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