February 2017 - xwiki-devs@xwiki.org

Re: [xwiki-devs] [xwiki-users] [UX] Administration Improvements
by Ecaterina Moraru (Valica) 23 Feb '17

23 Feb '17

Thanks Stéphane for your answer. It's very helpful. Caty On Thu, Feb 23, 2017 at 12:15 PM, Stéphane LASSIRE <slassire(a)cesap.asso.fr> wrote: > Hello, > > What a nice idea. > We are using a Xwiki 7.4.4 release. > > 1. what sections are always needed and maybe we could prioritize them; > -> Users / groups / right access / extensions / statistics > > 2. what sections could be grouped together, since they are related; > -> Configuration / Look / Email > > 3. what sections are not relevant and could be removed (maybe because they > are too technical, or not needed or rarely used); > -> wikis (we are using only 1 instance, so no need of multi configs for us) > > 4. if there are important recurring things missing from administration; > -> rights "inspector", not really to know the right of a page inside a > space > for all users and groups > -> activity of a group / user. I try to put a counter inside pages to see > if > it is accessed but it a basic solution. I would like to see how much some > pages are viewed. The statistics are limited on this part > > 5. other ideas? > -> see 4 > > Thanks > > Cordialement > > Stéphane Lassire > Chargé de l'informatique et de la communication > Courriel : slassire(a)cesap.asso.fr > > -----Message d'origine----- > De : users [mailto:users-bounces@xwiki.org] De la part de Ecaterina Moraru > (Valica) > Envoyé : mardi 21 février 2017 16:15 > À : XWiki Mailinglist; XWiki Mailinglist > Objet : [xwiki-users] [UX] Administration Improvements > > Hi, > > We are thinking about improving the Administration, so would be great to > hear your opinion about: > 1. what sections are always needed and maybe we could prioritize them; 2. > what sections could be grouped together, since they are related; 3. what > sections are not relevant and could be removed (maybe because they are too > technical, or not needed or rarely used); 4. if there are important > recurring things missing from administration; 5. other ideas? > > We are particularly interested in 1. and that is sections that are used > often and would love to know which are those (since they differ so much > depending on usage). > > Let us know, > Caty >

1 0

[xwiki-devs] [ANN] XWiki 9.1 Release Candidate 1 released
by Thomas Mortagne 21 Feb '17

21 Feb '17

The XWiki development team is proud to announce the availability of XWiki 9.1 Release Candidate 1. This version contains mainly CKEditor integration, HTML export and Job REST API improvements. Page delete UI is also a lot safer. 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/Data/XWiki/9.1RC1 Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [UX] Administration Improvements
by Ecaterina Moraru (Valica) 21 Feb '17

21 Feb '17

Hi, We are thinking about improving the Administration, so would be great to hear your opinion about: 1. what sections are always needed and maybe we could prioritize them; 2. what sections could be grouped together, since they are related; 3. what sections are not relevant and could be removed (maybe because they are too technical, or not needed or rarely used); 4. if there are important recurring things missing from administration; 5. other ideas? We are particularly interested in 1. and that is sections that are used often and would love to know which are those (since they differ so much depending on usage). Let us know, Caty

1 0

[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