- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Discussion] New GWT-based WYSIWYG editor
by Marius Dumitru Florea 21 Sep '07

21 Sep '07

Hi, Last time, I've presented some general ideas regarding the new GWT-based architecture for the WYSIWYG editor. Now I'm going to give you the details. More precisely, based on the components described in my last mail I've defined an API. You should be aware that all package, interface, class, method, field names are subject to change and I'm open to your suggestions. We should use self-explanatory and natural names as much as we can. But before delving into the API I should recap the main ideas from my last mail. We're designing a lightweight and extensible editor, both for WYSIWYG editing and for Wiki-syntax editing. The editor has a featureless core allowing us to easily add and remove features (plug-ins). Enough with the introduction. Here's the API: org.xwiki.editor.client.core.impl.def ------------------------------------- class DefaultConfigPanel extends AbstractConfigPanel class DefaultContextMenu extends AbstractContextMenu class DefaultEditor extends AbstractEditor +DefaultEditor(PlugInManager, EditorServiceAsync) class DefaultFloatingToolBar extends AbstractFloatingToolBar class DefaultRichTextArea extends AbstractRichTextArea class DefaultStatusBar extends AbstractStatusBar class DefaultToolBar extends AbstractToolBar org.xwiki.editor.client.core.impl --------------------------------- abstract class AbstractConfigPanel extends Composite implements ConfigPanel abstract class AbstractContextMenu extends Composite implements ContextMenu abstract class AbstractEditor extends Composite implements Editor #EditorServiceAsync editorService #PlugInManager plugInManager #AbstractConfigPanel configPanel #AbstractContextMenu contextMenu #AbstractFloatingToolBar floatingToolBar #AbstractRichTextArea richTextArea #AbstractStatusBar statusBar #AbstractToolBar toolBar abstract class AbstractFloatingToolBar extends Composite implements FloatingToolBar abstract class AbstractPropertyManager implements PropertyManager #boolean dirty #abstract void doApplyChanges() #abstract void doDiscardChanges() +boolean isDirty() #abstract void doRestoreDefaults() +void setDirty(boolean) abstract class AbstractRichTextArea extends Composite implements RichTextArea abstract class AbstractStatusBar extends Composite implements StatusBar abstract class AbstractToolBar extends Composite implements ToolBar org.xwiki.editor.client.core ---------------------------- interface ConfigPanel void addPage(String name, Widget page, PropertyManager manager) enum ContentType {HTML, XWIKI, CREOLE, CONFLUENCE} interface ContextMenu void addCheckBox(String label, Command cmd) void addImage(AbstractImagePrototype imgProto, String label, Command cmd) void addRadioButton(String groupName, String label, Command cmd) ContextMenu addSubMenu(AbstractImagePrototype imgProto, String label) interface Editor ConfigPanel getConfigPanel() ContextMenu getContextMenu() EditorServiceAsync getEditorService() FloatingToolBar getFloatingToolBar() RichTextArea getRichTextArea() StatusBar getStatusBar() ToolBar getToolBar() interface EditorService Serializable invoke(String plugInServiceName, Serializable args) Map<String, String> restoreProperties(String plugInName) void storeProperties(String plugInName, Map<String, String> properties) interface EditorServiceAsync void invoke(String plugInServiceName, Serializable args, AsyncCallback) void restoreProperties(String plugInName, AsyncCallback callback) void storeProperties(String pn, Map<String, String> props, AsyncCallback) interface FloatingToolBar extends ToolBar interface PropertyManager void applyChanges() void discardChanges() void restoreDefaults() interface RichTextArea extends SourcesClickEvents, SourcesFocusEvents, SourcesKeyboardEvents, SourcesMouseEvents, SourcesMouseWheelEvents, SourcesScrollEvents, HasHTML, HasText, com.google.gwt.user.client.ui.RichTextArea.ExtendedFormatter interface StatusBar extends HasWidgets interface ToolBar extends HasWidgets org.xwiki.editor.client.plugin.impl.def --------------------------------------- class DefaultPlugInManager extends AbstractPlugInManager -Map<ContentType, List<PlugIn>> plugInMap class DefaultPlugInPropertyManager extends AbstractPropertyManager -PlugIn plugIn -Map<String, String> properties -Map<String, String> defaults +DefaultPlugInPropertyManager(PlugIn plugIn, Map<String, String> defaults) org.xwiki.editor.client.plugin.impl ----------------------------------- abstract class AbstractPlugIn implements PlugIn #Editor editor #PropertyManager propertyManager #Map<String, String> properties #abstract void installConfigPanel() #abstract void installContextMenu() #abstract void installFloatingToolbar() #abstract void installRichTextArea() #abstract void installStatusBar() #abstract void installToolBar() #abstract void uninstallConfigPanel() #abstract void uninstallContextMenu() #abstract void uninstallFloatingToolbar() #abstract void uninstallRichTextArea() #abstract void uninstallStatusBar() #abstract void uninstallToolBar() abstract class AbstractPlugInManager implements PlugInManager org.xwiki.editor.client.plugin ------------------------------ interface PlugIn String getName() String getProperty(String name) PropertyManager getPropertyManager() Iterator<String> getPropertyNames() void install(Editor editor) void setProperty(String name, String value) void uninstall() interface PlugInManager void register(PlugIn plugIn, ContentType contentType) void register(PlugIn plugIn, ContentType[] contentTypes) void unregister(PlugIn plugIn, ContentType contentType) void unregister(PlugIn plugIn, ContentType[] contentTypes) Iterator iterator(ContentType contentType) org.xwiki.editor.server.core.impl.def ------------------------------------- class DefaultEditorService extends RemoteServiceServlet implements EditorService -PlugInServiceManager plugInServiceManager org.xwiki.editor.server.plugin.impl.def --------------------------------------- class DefaultPlugInServiceManager implements PlugInServiceManager -Map<String, PlugInService> plugInServiceMap org.xwiki.editor.server.plugin.impl ----------------------------------- abstract class AbstractPlugInService implements PlugInService org.xwiki.editor.server.plugin ------------------------------ interface PlugInService Serializable invoke(Serializable args) String getName() interface PlugInServiceManager PlugInService get(String plugInServiceName) Iterator iterator() void register(PlugInService plugInService) void unregister(PlugInService plugInService) NOTE: All the interfaces and classes that I'm referring to but I'm not defining them are from the last version of the GWT. I'll use this occasion to answer Ludovic and to ask him, and you at the same time, some questions. Ludovic, - we could make XWikiService extend EditorService - I'd like to keep the editor's core as simple as possible - a plugin could open as many popups, dialogs, windows as it needs. The idea is that finally it either changes the content or the way we visualize the content. So, I think the table AJAX editor could be handled as a plugin. Questions: - what 'real time editing' truly means? Unfortunately right now I don't have a clear idea of what it is supposed to do/offer. Can you give me some use cases or examples of applications that are already doing it. - how are we going to mix (at user interface level) text editing and chat activities? It seems to me that the chat is a different application. - what is 'table AJAX editor' supposed to do? What other editors could be 'embeded' into the WYSIWYG editor? WDYT? -Marius

