xwiki-devs July 2017

xwiki-devs@xwiki.org

14 participants
28 discussions

[xwiki-devs] [VOTE] Use discourse for the "dev" mailing list

by Guillaume Delhumeau

Hi devs, I think we are now satisfied with our experimentation with the "users" mailing list on discourse. I propose you to move the "dev" ML too. My main point is that it allows advanced formatting (which is good when you have complex proposals), meanwhile the formatting is lost with our archiving tool like markmail (it's plain text). Here is my +1. Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

4 years, 10 months

[xwiki-devs] [proposal] Process to handle Pull Requests

by Ludovic Dubost

Hi devs, I don't think there is currently a process that is in place to handle pull requests and I have the feeling that the way there are handled today is a bit random. There are usually comments sent out on each pull request but sometimes it seems that some pull requests are going in sleep mode and it's not clear who is in charge. I would like to suggest that a process is put in place where it's clear who is responsible for a pull request and a status is given to the contributors that propose that pull request. Something like: Assigned developer: XXXX Status: New -> new pull request, not yet assigned Assigned -> assigned to a developer, he is in charge of reviewing the pull request and ask for modifications or accept it. The developer can auto assign it to himself. If nobody does, we need to decide how they will be taken into account. ModificationsRequired -> for now rejected with comments. Contributor needs to apply comments and then change back to Assigned for further evaluation VoteRequired -> there are no more comments, but a vote is required as the changes to XWiki core are important WaitingFinalAuthorization -> optional step for complex patches where a additional authorization would be required (need to define who would be the persons that give the authorization) WaitingApplication -> there are no more comments and no changes or vote required. The pull request can be applied and is waiting for a developer to apply it Abandoned -> contributors is abandoning the pull request (cannot do the changes, no more time, etc..) Rejected -> pull request is rejected (quality not enough, etc..) Applied -> pull request is applied What do you think ? Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

5 years, 2 months

[xwiki-devs] Velocity 2.0 and DeprecatedCheckUberspector

by Claude Brisson

Hi. I'm currently working on Velocity 2.0 packaging. If that's OK with you, I would like to incorporate DeprecatedCheckUberspector.java into Velocity, but I need a statement from your part to be able to change its licence to Apache 2.0 (LGPL and Apache 2.0 licences aren't compatible). By the way, I take this opportunity to tell you that if there is another specific part of xwiki-commons-velocity that you think should be integrated on our side, or an important missing feature you'd like to insist on, don't hesitate. I already integrated VELOCITY-825, for instance, so String->Enum constant conversions are now handled by Velocity. There may be other important conversion cases you'd like to see handled. Regards, Claude

6 years, 1 month

[xwiki-devs] [Vote] Assignee for PR: Contributor or Committer?

by Ecaterina Moraru (Valica)

Hi, We have discussed this subject multiple times, but we don't have an official vote and conclusion on the topic. Problem: In JIRA who is the Assignee of an issue fixed by a Pull Request? 1: Contributor - he provided the solution - giving the attributions, the contributor might feel encouraged to contribute more - we could do some JIRA statistics on external contributions, but this use case can be covered by GitHub statistics 2: Committer - he does the merging on his account and he becomes responsible for the committed code. - in case there are problems, the committer needs to find solution, since we can't rely on contributors availability - in doing the PR review, the committer spends a lot of time analyzing and testing the provided solution We are talking here about complete solutions provided by the PR, since in case of partial solutions, the committer can assign himself on the issue (depends on the quantity of modification he does). Let me know what you think, Caty

6 years, 2 months

[xwiki-devs] [Proposal] Replace OpenJS Keyboard JS with Keypress JS for handling keyboard shoirtcuts

by Vincent Massol

Hi devs, We’re currently using http://www.openjs.com/scripts/events/keyboard_shortcuts/ but it has some limitations. Clement and I tried to find some unused combinations of keys that works on Mac and Unix and we couldn’t find any that worked with it. It also doesn’t support having combinations with several letters for example. For example we could imagine having H+H+H for turning on/off hidden documents (as a developer key sequence since it’s not a user use case). I’d like to propose using https://dmauro.github.io/Keypress/ which is under the Apache 2 license and that seems to work well on Mac and Unix and it’s very powerful. See sequence combos for example. The API look simple and nice and I don’t think it would be hard to continue support our data structure inside the “shortcuts” variable to make it work with it. WDYT? Thanks -Vincent

6 years, 9 months

[xwiki-devs] [Proposal] Entry point for Extensions

by Vincent Massol

Hi devs, Problem ======= We have 2 issues right now when installing an extension in XWiki: 1) It’s not clear where is the entry point of that extension. - Example1: an app that is only for admins and only has a ConfigurableClass - Example2: an app that provides a macro and doesn’t have a UI 2) Even when an extension registers itself in the Applications Panel, the user still need to refresh the page or navigate away to see it. Proposal ======== * Introduce the concept of Entry point (a.k.a home page) in Extension metadata * Have the EM UI display the extension’s entry point (when there’s one) after having installed the extension so that the user can click on it and be taken to the home page of the extension. This would make extensions more discoverable IMO. Implementation Details ================== * Some maven extension metadata properties in pom.xml * A format to represent an entry point. It shouldn’t be a full URL since that needs to be computed at runtime. Basically it should contain: ** The document reference ** The action to use (view, admin, etc) - optional, should default to “view" ** The query string to use - optional, should default to an empty query string This corresponds to the notion of ResourceReference (EntityResourceReference to be precise). However we don’t have any textual representation of it ATM. WDYT? Good idea? Bad idea? Thanks -Vincent

