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

[xwiki-devs] [VOTE] New Model component + move code from core to model
by Vincent Massol 14 Dec '09

14 Dec '09

Hi, Following on the model emails, I'd also like to do the following: * Introduce a new Model component to access the Model objects from the Execution Context (same as we do for other modules to prevent everyone from directly accessing the EC). For now I have: /** * Allows accessing Model Objects for current objects (current document, current wiki, current space, etc) placed in * the Execution Context. * * @version $Id$ * @since 2.2M1 */ @ComponentRole public interface Model { /** * @return the current document located in the Execution Context or null if no current document exist */ DocumentName getCurrentDocumentName(); } I'll also like to add getCurrentWikiName() and getCurrentSpaceName() later on. * Move *DocumentNameSerializer in Model module (currently in xwiki-core) * Move *DocumentNameFactory in Model module (currently in xwiki-core) Here's my +1 Thanks -Vincent PS: FYI here's how I have implemented Model for now: /** * Default implementation bridging to the old XWiki Context to get current Model Objects. * * @version $Id$ * @since 2.2M1 */ @Component public class DefaultModel implements Model { /** * The Execution Context from which we get the old XWiki Context from which we get the current Model Objects. */ @Requirement private Execution execution; /** * {@inheritDoc} * @see org.xwiki.model.Model#getCurrentDocumentName() */ public DocumentName getCurrentDocumentName() { DocumentName result = null; // TODO: This is bridge to the old XWiki Context since we currently don't store the current document in the // new Execution Context yet. Remove when we do so. try { Map<Object, Object> xcontext = (Map<Object, Object>) this.execution.getContext().getProperty("xwikicontext"); Object currentDocument = xcontext.get("doc"); result = (DocumentName) currentDocument .getClass().getMethod("getDocumentName").invoke(currentDocument); } catch (Exception e) { // Shouldn't happen in normal cases. Could happen if the context doesn't contain the old XWiki Context // but that would be a bug in the initialization system somewhere. } return result; } }

2 4

[xwiki-devs] [VOTE] Disable the WYSIWYG sync plugin
by Marius Dumitru Florea 14 Dec '09

14 Dec '09

Hi devs, I'd like to disable the WYSIWYG sync plugin (the one that adds experimental support for real time editing) in the WYSIWYG code till we clean and refactor it. The main reason is to reduce the size of the JavaScript code generated by GWT: 641.3 KB when enabled 545.2 KB when disabled The technical explanation: The sync plugin uses a diff Java library ported by Ludovic to GWT. This library uses the generic Object class in lots of places. Instances of classes defined in this library are passed from the client to the server and back, and so they have to be serialized and deserialized. When fields of Object type or List<Object> or Object[] are deserialized on the client, GWT doesn't know the concrete type and thus generates JavaScript code to handle every possibility (i.e. all classes implementing IsSerializable tag interface). This increases a lot the size of the JavaScript code. Here's the warning we get during GWT compilation: http://pastebin.com/m61aa381f mainly: [WARN] In order to produce smaller client-side code, 'Object' is not allowed; consider using a more specific type To disable the WYSIWYG syntax plugin I have to comment one line of code: // WysiwygEditorFactory.java pfm.addPluginFactory(SyncPluginFactory.getInstance()); and to remove an import. GWT compiles to JavaScript only the code that is really used. Here's my +1 Thanks, Marius

8 12

[xwiki-devs] [Code Review] Wiki Macro
by Vincent Massol 12 Dec '09

12 Dec '09

Hi Asiri, This is mostly for you but sending here for others to see and comment if they want. While working on adding support for wiki macro visibility I have found the following issues in the existing wiki macro code: 1) Usage of String for document names instead of DocumentName class. I've fixed this. 2) Printing logs in all methods instead of sending exceptions on errors. I've fixed this too. 3) Bad test strategy for testing DefaultWikiMacro. It's not needed to use RenderingTests with test files. I've fixed this. 4) Missing several tests in DefaultWikiMacro. I have not fixed this. 5) Bad strategy for providing user feedback on macro registration. I believe we shouldn't implement registration as an event listener and instead have a Wiki Macro management page with register/unregister buttons and when clicked the result is printed on the page. This should probably be done as a replacement of the WikiMacros page in the wiki macro bridge application. WDYT? I've not fixed this. 6) Programming rights required to access macro params. I have not fixed this. 7) There was a bug with parameter ordering I have fixed a few weeks ago but I'm mentionning it here for completeness. 8) Context restoration in DefaultWikiMacro. It's currently not in a finally block and thus it's possible it's not restored if there are exceptions raised. I have not fixed this. 9) Missing some comments for complex code portions. For ex in DefaultWikiMacro for the inline macro stuff. I have not fixed this. 10) Systematic setting of null values not required in lots of place. I have fixed all I saw. 11) DefaultWikiMacro only executes Macro Transformations but not other Transformations. I think this is a problem. I have not fixed this. 12) Several classes had full javadoc but the checkstyle config wasn't set in the POM, thus allowing checkstyle errors to creep in unnoticed. I have only partially fixed this. Please check all classes that can be added and fix the few that still have errors. 13) Missing tests for the Event Listener but because of 5) I haven't added them. 14) Missing at least one functional test to prove everything works. Thanks -Vincent