1 0

[xwiki-devs] [VOTE] Release Core 1.1.1 today or tomorrow
by Vincent Massol 21 Sep '07

21 Sep '07

Hi, We have our first use case where we need to release the Platform Core independently of the rest. Use case: XEM needs to be released on Monday and requires http:// jira.xwiki.org/jira/browse/XWIKI-1740 to be applied to the Core for it to work. Proposal: I apply XWIKI-1740 and we release the Core version 1.1.1 today or tomorrow (this is what I'm asking you to vote for!). BTW it already has 3 issues fixes: * Cache issue on new document creation in multilingual mode * Document change notification not sent for new documents * Fullscreen doesn't work on IE6 or IE7 Note: This means that we're now separating versions for the Core from versions from Web, XE, etc. Since now they were all aligned to be the same. This is good news for me since this means our work on modularizing the building is going to be used ;). So after 1) is done the next release versions will be: Core: 1.1.2 Web: 1.1.1 (or 1.2M1) Panels: 1.1.1 (or 1.2M1) XE: 1.1.1 (or 1.2M1) Note: that when we release Core 1.2M1 then all versions will be aligned again. Here's my +1 to that. Thanks -Vincent

1 1

Re: [xwiki-devs] [xwiki-users] [ANN] XWiki Enterprise Manager 1.0 Milestone 1Released
by Vincent Massol 21 Sep '07

