September 2007 - xwiki-devs@xwiki.org

[xwiki-devs] [Proposal] XE 1.2 Roadmap
by Vincent Massol 25 Sep '07

25 Sep '07

Hi everyone, We need to start defining the content of XE 1.2 and the time frame. Looking at http://www.xwiki.org/xwiki/bin/view/Idea/FeaturesFor11 we can see that there are a lot of leftovers. Content ======= I propose the following content for 1.2: * Priority 1: bug fixing. We have even more bugs in jira than before we started 1.1 (unless I'm mistaken). In platform only we have about 171 bugs listed. There were 108 when we started 1.1. * Priority 2: Cleaning up - cleaning up skins - cleaning up XE into separate applications (Blogs, Search, etc) - cleaning up resource files (and implementing the mechanism defined on the list for application resources) - cleaning up JS libraries * Priority 2: New rights UI * Priority 3: Other features - Scheduler plugin to finish (note that now that this plugin is outside XE it can be worked on in a different lifecycle) - Notification and mail plugins (same comment as for the scheduler plugin) - Anything that helps navigation and usability of XE Note: We already have important changes in 1.2 trunk (recycle bin, new history table, etc) which alone would warrant a release so we don't need to add many more features. This is also why I think we should focus on making these work properly with nice UIs and fix existing bugs rather than try to cram more features. The only exception is the new Rights UI which we badly need. We also badly need Mail/Notification plugin. Milestones ========= I propose to release a 1.2 final version before Javapolis, which starts on the 10th of December. We'll be present there so I think it would be very good if we came with a new version ready. Thus I propose the following schedule: 1.2M1: 1st of October 1.2M2: 15th of October 1.2M3: 29th of October 1.2RC1: 12th of November 1.2RC2: 19th of November 1.2 final: 26th of November This gives us an error margin of about 15 working days (more with week ends ;)) for making it to Javapolis, which I think is good enough. We just need to be careful to do time boxing properly and release the milestones on agreed dates. WDYT? Thanks -Vincent

3 3

[xwiki-devs] Rights Management API
by Evelyne24 24 Sep '07

24 Sep '07

Hello, In order to implement the Rights Management desired improvements, we concluded that there is need to write an api to help retrieve: - the local / global users - the local / global groups - the inherited rights for users / groups So after I spoke with Ludovic and Thomas, here is the list of things to be implemented in this api: XWikiUser ============ We have: -> user (string) -> main (boolean) --> setUser, getUser --> isMain, setMain ---------------------------- We will need to do: --> add methods: * getAllActiveUsers [ will read xwiki settings to know what to return, global or local active users; Thomas and I understood that 'active' user means the user after being registered and confirmed the registration through email maybe, following a link to activate or something like this ] * getAllGlobalUsers * getAllLocalUsers * getAllUsers * getMatchingActiveUsers(string MatchText, XWikiContext) * a method to get details for a user, other than the ones returned by getAllUsers (which will return something like Xwiki.LudovicDubost); we might need firstname, lastname, pagename etc. maybe we can use a parameter for the getAllUsers method, called 'withDetails'(boolean) XWikiGroupService (interface) ============================= We have --> listGroupsForUser --> addUserToGroup --> listMemberForGroup --> listAllGroups ------------------------- We will need to do: --> add methods: * getAllActiveGroups * getAllGlobalGroups * getAllLocalGroups [ this is currently done by 'listAllGroups' ] * listMatchingActiveGroups(string MatchText, XWikiContext) [ this will help me for the ajax-suggest feature; will return the groups with the name matching a certain string ] XWikiRightService (interface) ============================== We have: --> checkAccess --> hasAccessLevel --> hasProgrammingRights (2 methods) --> hasAdminRights --> listAllLevels ------------------------------- We will need to do: --> add methods: * to find inherited rights * and maybe other things, I'm not very sure yet I hope I understood right. Thomas will try to draw some schemes and I'll clarify some of the questions that are left, then. Ps. I posted this mail yesterday but only today I found out that devs list moved to xwiki.org. Sorry about the delay.

4 5

[xwiki-devs] [VOTE] Modify XWiki.search() returned result + other methods returning a collection
by Vincent Massol 22 Sep '07

22 Sep '07

Hi, Since this is an API I'm sending a vote. I'd like to modify the following: public List search(String wheresql) throws XWikiException { if (hasProgrammingRights()) return xwiki.search(wheresql, getXWikiContext()); return null; } To: public List search(String wheresql) throws XWikiException { if (hasProgrammingRights()) return xwiki.search(wheresql, getXWikiContext()); return Collections.EMPTY_LIST; } Rationale: * A method that returns a List (or a Collection in general) should never return null but always an empty collection instead (or throw an exception). I also propose to modify the other methods to return empty collections instead of null. Those include: * public List getDeletedDocuments(String fullname, String lang) throws XWikiException * public List search(String wheresql, int nb, int start) throws XWikiException * public List searchDocuments(String wheresql, int nb, int start, String selectColumns) Here's my +1 Thanks -Vincent

5 6

[xwiki-devs] [ObjectWeb Forge Could Not Connect to Database:]
by bernaulli 22 Sep '07

22 Sep '07

Hi I am not able to download xwiki because of following error. Arvind

1 0

[xwiki-devs] Fwd: New date for XEclipse 10.M2?
by Asiri Rathnayake 22 Sep '07

22 Sep '07

Should have hit the reply-to-all button :) ---------- Forwarded message ---------- From: Asiri Rathnayake <asiri.rathnayake(a)gmail.com> Date: Sep 14, 2007 9:21 AM Subject: Re: New date for XEclipse 10.M2? To: Vincent Massol <vincent(a)massol.net> Hi Vincent, On 9/14/07, Vincent Massol <vincent(a)massol.net> wrote: > > Hi Asiri/Tharindu, > > I'd like to set a new target date for the XEclipse 1.0M2 release so > that we have an objective. > > Could you please tell me what date would be reasonable, taking into > account your studies and such? Will 8th of October be enough ? Thanks. - Asiri Thanks > -Vincent > >

3 3

[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