2 1

[xwiki-devs] [VOTE] Add DAB.getCurrentWiki()
by Vincent Massol 11 Dec '09

11 Dec '09

Hi, I have the need to get the current wiki (which is different from the wiki defined in the current doc for my use case). I'd like to add a DAB.getCurrentWiki(). Here's my +1 Thanks -Vincent

3 4

[xwiki-devs] [VOTE] Add DAB.isDocumentEditable(DocumentName documentName) and deprecate signature with String
by Vincent Massol 11 Dec '09

11 Dec '09

Hi, I'd like to add: boolean isDocumentEditable(DocumentName documentName); And deprecate: boolean isDocumentEditable(String documentName); Here's my +1 Thanks -Vincent

6 5

[xwiki-devs] [myxwiki] XWiki Enterprise 2.1 Upgrade
by Jean-Vincent Drean 10 Dec '09

10 Dec '09

Hello, myxwiki.org has been upgraded to XE 2.1, if you own a wiki hosted there you should have a look at : http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise21 We also strongly recommend an upgrade to the latest wiki version. To upgrade you must download XE 2.1 XWiki XAR from : http://www.xwiki.org/xwiki/bin/view/Main/Download And follow the upgrade guide available at : http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation#HUpgrading… To be notified of the myxwiki.org server upgrade you can follow myxwiki on twitter: http://twitter.com/myxwiki Thanks, JV.

1 0

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 2.0.5 Released
by Thomas Mortagne 09 Dec '09

09 Dec '09

The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 2.0.5. This is the last bug fix and enhancement release for 2.0 branch. It contains several important bugfixes like support of non ASCII character in Go to, Search and Document Index or proper UTF8 support when creating a sub wiki. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise205 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM205 Thanks -The XWiki dev team

1 0

[xwiki-devs] [VOTE] Release XE/XEM 2.0.5 and remove 2.0 branches
by Thomas Mortagne 09 Dec '09

09 Dec '09

Hi devs, I would like to end 2.0 cycle with the 2.0.5. You can look at http://jira.xwiki.org/jira/browse/XWIKI?report=com.atlassian.jira.plugin.sy… for the list of issues closed for this release. Here is my +1 -- Thomas Mortagne

5 6

Re: [xwiki-devs] [xwiki-notifications] r25712 - in platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki-rendering-api/src: main/java/org/xwiki/rendering/internal/renderer test/java/org/xwiki/rendering/internal/renderer/plain
by Sergiu Dumitriu 09 Dec '09

09 Dec '09

On 12/09/2009 04:23 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-12-09 04:23:01 +0100 (Wed, 09 Dec 2009) > New Revision: 25712 > > Modified: > platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/BasicLinkRenderer.java > platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki-rendering-api/src/test/java/org/xwiki/rendering/internal/renderer/plain/PlainTextChainingRendererTest.java > Log: > [misc] Adding svn keywords > > Modified: platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki-rendering-api/src/test/java/org/xwiki/rendering/internal/renderer/plain/PlainTextChainingRendererTest.java > =================================================================== > --- platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki-rendering-api/src/test/java/org/xwiki/rendering/internal/renderer/plain/PlainTextChainingRendererTest.java 2009-12-09 02:18:55 UTC (rev 25711) > +++ platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki-rendering-api/src/test/java/org/xwiki/rendering/internal/renderer/plain/PlainTextChainingRendererTest.java 2009-12-09 03:23:01 UTC (rev 25712) > @@ -31,7 +31,7 @@ > /** > * Unit tests for {@link PlainTextChainingRenderer} that cannot easily be performed using the Renderng Test framework. > * > - * @version $Id: PlainTextChainingRendererTest.java 24898 2009-11-06 12:58:22Z sdumitriu $ > + * @version $Id$ Why is there a "since 2.1M1" message on the 2.0 branch? > * @since 2.1M1 > */ > public class PlainTextChainingRendererTest extends AbstractComponentTestCase -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 1

[xwiki-devs] [Proposal] Wiki macros improvement ideas
by Vincent Massol 09 Dec '09

09 Dec '09

Hi, Wiki macros currently require programming rights and thus are limited and in addition cannot be created in subwikis by the majority of users. Since I've now almost finished implementing component isolation I'd like to agree on what we want for wiki macros. Proposal: * Modify the wiki macro class to add a "Visibility" field with 2 values: - visible only in the current wiki - visible to everyone * Visible to everyone will require admin rights * Make the macro available to a user only if that user has view rights to the wiki macro page. This is to allow making a wiki macro private (when testing for example). It also allows making a macro visible only to a given group of users. Note: I considered having a "visible only to the current user" value for the Visibility field but I don't think it means much since if someone else edit the page and saves it, then suddenly the macro becomes visible only to that person... WDYT? Thanks -Vincent

2 5