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