[xwiki-devs] [Discussion] New GWT-based WYSIWYG editor
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. 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) 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 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. 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. WDYT? -Marius
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 [email protected] 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
participants (2)
-
Ludovic Dubost -
Marius Dumitru Florea