February 2015 - xwiki-devs@xwiki.org

[xwiki-devs] [Idea] Page Administration
by Ecaterina Moraru (Valica) 19 Nov '15

19 Nov '15

Hi devs, So this proposal appeared in some of my proposals but right now I created a proper Proposal/Idea mail for it. It's about having an 'Administer Page' section in the menus, similar to the 'Administer Wiki' and 'Administer Space' functionality. The 'Administer Page' will be accessible to global admins, page creators and users with (edit?/admin?) rights for the page. >From what we currently have implemented it should contain the 'Rights Editor' (?editor=rights) at page level. In the future we could make 'Presentation', 'Page Elements' or 'Panel Wizard' to be more granular and be set at Page level (have different panels and style for just one page). Some screenshots at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/PageAdministration Thanks, Caty

5 9

[xwiki-devs] [UX][Consistency][Vote] "Page" vs. "Document" consistent naming
by Ecaterina Moraru (Valica) 09 Sep '15

09 Sep '15

Hi, We are using mixed naming when referring to a document/page, not only on different pages, but also in the same context (Rename step for example). There is also an issue referring to this problem XWIKI-5401<http://jira.xwiki.org/jira/browse/XWIKI-5401>and we need to find an answer in order to move forward consistency. So the question is which version we prefer: "Page" or "Document" ? I'm voting +1 for "Page". "Page" is more used IMO, especially in the "Space"/"Page" context. "Page" is more general than "Document" and better fitted for a platform that encapsulates all kind of content (not just documents). Please cast your vote. Thanks, Caty

10 14

[xwiki-devs] [Proposal] Object addition/removal/update shouldn't change content author
by Vincent Massol 23 Jun '15

23 Jun '15

Hi, According to the javadoc in XWikiDocument: /** * The last user that has changed the document's content (ie not object, attachments). The Content author is only * changed when the document content changes. Note that Content Author is used to check programming rights on a * document and this is the reason we need to know the last author who's modified the content since programming * rights depend on this. */ private DocumentReference contentAuthorReference; This means that objectadd or objectremove actions shouldn't change the content author as they do now. I'm proposing that we fix this. Do you see any issue? Thanks -Vincent

7 11

[xwiki-devs] [Idea] Extensible API for accessing structured data
by Fabio Mancinelli 07 May '15

07 May '15

Hi all, some time ago we wrote about an idea of having an extensible API for accessing structured data. The final goal is to have a uniform API for accessing structured data both on the client (Javascript+REST) and on the server. We have written a little design document that I am submitting to the list for comments: http://design.xwiki.org/xwiki/bin/view/Proposal/ExtensibleAPIforaccessingst… This idea is also related to other ones, like providing a way for dynamically extending the REST API, and also to the integration with client side frameworks like AngularJS. Thanks, Fabio

4 9

[xwiki-devs] [Proposal] Automatic creation of objects with HTTP parameters
by Jean SIMARD 01 Apr '15

01 Apr '15

