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

[xwiki-devs] HK2 DI framework
by Vincent Massol 20 Feb '17

20 Feb '17

Hi devs, While researching whether we could use CDI for XWiki (see https://issues.jboss.org/browse/CDI-114) I was pointed to HK2 (https://hk2.java.net/2.5.0-b34/) I’ve quickly started to read about it and it really looks very similar to our Component Manager. See for example the introduction at https://hk2.java.net/2.5.0-b34/introduction.html I still need to read more about it but I thought I’d share this with you. Thanks -Vincent

1 0

[xwiki-devs] [XWiki Day] Test Day #2
by Thomas Mortagne 20 Feb '17

20 Feb '17

Hi devs, The idea today is to do a Test Day with priority to fixing long standing flickering (integration mostly) tests. You can find known flickering tests on http://jira.xwiki.org/issues/?filter=14240. The goal is to really fix them, not just add some random wait here and there ;) If you are really not confident with the area around those specific flickering tests here are some other ideas for this kind of Day: * obviously add more tests and increase the code coverage * move tests from enterprise to platform. Needed for the platform flavor and removal of XE * update jacoco covering setup (we often forget to increase it when adding more tests) * move more tests from JMock to Mockito * work on new test setups and tools: ** improve docker containers for packaging XWiki (possibly several for multiple DBs and Servlet containers). ** work on spreading Jenkins platform job into one job per maven module so that build can be spread on various agents (groovy scripting) ** Research/Use Jenkins 2 Pipeline plugin with the new DSL and commit the jenkinsfile in SCM ** Test platform to run contrib extension tests on various versions of XWiki automatically * Speedup existing tests (research xwiki startup time, remove unnecessary modules, etc) When what you fix can be linked to an issue, tag it with "testday" (same idea as "bugfixingday" when doing BFD). If not then answer to this mail to explain what you did. Good Test Day !

1 1

[xwiki-devs] [Proposal] Use <thead> to improve the HTML produced by the XHTML renderer for tables
by Vincent Massol 20 Feb '17

20 Feb '17

Hi devs, For the following XWiki Syntax 2.1 input: |=head11|=head12 |cell11|cell12 We generate the following XHTML 1.0 output: <table> <tbody> <tr> <th>head11</th> <th>head12</th> </tr> <tr> <td>cell11</td> <td>cell12</td> </tr> </tbody> </table> I think it would be better to generate: <table> <thead> <tr> <th>head11</th> <th>head12</th> </tr> </thead> <tbody> <tr> <td>cell11</td> <td>cell12</td> </tr> </tbody> </table> Arguments: * More standard. * In addition I read I the XHTML spec that "Table rows may be grouped into a table head, table foot, and one or more table body sections, using the thead, tfoot and tbody elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.” I haven’t checked but hopefully it should relatively painless for our CSS (unless we use a rule for tbody/tr/th instead of tr/th or th). However even if it changes our CSS I still fee it’s the right thing to do with a note in the Release Notes for the unlikely chances that it would break something. Note tat I know that for example for the http://extensions.xwiki.org/xwiki/bin/view/Extension/Datatables+Macro extension, we cannot use xwiki syntax because of this issue (this is why the example is using the html macro). WDYT? Thanks -Vincent PS: our XHTML parser already supports this as can be verified with the following test: {{groovy}} def input = ''' <table> <thead> <tr> <th>head11</th> <th>head12</th> </tr> </thead> <tbody> <tr> <td>cell11</td> <td>cell12</td> </tr> </tbody> </table> ''' def xdom = services.rendering.parse(input, 'xhtml/1.0') println "{{{" println services.rendering.render(xdom, 'xwiki/2.1') println "}}}" {{/groovy}}

3 2

[xwiki-devs] [Brainstorming] Interesting config library: cfg4j
by Vincent Massol 19 Feb '17

19 Feb '17

This could be an idea to replace our aging commons-configuration at some point: https://github.com/cfg4j/cfg4j It looks a bit more modern. WDYT? Thanks -Vincent

1 0

[xwiki-devs] [ANN] Official docker image for XWiki on dockerhub
by Vincent Massol 18 Feb '17

18 Feb '17

Hi everyone, Just wanted to let you know that the XWiki docker image is now an official image on docker hub! See https://hub.docker.com/r/library/xwiki/ Please try it out and let us know how it goes. That’s probably one of the simplest way to try XWiki now. It comes configured with filesystem attachment by default and libreoffice configured too for office imports/exports/viewing office docs. Thanks -Vincent

1 1

[xwiki-devs] [VOTE] Get rid of xwiki-enterprise-archetype module
by Thomas Mortagne 18 Feb '17

18 Feb '17

Hi devs, Maintaining something like xwiki-enterprise-archetype is a pain and really does not worth it IMO since it's probably not used at all. And as you can see from the history it's never really been maintained after it's introduction 3 years ago and XE changed a lot since that time. We should simply get rid of it IMO. If someone really wants to provide something like this it can be done in Contrib. In the meantime copy/pasting XE and modify the few things you need to modify is not very hard i you want to introduce a new XWiki distribution (and if flavor is not enough for you). WDYT ? -- Thomas Mortagne

3 2

[xwiki-devs] Edit Modes vs. Editors
by Marius Dumitru Florea 18 Feb '17

18 Feb '17

Hi devs, While working on adding extension points to support the replacement of the current WYSIWYG editor I came to the conclusion that we need to make a clear distinction between Edit Modes and Editors. An Edit Mode is basically an HTML *form* that allows you to edit some data that is associated with an XWiki document. There can be for instance an edit mode to edit the document title and content, another edit mode to edit the document objects, another one to edit the document access rights, and so on. Ideally, XWiki extensions should be able to provide new edit modes. The current place where we expose the Edit Modes is the Edit Menu. Class, Objects, Access Rights, Inline Form are well defined edit modes. Before we talk about the Wiki and WYSIWYG "edit modes" let's define what an editor is. An Editor is basically a form *field*. Most of the time it is an enhanced form field, a widget, that allows you to edit a single document field. The editor obviously depends on the field type. There can be a date editor (known as date picker), a plain text editor, a rich text editor, and so on. Ideally, XWiki extensions should be able to provide new editors for specific data types. For instance an extension could replace the date picker. Another one could replace the rich text editor. The relation between Edit Modes and Editors is many to many. An Edit Mode can use multiple editors and an Editor can be used by multiple Edit Modes. For instance the rich text editor can be used in the "Content" edit mode (for document content) but also in the Inline Form edit mode, for TextArea object properties. If we agree with this distinction then I think XWiki should have separate extension points for Edit Modes vs. Editors. What does this mean for the CKEditor integration? Well, CKEditor is an editor.. so it doesn't make sense to have a "CKEditor" edit mode. CKEditor can be used to edit the document content as well as the TextArea object properties that contain wiki syntax. So there should be no "CKEditor" entry in the Edit Menu. Otherwise we need to add "Inline Form - CKEditor" also, and so on for each Edit Mode that can use the CKEditor. So I think we should go in the following direction: * Replace Wiki and WYSIWYG entries from the Edit menu with a single Entry that will represent the Edit Mode for editing the document title, content and syntax. I'm not yet sure what name should we use for this Edit Mode. Let's call it "Content" for now. * The default edit action (for simple users) will ** open the Inline Form edit mode if the document has a sheet associated ** open the "Content" edit mode otherwise * The "Content" edit mode will use the Editor configured in the User Profile, falling-back on the wiki preferences * The Inline Form edit mode will use for TextArea properties the Editor specified in the property meta data, falling-back on the User Profile setting, then on the wiki preferences * We should have an administration section to configure the default Editor as wiki level (wiki preferences) We don't have to implement all this right away. I'd like to start by making the editor list from the TextArea meta data, User Profile and wiki preferences extensible, so that CKEditor can add its entry there. WDYT? Thanks, Marius

8 14

[xwiki-devs] [XWiki Day] BFD#136
by Alexandru Cotiuga 17 Feb '17

17 Feb '17

Hello devs, Today is BFD#136: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 500 days period is 39 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352#Created-vs-R… Here's the BFD#136 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13804 Happy BugFixing Day, Alex

1 1

[xwiki-devs] Help Center
by Marius Dumitru Florea 13 Feb '17

13 Feb '17

Hi all, For the 9.1 roadmap, see http://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki9.0-9-2, Caty and I have worked on a Help Center to cover the "Demo Content" and (partially) the "In-Product Tours and Documentation" topics. I opened this issue http://jira.xwiki.org/browse/XWIKI-14018 to follow the progress. I committed a first working version on https://github.com/xwiki/xwiki-platform/tree/feature-help-center . I committed the code in platform mainly because we already have a xwiki-platform-help-ui module which is related, but we can discuss putting the help center in a different place: * either a separate child module of xwiki-platform-help (to separate the help center from the rest of the help pages like the XWiki syntax help and the tips panel) * on xwiki-contrib Caty named it "Help Center" in the initial proposal, then used "Help" in the prototype. We need to decide which one is best. I'm fine with both. The version I committed uses "Help Center". The help center pages have quite a few images and 4 big gifs (animated steps) which leads to a 22Mb XAR. I hope the size won't cause any issue. It may slow down the XWiki Enterprise functional tests setup? Caty and I would like to put the help center pages on playground.xwiki.org so that we can measure if it's useful (without having to wait for the playground wiki to be upgraded to XWiki 9.1). WDYT? Thanks, Marius

4 6

[xwiki-devs] Default location for new pages in customized main space?
by Lilianne E. Blaze 11 Feb '17

11 Feb '17

Hello, Is there a way to customize default location for new pages? (Added later - I figured it out, I'm leaving the previous steps of how and why) I set up a new XWiki (9.0) from scratch, created "Public" space, configured it so non-admins don't see anything else, switched it to default both in web.xml "homePage" param and Admin -> Descriptor -> Homepage "Public.WebHome", everything works as intended, but when I'm at host/bin/view/Public/ and I click "Plus icon (Create)" it offers to create a new page at top level "home /", while I want it to select "home / Public /" by default, which I assume would be a reasonable behavior. Is it possible? >From what I checked it's handled in file skins/flamingo/menus_content.vm ? "#macro(displayCreateButton) <div class="dropdown" id="tmCreate"> <a href="$doc.getURL('create')" role="button" title="$services.localization.render('core.menu.create')"><span class="glyphicon glyphicon-plus"></span></a> </div> #end" Any suggestions on how to change it? I tried replacing the lines: <div class="dropdown" id="tmCreate"> <a href="$doc.getURL('create')" role="button" title="$services.localization.render('core.menu.create')"> <span class="glyphicon glyphicon-plus"></span></a> </div> With: #set( $parentEqualsDocFullName = "parent=$escapetool.url($doc.getFullName())" ) <div class="dropdown" id="tmCreate"> <a href="$doc.getURL('create', $parentEqualsDocFullName)" role="button" title="$services.localization.render('core.menu.create')"> <span class="glyphicon glyphicon-plus"></span></a> </div> Turns out it just ends up being ignored. (Added later) Also, as I understand now it would be redundant. After some googling I found createinline.vm, lines 239-243 #if ($parentReference.equals($homeReference.lastSpaceReference)) ## We want to discourage ending up with all the pages children of the homepage so we ## default to top level documents, unless the user explicitly says otherwise. #set ($parentReference = $parentReference.wikiReference) #end Actually that's exactly what I want. I'm trying to comment out the 4th line. Restarted, it worked. It all seems a bit counterintuitive, could you please consider making it configurable, in "xwiki.properties" maybe? Why exactly is it "discouraged"? Is it only a matter of "style" or are there any potential complications I'm unaware of? Greetings, Lilianne

1 0