21 Sep '07

Hi Brandon, On Sep 21, 2007, at 11:30 AM, Esbach, Brandon wrote: > Clarification: > If I read right, the manager tool is installed as a separate wiki? It is, however since the development is modular you could also transform an existing wiki into a XEM wiki by: * adding virtual=1 in xwiki.cfg + generally speaking configure your wiki as is explained on the virtualization page on xwiki.org * installing the app manager and wiki manager plugins * import the XEM XAR Is that correct Thomas? Maybe we should document this too in the release notes? WDYT? Thanks -Vincent > -----Original Message----- > From: users-bounces(a)xwiki.org [mailto:[email protected]] On > Behalf > Of Vincent Massol > Sent: 20 September 2007 17:03 > To: XWiki Developers; XWiki Users > Subject: [xwiki-users] [ANN] XWiki Enterprise Manager 1.0 Milestone > 1Released > > The XWiki development team is pleased to announce the release of XWiki > Enterprise Manager (XEM) 1.0 Milestone 1. > > XEM is a special wiki (based on XWiki Enterprise) used to manage a > farm > of sub-wikis. It has an interface to create new sub-wikis from > templates, delete wikis, view all created wikis, etc. Basically it's > meant to implement the feature previously known as "Virtual Wikis", > but > as a product and with a UI. > > Features in 1.0M1: > > * XEM install page (XemManager.Install): > o Update XWikiPreferences with all application translations > pages bundled with XEM > o Create the default wiki template based on XE > * All Wiki Manager 1.0 Milestone 1 features: > o Create new empty wiki > o Create new wiki from template wiki > o Create new wiki from XAR file > * All Application Manager 1.0 Milestone 1 features: > o Create new application descriptor > o Delete application descriptor > o Export application based on XWiki Package internal plugin > o Import application based on XWiki Package internal plugin > o Support applications dependencies > o Children wikis can reference documents located in the > template wiki, thus preventing content duplication and easing > maintenance > o Support translations documents > > For more information see the Release notes at: > http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM10M1 > > Thanks > -The XWiki dev team

1 0

[xwiki-devs] [Discussion] New GWT-based WYSIWYG editor
by Marius Dumitru Florea 21 Sep '07

21 Sep '07

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

2 1

[xwiki-devs] [ANN] XWiki Enterprise Manager 1.0 Milestone 1 Released
by Vincent Massol 20 Sep '07

20 Sep '07

The XWiki development team is pleased to announce the release of XWiki Enterprise Manager (XEM) 1.0 Milestone 1. XEM is a special wiki (based on XWiki Enterprise) used to manage a farm of sub-wikis. It has an interface to create new sub-wikis from templates, delete wikis, view all created wikis, etc. Basically it's meant to implement the feature previously known as "Virtual Wikis", but as a product and with a UI. Features in 1.0M1: * XEM install page (XemManager.Install): o Update XWikiPreferences with all application translations pages bundled with XEM o Create the default wiki template based on XE * All Wiki Manager 1.0 Milestone 1 features: o Create new empty wiki o Create new wiki from template wiki o Create new wiki from XAR file * All Application Manager 1.0 Milestone 1 features: o Create new application descriptor o Delete application descriptor o Export application based on XWiki Package internal plugin o Import application based on XWiki Package internal plugin o Support applications dependencies o Children wikis can reference documents located in the template wiki, thus preventing content duplication and easing maintenance o Support translations documents For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM10M1 Thanks -The XWiki dev team