6 years, 11 months

[xwiki-devs] [GSOC Update 5] Redpen Integration

by deshengchuan

Hi all this is another update regarding the integration of Redpen, aka the Content Checker extension. As of now, I have finally implemented dictionary-based validators (validators that check for invalid or subpar expressions). With this, most of the validators will be easily added within the configurable class of the extension. Feel free to check the design page for the UI implementation: http://design.xwiki.org/xwiki/bin/view/Proposal/RedPenIntegration <http://design.xwiki.org/xwiki/bin/view/Proposal/RedPenIntegration> Also, the output of the document checks are currently registered in the logs, and are separated into warnings and errors. The determination of whether a particular validator setting gives a warning or an error is registered in the xwiki.properties file. The automatic validation function also cancels document saves when errors are registered by Redpen. There are now two core milestones to be done on this extension. First and critically, I would need to implement functional test, especially on the Configurable classes. To this end, I would appreciate any advise on how I can implement this (I have previously only created a functional test to test the entry of expressions into the Dictionary part of the extension.) After that, I would then implement the Job module of this extension. (The Job will be accessible in another tab, 'Job', below the current Dictionary tab in the Administration UI panel.) I would greatly appreciate any advice on what else needs to be added regarding the Content Checker functionality, and with the implementation of functional tests. Thank you! -- View this message in context: http://xwiki.475771.n2.nabble.com/GSOC-Update-5-Redpen-Integration-tp760438… Sent from the XWiki- Dev mailing list archive at Nabble.com.

6 years, 11 months

[xwiki-devs] [Proposal] Notifications : Add "in-context" switches

by Guillaume Delhumeau

*TL;DR* - Add a button in each page that will allow you to subscribe to all events that happens to that page. - When you subscribe to a page with this "in-context" bell, it must not affect your other preferences regarding notifications. *Full Post* Hello developers, With Clément Aubin, we are implementing new features in the Notifications Application in order to be able to remove the Watchlist Application. *Status* Currently, a user can subscribe to different kinds of events (ex: "update", "comment", "blog published", etc...). Recently, we have also added the ability to restrict on which locations we are interested in, for each kind of events. For example, we are now able to say, "for the *update* event, show me notifications only about the wiki ABC and for the *blog post* event, show me notifications only about the space XYZ". If you have no restriction (a.k.a "filters") on an event type, then you receive notifications for every event matching the event type in the wiki, no matter the location of the entity it concerns. *Objectives* In the Watchlist Application, we had 3 switches on the top menu that was displayed on every page, and these switches were "watch this wiki / watch this space / watch this page". That would be great if we could have the same for the notifications. *Proposal* - Add the ability to subscribe to all events that happen in a given location, no matter their type (≈ what the watchlist does). - In each page, add a button to subscribe to the current location: https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup) - Problem: if you previously had no restriction, you suddenly add a new one that will prevent you to receive any notifications concerning the other locations. A bit like the rights module: adding a right to someone at some level will dismiss rights for all other people. I guess we all agree it's a problem on the User Experience point of view. - Proposition: the restriction added by the "in-context" button should be *inactive if there is no other restriction enabled manually via the notification preferences UI*. - Rational: - When you are on the notifications preferences, you can actually see all restrictions, so you can understand that creating one will make you lose all notifications that do not honor the restrictions. - However, when you are on a page, you don't see all the restrictions. If you click on the "subscribe" bell naively, you might not expect it will impact all other notifications. It would actually be very confusing. - In addition: if we add an "auto-watch" option, that add the page you just saved to the list of locations you are interested in, we need to have this feature too. Otherwise saving a document will make all other notifications silent. That is our plan. Cast you ideas! Thanks, Guillaume

6 years, 11 months

[xwiki-devs] [Proposal] Change the default blog post layout to 'image' layout

by Mohamed Boussaa

Hello XWikiers, Starting from the version 9.4 of the Blog application we introduced the notion of blog post layouts (see details here: http://extensions.xwiki.org/ xwiki/bin/view/Extension/Blog%20Application). Currently when a user creates/edit a blog he has the possibility to select the layout of the blog posts, 2 layouts are available FTM: the Calendar layout (default) and the image layout. The image layout uses an image thumbnail in order to allow a more visual and appealing display of the blog posts this is why an image selector was added to the blog post form. Because the default layout is 'Calendar' the image selector on the blog post form can be confusing for the user because the uploaded image doesn't appear anywhere. This proposal is about changing the default blog posts layout from 'Calendar' to 'image' in order to avoid the confusion. I propose to: - Change the default post layout to 'image' layout for new blogs - Change the layout of the default Blog to 'image' layout - Add an image to the introduction blog post created when installing the blog app. Find attached some examples of images that can be used on the introduction post. - On the blog post form add a short description to the image selector to explain the objective of the image. *Introduction blog post images* *1) * *2)* *3) * *4)* ** WDYT? Thanks, Mohamed

6 years, 11 months

[xwiki-devs] [GSoC] Extension Repository Connector - Pypi released!

by Krzysiek Płachno

Hey! I'm happy to announce that Extension Repository Connector - Pypi is released - http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension%20Repository… XWiki has possibility to scirpt on its pages in Python. Under the hood it's Java Scripting API and Jython that takes care of running this script and returning result to page. Jython has implementation only for standard libraries. That's why Extension Repository Connector - Pypi is created - to be able to import to XWiki other (non-standard) python packages that are hosted on pypi: https://pypi.python.org/pypi. I'd be grateful for any feedback :) Best, Krzysztof

6 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs July 2017