xwiki-devs October 2012

xwiki-devs@xwiki.org

29 participants
67 discussions

[xwiki-devs] [Contrib] I'd like to move xwiki realtime editor to xwiki-contrib

by Caleb James DeLisle

Hi, Since I've got the realtime editor in a working state and it's hosted as an extension, I'd like to move it to xwiki-contrib so we can take advantage of the jira project and not have issues lost in githubland. WDYT? Thanks, Caleb

12 years, 1 month

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 4.3-milestone-1 released.

by Fabio Mancinelli

The XWiki development team is proud to announce the availability of XWiki Enterprise 4.3-milestone-1. This release brings several improvements in Workspaces, Extension Manager, Distribution Wizard and the REST API. It is now possible to activate the multiwiki feature when using the HSQLDB database (i.e., in the standalone version of XWiki Enterprise). Several important fixes for bugs related to importing Office Documents while using filesystem attachments have also been included. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… Thanks -The XWiki dev team

12 years, 1 month

[xwiki-devs] New localization module

by Thomas Mortagne

Hi devs, I started recently to refactor the localization module Sergiu had started. You can look at the current status in the branch https://github.com/xwiki/xwiki-platform/tree/feature-localization. Nothing is working yet but I wrote enough APIs to see a bit more clear on what I'm up to so here it is. This mail is mostly to discuss the general architecture. There will be other more detailed mails for voting class name and things like that. = Get a translation = * here is the main client API: the client ask for a Translation object to LocalizationManager by indicating it's key (String) and locale (java.util.Locale). Then it calls Translation#render() with optional parameters to get a rendering Block as result. This Block is then inserted in the main XDOM using the translation macro or rendered as text by XWikiMessageTools#get() and other APIs like that if there is = Provide new translations = * support "injecting" new translations just by "marking" pages containing translation using an object to not have to list them in XWikiPreferences anymore. This is especially required for extensions. * the same way I think we should be able to provide translation in a jar extension * on idea introduce by Sergiu and that I agree with is the fact that like with ssx/jsx we need to be able to pull a specific translation explicitly without it to be automatically registered for the whole wiki or something like this * LocalizationManager (and more specifically BundleContext) find the right translations bundles to look at by lokuping all the org.xwiki.localization.Bundle components depending of the context (component can be registered for specific wikis/users). = Translation message syntaxes = * translation message syntax: the current syntax of our translations is a MessageTool based syntax depending on the fact that your have custom parameters or not. This syntax is not very good IMO (managing ' char is a mess) but good or not I think we need to have the possibility to introduce new features (like variables, light formating syntax, etc.) whenever we needs it without breaking anything and the way to do it is by having the possibility to have translation resources in different syntaxes and associated parsers. Note that TranslationMessage does not appear anywhere in the Translation API, any Bundle can implement Translation the way it want but we will have a lot of Bundle on our side using this concept of translation message syntax. The main target is wiki translations. Not all that is going to ends up in 4.3 but the goal is to have at least the new architecture support the "old" ApplicationResources resource and XWikiPreferences static translations pages and start introduce dynamically registered wiki translations. Shoot ! -- Thomas Mortagne

12 years, 1 month

[xwiki-devs] New Realtime collaborative editing extension.

by Caleb James DeLisle

Hi guys, I just finished repackaging the realtime collaborative editor which was developed as part of wiki/3.0. It is now installable as an extension. It's still a bit rough around the edges but it's pretty safe to play with so everyone is invited to give it a try. * Multiple users can edit the same document at the same time and their changes are merged in real time. * The "RealTime Wiki" editor is an option along side WYSIWYG and Wiki so it won't break existing editors. * Easy installation by copying a .jar file and importing a .xar file, removal is simply deleting 2 XDocuments. http://extensions.xwiki.org/xwiki/bin/view/Extension/RealTime+Wiki+Editor Please feel free to share your experiences in the mailing list, on the extension wiki page and on the github bug tracker. Thanks, Caleb

12 years, 2 months

[xwiki-devs] [Proposal] Define XClass property types using components

by Marius Dumitru Florea