1 0

[xwiki-devs] XWiki Identity Management - Integrating Enterprise Sign On Engine
by Bradley Beddoes 20 Sep '07

20 Sep '07

Hi All, We have a project called the Enterprise Sign On Engine ( http://esoeproject.org ) which is an Apache 2.0 licensed platform for authentication, authorization and accountability for both internal enterprise users and federated contexts. About 4 months ago I talked to some of you on this list and there was some interest in integration, we are now in a position to really try and bring this forward. With ESOE integrated into Xwiki you would automatically get the benefits of using openID and Shibboleth. Xwiki would also get our ability to do true single sign on from Active Directory enabled enterprise clients. We also have a very powerful XACML based authorization engine which allows some really unique flexibility in providing access control to content. All said and done we are trying to provide a clean general purpose solution to identity and federation that can be used across many products without needing to continually reimplement this kind of thing. You don't have to write your own database for every application you create we believe it should and can be the same way with identity. We intend to support further technologies in the future such as Yahoo's BBAuth and Microsofts Identity Card. The really neat thing is that the application side doesn't need to be changed at all when these new options come on board for end users. Please take a look around the website and I would really like to talk further with you guys if there is an interest in doing some work together. regards, Bradley -- Bradley Beddoes Lead Software Architect Intient http://intient.com - "Building intelligent open source solutions for your enterprise"

2 8

[xwiki-devs] [VOTE] Release Application Manager + Wiki Manager plugins and applications
by Vincent Massol 19 Sep '07

19 Sep '07

Hi, Thomas and I would like to release both the Application Manager + Wiki Manager plugins and applications. They are needed for XEM 1.0M1. Preliminary docs: * http://www.xwiki.org/xwiki/bin/view/Code/ApplicationManagerApplication * http://www.xwiki.org/xwiki/bin/view/Code/ApplicationManagerPlugin * No doc yet on the Wiki Manager app and plugin but they are forthcoming for the release. I propose to release them as 1.0M1. Here's my +1 Thanks -Vincent

3 2

[xwiki-devs] [VOTE] Release Tools v1.5
by Vincent Massol 19 Sep '07

19 Sep '07

Hi, For XEM 1.0M1 release we also need to release The Platform Tools v1.5 Here's my +1 Thanks -Vincent

3 2

[xwiki-devs] [VOTE] Promote Thomas Mortagne as a committer
by Vincent Massol 19 Sep '07

19 Sep '07

Hi everyone, I'd like to propose voting Thomas Mortagne as a XWiki committer. He's been sending lots of good patches lately (for the the Core and for XEM) and his patches show a good understanding of how XWiki works. He's also working at full steam on XEM and I'm tired of applying his patches so I propose we let him do it by himself! ;) Here's my +1. Note: For full disclosure, Thomas is working for XPertNet, the company behind the creation of XWiki. FWIW, out of the 23 committers (http://www.xwiki.org/xwiki/bin/view/Community/HallOfFame) 6 are working for XPertNet (including myself). Note that we're running XWiki as a meritocratic project (trying to follow the Apache rules as much as possible) and thus anyone can become a committer (see http:// www.xwiki.org/xwiki/bin/view/Community/Committership) The more the merrier! Thanks -Vincent

8 8

[xwiki-devs] Sorry for the multiple commits for the wiki-manager rename
by Vincent Massol 19 Sep '07

19 Sep '07

I did the refactoring with IDEA and all went fine but when I committed SVN failed so I had to commit bit by bit. I think IDEA's refactoring are not all implemented correctly WRT SVN, i.e. SVN doesn't support several refactorings on top of one another. What a pain... -Vincent

1 0