Hi devs, In XWiki, if you send a POST request at the following URL ('MySpace.MyPage' is a document that doesn't exist at the moment) /bin/save/MySpace/MyPage with the following HTTP parameters: * template=MySpace.MyTemplate * XWiki.XWikiRights_0_users=XWiki.Me * <others parameters> with 'MySpace.MyTemplate' a template document and 'XWiki.Me' a user of the wiki. 2 cases: 1. If 'MySpace.MyTemplate' contains a 'XWiki.XWikiRights' object, then the resulting document 'MySpace.MyPage' will have this object with its property 'users' initialize with the value 'XWiki.Me' (see HTTP parameters) 2. If 'MySpace.MyTemplate' does not contain a 'XWiki.XWikiRights' object, the resulting document 'MySpace.MyPage' will not contain it either ### PROPOSAL Create automatically the objects if they don't exist in the template document. ### To make it possible, it seems that we would need to refactor the method 'readObjectsFromForm(EditForm, XWikiContext)' in the 'com.xpn.xwiki.doc.XWikiDocument' class. And probably modify also the 'getObject(String)' from 'com.xpn.xwiki.web.EditForm' class. 2 things to take care: * It seems there is no unit test for these methods. * May this proposal be a security problem? WDYT? -- Jean

7 10

[xwiki-devs] Migration Manager Subsystems
by Marc Sladek 23 Mar '15

23 Mar '15

Dear XWiki devs Within the scope of our XWiki-based project called celements, we are using several so-called "modules", which consist of JARs, web resources (VM/CSS/JS files) and hibernate mappings. These modules extend the functionality of the base application and can be optionally added if required. We need to update and migrate these modules independently from XWiki. Therefore we require to store individual migration version numbers in the database for each module. XWiki's single implementation of DataMigrationManager, HibernateDataMigrationManager, isn't intended to store multiple version numbers with specific identifiers in the database. There also doesn't seem to be an evident hook from XWiki to seamlessly add own implementations of the DataMigrationManager to the application to allow migration subsystems. Considering the similarities of XWiki extensions to our modules, is there already a way that we have missed to achieve independent migrations of our modules? If not, are there any future plans from XWiki's side to add this functionality? Thanks in advance Marc Sladek synventis gmbh

3 3

[xwiki-devs] GSCO: Interested in project Javascript and AngularJS XWiki API
by kiran ps 07 Mar '15

07 Mar '15

Hi, I'm an Engineering student(computer science) pursuing my degree from Government Engineering College(Calicut University), Thrissur, India. I went through xwiki gsoc idea list.I'm interested in the project JavaScript and AngularJS XWiki API. I have good skills in JavaScript, nodejs, angular. I am looking forward for a good response from your side regarding details about the projects so that I could start contributing towards it. Skills: Languages: JavaScript, nodejs, python, HTML5, CSS3, C, C++ Libraries: jQuery, underscorejs, zeptojs, KineticJS Frameworks: Angularjs, Express, Django, Tools: Vim, Git, Grunt, bower, Yeoman Thank you, { name: "Kiran P S", email: "pskirann(a)gmail.com", github: "github.com/kiranps", google+: "plus.google.com/+kiranps1", twitter: "@pskirann" }

2 1

[xwiki-devs] [Proposal] Split XE pages into platform modules
by Vincent Massol 06 Mar '15

06 Mar '15

Hi devs, Here's a proposal to move pages currently located in XE into platform modules: * ColorThemes/*.xml --> xwiki-platform-colorthemes * Main/Activity.xml --> xwiki-platform-activitystream-ui (move current xwiki-platform-activitytream into xwiki-platform-activitystream-api) * Main/AllDocs.xml (and XWiki.Tableview, XWiki.Treeview, XWiki.OrphanedPages, XWiki.AllAttachments*, XWiki.DeletedDocuments, XWiki.DeletedAttachments and all pages used by those) --> new xwiki-platform-navigation module * Main/RssFeeds.xml --> new xwiki-platform-help module or xwiki-platform-rss-ui module (see below) * Main/SpaceIndex.xml --> xwiki-platform-navigation * Main/Spaces.xml --> xwiki-platform-navigation * Main/UserDirectory.xml --> xwiki-platform-user-ui * Main/WebHome.xml --> xwiki-platform-dashboard-ui * Main/WebRss.xml --> new xwiki-platform-rss-ui module, we would create a xwiki-platform-rss-api module too where we will move the feed plugin * Main/Welcome.xml --> move to xwiki-platform-dashboard-ui since it's a dashboard gadget which we could consider as a default widget * Sandbox/*.xml --> xwiki-platform-sandbox module (or xwiki-platform-help module) * XWiki/XWikSyntax.xml --> xwiki-platform-help module * XWiki/AttachmentSelector.xml --> xwiki-platform-user-ui or new xwiki-platform-attachmentselector module * XWiki/ClassSheet, ClassTemplate, ObjectSheet, XWikiClasses, * XWiki/GadgetClass.xml --> xwiki-platform-dashboard-ui * XWiki/LiveTableResult*.xml --> new xwiki-platform-livetable module * XWiki/MessageStreamConfig.xml --> new xwiki-platform-messagestream-ui module (and move xwiki-platform-message in xwiki-platform-message-api module) * XWiki/RequestsStatus.xml --> xwiki-platform-administration module or remove from platform till we integrate it in the Admin as an admin tool somewhere since right now I think it's available in the Admin tools application * XWiki/RequiredRightClass.xml --> since it's used in lots of other ui modules I'd propose to move it in java code as a class created on startup. Alternatively start creating a xwiki-platform-rights-ui module (or xwiki-platform-permission-ui module) and move it there * XWiki/SharePage.xml --> not sure…. maybe in a xwiki-platform-share or xwiki-platform-sharepage module * XWiki/TemplateProvider*.xml --> xwiki-platform-administration for the moment * XWiki/WebHome.xml --> xwiki-platform-administration module * XWiki/WebPreferences.xml --> xwiki-platform-administration module WDYT? Please try to tell me if you're ok for each line if you have time ;) Thanks -Vincent

8 20

[xwiki-devs] [Proposal] Using Less4j by default in XWiki
by Guillaume "Louis-Marie" Delhumeau 05 Mar '15

05 Mar '15

Hi developers. I have recently implemented the ability to use LESS in SSX: http://jira.xwiki.org/browse/XWIKI-10708. This feature has pointed me out some bugs, that are reported upstream: https://github.com/less/less.js/issues/1878 https://github.com/less/less.js/issues/1968 I have tried to implement a workaround, but as a result, it is preventing us to use an important feature of LESS: .extend(). And it simply breaks the Caty work on the Menu Application. Moreover, LESS has been rewritten in version 2. But because of this refactoring, the Rhino version does not work. See: https://github.com/less/less.js/issues/2316 So we are stuck with the current version of LESS, with the bugs listed above (that I am not able to patch). But in parallel, I have worked to use LESS4j instead of the official LESS project (http://jira.xwiki.org/browse/XWIKI-11034) And today, I finally managed to make it work! The good news is that LESS4j does not have the bugs that are blocking us. I propose to commit this for 6.4M2 (before tomorrow), and we can still revert it afterwards. Advantages of LESS4j: * should be quicker (see: https://github.com/xwiki-contrib/less-vs-sass-benchmark) * does not have the bugs listed above * we can hope that the version 2 will be ported to LESS4j too. Drawbacks of LESS4j: * maintained by only one developer (but reactive when I report bugs) * not exactly the same behaviour than LESS: https://github.com/SomMeri/less4j/wiki/Differences-Between-Less.js-and-Less… * maybe the error messages are less kindly than lessjs ones. My implementation is configurable: an administrator can decide to use the LESS official version by changing a property in xwiki.properties. I just propose to have LESS4j by default. Here is my +1. Thanks, -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 10

[xwiki-devs] [VOTE] New Translation property naming rules
by vincent＠massol.net 05 Mar '15

05 Mar '15

Hi devs, At the moment the VOTED rule for naming our translation properties is the one defined at http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTransla… Back in 2012 Sergiu started drafting an extended "L10N Conventions” document for best practices around writing translation properties at http://dev.xwiki.org/xwiki/bin/view/Drafts/L10N+Conventions Sergiu sent this a proposal in this mail thread: http://markmail.org/message/ofl23yorvxsqhn4x When Sergiu did this he didn’t realize we already had a VOTED rule for naming our translation properties and his proposal was in conflit with that. However, in this mail thread, several developers mentioned that even though they votes the previous naming rules they didn’t fully like it and preferred the one Sergiu was proposing. Several suggestion for improvements were also proposed. It was suggested in that thread (and Sergiu agreed) that he should resend a VOTE to change those established rules. Apparently he didn’t get the time/will to do it since I couldn’t find such a mail. In addition several developers are apparently not following the current rules (BAD! :)). For example in the xwiki-platform-icon-ui module, the Translations.xml page has the following which is NOT following the current rules: platform.icon.picker.preview=Preview with: platform.icon.picker.loading=Loading And most translation keys found in contrib apps at http://l10n.xwiki.org/xwiki/bin/view/Contrib/WebHome are also not following these rules (although we don’t enforce anything for contrib projects, when they are coded by devs from the XWiki dev team or by known contributors, it would be a good thing to follow the same rule, especially as, in the future, we want to provide a path to move from contrib sandbox to contrib extensions). For example I see the following type of naming: “polls.vote.instructions.single”. Thus, with this email I’d like to try agreeing on a new naming format and conventions. I propose to VOTE for making http://dev.xwiki.org/xwiki/bin/view/Drafts/L10N+Conventions our official practice with the following change for the property naming part: " Keys should have the following format: ##[module]*[.section]*.element[.part]*##, where: * ##module## is the name of the module or application being translated, like ##blog##, ##faq##, ##statistics##… Since a module can have submodules, there can be several module names. For example the SOLR Search UI is located in ##xwiki-platform-search/xwiki-platform-solr/xwiki-platform-solr-ui## and would have keys starting with ##search.solr.##. * zero, one or more ##section## parts that further refine the location of the string being translated; for example, a key starting with ##theme.colors.wizard.## refers to a text located in the //wizard// for the //color// part of the //theme// application (currently there are only color themes, but in the future we might add icon themes, layout themes, and so on), ##macro.python.parameter.## refers to //parameters// of the //python// //macro//, while a key starting with ##userdirectory.## belongs to the main and only section of the //user directory// application * ##element## identifies the main element being translated, but such an element could have several related parts. * ##part## identifies a text related to a main element, such as the ##label## that describes an input, the ##placeholder## found inside that input, the ##tooltip## that appears when hovering that input, the ##hint## that is displayed before the field and provides additional details about what it, the ##error.empty## or ##error.invalidFormat## displayed when there are validation errors, and so on Individual parts of the key should use **camelCase** if more than one word is needed to identify the element. “ Note that I’ve removed the ##product## part from Sergiu’s proposal (the reasoning is here: http://markmail.org/message/ocijlegslw45yedu) In short this makes it simpler to move apps around without breaking the translation keys. Of course it reduces the namespace and increases likelihood of translation clashes with user-provided extensions but I don’t think it’s going to be a problem and user-provided extensions should have a unique app name anyway. I would also point to http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTransla… for the deprecation part. The big question is what to do with existing translations and the only answer I have so far is: * Use the new rules when adding new translation keys (after, and if, it’s voted) * Don’t touch existing keys for now (since that would loose all translations) but implement the following first, and once it’s done, refactor existing translations over time: ** Add support for a deprecation section in Translations.xml’s content, honoured by l10n in the same way that we do it for ApplicationResources.properties ** Add the new key ** Move the old key to the deprecation section (in ApplicationResources.properties or in Translations.xml) ** Make the old key point to the new key, using a special syntax. For example: my.old.deprecated.key = @{new.shiny.key} Here’s my +1 Thanks -Vincent

6 10