Hi devs, Currently, the available XClass property types are hard-coded in MetaClass [1]. So in order to add a new property type you need to recompile the XWiki old core. I'd like to be able to create new property types using components so I created this branch [2] that includes the following important changes: (A) Use the value of the "classType" XML element from the XAR as a property type hint If you look at the XML export of an XClass you'll see that each property has a "classType" element whose content is the full name of the Java class used to implement that property type: <classType>com.xpn.xwiki.objects.classes.DBTreeListClass</classType> I think this is bad because: * it exposes an implementation detail * you cannot change the property type implementation without breaking backwards compatibility So I'm proposing to use the "classType" as a hint for the property type. Well, technically it will be a hint, but semantically it will specify the data type of the property value (e.g. String, Date, Number). For backwards compatibility, the existing property types will have hints that can be extracted from the value of the 'classType' (i.e. the full Java class name): String hint = StringUtils.removeEnd(StringUtils.substringAfterLast(classType, "."), "Class"); So both: <classType>com.xpn.xwiki.objects.classes.DBTreeListClass</classType> <classType>DBTreeList</classType> will point to the property type with hint "DBTreeList". Of course, when exporting an XClass with the new version of the core you'll only see the property type hint. The only issue with this approach is that XClasses exported with the new version will not work on an older version but this is acceptable IMO. (B) Add a PropertyClassProvider [3] role to retrieve an instance of a property class and to access its meta class Currently, in order to define a new property type you need to create two Java classes: * one extending PropertyMetaClass, to define the list of meta properties of the new property type (e.g. displayType, dateFormat, multiSelect, etc.) * one extending ProperyClass, to define setters and getters for the meta properties and maybe some custom display. This is the property type itself. So I added a PropertyClassProvider role that has two methods: one to get the meta class and one to get a new instance of the property type (e.g. when adding a property to an XClass). As a quick implementation I transformed all meta classes into implementations of this role. Finally, I modified MetaClass to lookup property class providers instead of hard-coding the property types. WDYT? Note that I've not added any CLIRR excludes and I tested my changes with the default, unchanged, class editor and it works fine. Thanks, Marius [1] https://github.com/xwiki/xwiki-platform/blob/xwiki-platform-4.2/xwiki-platf… [2] https://github.com/xwiki/xwiki-platform/compare/feature-xclass-property-com… [3] https://github.com/xwiki/xwiki-platform/commit/fb9fcc7313ccb16f38c2d17dd7ed…

12 years, 2 months

[xwiki-devs] New fine-grained way to ignore CLIRR violations

by Vincent Massol

Hi guys, I've committed http://jira.xwiki.org/browse/XCOMMONS-283 which allows us to very precisely exclude CLIRR violations. See http://mojo.codehaus.org/clirr-maven-plugin/examples/ignored-differences.ht… for details. For example I've just added an IRCBot exclude using this with: <ignored> <difference> <className>org/xwiki/ircbot/IRCBot</className> <method>void initialize(java.lang.String)</method> <differenceType>7012</differenceType> <justification>IRCBot is still a young API. Added a new initialize() method to support installing the IRC Bot application in a subwiki</justification> </difference> </ignored> Now could every one who's added a clirr exclude please convert to the new way? This allows us to have fine-grained excludes and not exclude the whole file. Thanks -Vincent

12 years, 2 months

[xwiki-devs] Where to define new property types? Java vs. Wiki

by Marius Dumitru Florea

Hi devs, I'd like to extend the set of property types available in the AWM class editor (the field palette) and I'm not sure where is the best place to do this: in the Java code (oldcore) or in the wiki. I prefer the wiki. Let me explain. We recently added two new property types in the oldcore: email and page. If you look at these two you'll see that email is just a string property with a default validation regexp and page is just a dblist property. The AWM class editor has a system that lets you define property 'templates' in the wiki. To define the email property type I could do this: * create AppWithinMinutes.Email xclass with a single String property (the 'template') * set the validation regexp to match an email address (but I can set other meta properties as well with *default* values) * add an object of type AppWithinMinutes.FormFieldClass to AppWithinMinutes.Email to specify (among other things) the list of meta properties that should be visible in the class editor. For instance, I'd like to hide the validation regexp. At this point the AWM class editor will detect the email property type and list it in the field palette and you can add it to your class. The only problem is that when editing the class back the editor doesn't have yet a way to determine what was the template used to add the property so it uses the default one, the one for the String property in this case. So my question is: do you think it's good to be able to define new property types from the wiki (e.g. Image, Attachment, Color, etc.) or should they all be written in Java? If the answer is Wiki, then I'll think of a way to store the reference to the property template so that the AWM class editor can edit back using the right template. Note that it crossed my mind to define a property type component that can be implemented both from Java and from the wiki but transforming the oldcore code that handles objects/properties into components is very difficult. Thanks, Marius

12 years, 2 months

[xwiki-devs] Build is unstable again....

by Vincent Massol

Devs, We're receiving tons of build failures every day again …. :( Coud all devs please help in fixing the build so that we can again have a passing build and fix flickering tests? Thanks -Vincent

12 years, 2 months

[xwiki-devs] [Contrib] xwiki-enterprise-vagrant

by Sorin Burjan

Hi devs, As part of the Hackathon 2012, I started working no a maven module to create VM' provisioned with XWiki.The module is somehow in its early stages, It needs polishing. In order to make the code public for others to see it and help polish it, I would like to have a xwiki-contrib project for this. project name: xwiki-enterprise-vagrant username: sorinello Regards, Sorin B.

12 years, 2 months

[xwiki-devs] Quality Profile now enabled in CI for XWiki Commons

by Vincent Massol

Hi devs, As previously agreed (see http://markmail.org/thread/j5yuaxixbyvytfr3), I've now configured all commons module to have proper TPC % values to make the build pass. I've also configured a Jenkins job that'll run once per day at midnight and send us an email if some module fails to pass the TPC check. When this happens it means some dev will have committed during the day code without enough test and he would have globally lowered the quality of the project for the module(s) where he committed. Even if he committed some functional tests to compensate he'll still need to write some more unit tests to make the TPC check pass again. http://ci.xwiki.org/view/Commons/job/xwiki-commons%20Quality%20Checks/ Next step is to do the same for Rendering and the Platform. I'll work on that. Thanks -Vincent

12 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2012