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