xwiki-devs June 2016

xwiki-devs@xwiki.org

20 participants
51 discussions

[xwiki-devs] UI extensions points VS ConfigurableClass (or any XObjects mechanism)

by Guillaume Delhumeau

Hello developers. I send this e-mail because I want to talk about the concept of UIX when it comes to inject content in a application that has already a mechanism to append content. Use-case: being able to inject some content in an administration page. Example: I would like to write an extension that display some informations on the "users" section of the administration. See the image: http://jira.xwiki.org/secure/attachment/32664/32664_example.png Currently, the only solution that I have is to overwrite XWiki.AdminUsersSheet which generate 2 problems: - it's a mess to maintain when XWiki is upgraded. - 2 different extensions cannot inject content in the same page (one will overwrite the other). Generally, we implement UI extension for this kind of problems, and that was my first intention. In the commit https://github.com/xwiki/xwiki-platform/commit/374903eea354db2d25b6541f8fd7… (on a branch), I've introduced a UIX point on the top of the right side of the administration. It can display several ordered extensions. And it can be displayed in a particular section, or in all of them. The UI extension has the following benefits: - we can easily create extensions to inject content anywhere. - if the UIX is supposed to be injected in a particular section and if that section does not actually exists (for example: if it has a part of an optional application that is not installed), the UIX is simply not displayed. - the mechanism is already used in a lot of places and is well-known. But in this particular context, this solution has a drawback: it creates a kind of duplication with the ConfigurableClass mechanism that we use to display sections in the administration ( http://extensions.xwiki.org/xwiki/bin/view/Extension/Administration+Applica… ). So I've tried to create a ConfigurableClass object to implement my use-case. However, it has several issues: - if 2 XObjects define the same section in the administration, both of them are displayed but we cannot select the order. - one of the 2 xobjects is automatically added in a form, which is not what I want. According to the documentation: " codeToExecute is executed before the form is begun, however if you have multiple ConfigurableClass objects in the same application which are also shown in the same section of the administration application (perhaps with different headers) then codeToExecute of any ConfigurableClass object after the first will be executed inside of the form. " There is one image to show this: http://jira.xwiki.org/secure/attachment/32665/32665_problems.png The mechanism has also the following limitations: - there is no way to inject content in ALL the sections of the administration. - if you want to inject content in a section only if that section exists, you cannot. Because of the presence of your object, the section will be displayed all the time. This is bad if you want to inject some content in an optional application that might be or not installed. So I'm front of 2 possible implementations: - introduce the UIX anyway, with all it benefits. - improve the ConfigurableClass mechanism, with special attention to not break the backward compatibility (I think about the "codeToExecute" parameter). The first solution have my preference. Not only because it's easier to implement (see my patch), but also because of its benefits. Moreover, the use-case is NOT to create a section in the administration. It is only about INJECTING content on an existing section, and this is exactly the purpose of UIXs. I believe this debate exceeds this particular use-case, and that we might have the same question for any application that define some custom way to be modular. So I propose this rule: - it's OK to create a custom mechanism to *structure* a modular application. - it's OK to add some UIX points in it too when the goal is to be able to inject content in an existing section. But I find this definition quite imprecise. What do you think about this? For the record, this is the JIRA issue about this topic: http://jira.xwiki.org/browse/XWIKI-13494 Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years, 5 months

[xwiki-devs] [UX][Proposal] Recommended extensions on e.x.o

by Ecaterina Moraru (Valica)

Hi devs, This is a proposal on how we could improve the homepage of extensions.xwiki.org in order to make it easier for users to discover useful extensions. Homepage: http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrgExtensionsWiki/… The main idea is to add a Recommended property to the Extensions class in order to select some extensions that we believe to be of high quality. Having this property will help us highlight this selection on the homepage, by providing a custom livetable (users that will want to browse all extensions should use the 'Browse' action - that will take them to the current e.x.o livetable). Some notes about the recommended livetable, we should: - add a filterble Ratings column - improve the Author column (by providing filtering and a display) - simplify the date format I've tried to make the proposal as simple as possible to implement. Let me know what you think, Caty

8 years, 5 months

[xwiki-devs] [GSoC] [Reminder] Mid-term evaluation deadline is June 27, 19:00 UTC

by Eduard Moraru

Hi fitz, According to GSoC`s rules, both the student and the mentor need to fill out the period evaluation form. Failure to do so on either side results in the exclusion of the student from the program. More details in the GSoC student's guide [1]. So please make sure that you don`t forget to fill in your evaluation form before the deadline (less than 4 days left)! Thanks, Eduard ---------- [1] http://write.flossmanuals.net/gsocstudentguide/evaluations/

8 years, 6 months

[xwiki-devs] [XWiki Day] BFD#108

by Alexandru Cotiuga

Hi devs, This Thursday is BFD#108: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 129 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#108 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13619 Happy Bug Fixing Day! Thanks, Alex

8 years, 6 months

[xwiki-devs] [VOTE] Deprecated and remove MediaWiki parser from xwiki-rendering

by Thomas Mortagne

Hi devs, I just released as a contrib extension a new MediaWiki parser which covers the old one located on xwiki-rendering (and also fix many issues that were not even listed). The big change is that the actual parser is https://bitbucket.org/axelclk/info.bliki.wiki/wiki/Home and not done by us anymore, we just produce event from the DOM provided by bliki. So I propose to get rid of the old one and retire it in contrib organization. WDYT ? here is my +1 -- Thomas Mortagne PS: OK I already did it and then Vincent reminded me that it would be nice to have a mail about it :)

8 years, 6 months

[xwiki-devs] [VOTE] New Strategy for the XWiki Github Organization

by Vincent Massol

Hi devs, I’m transforming the brainstorming that was started in the thread http://markmail.org/message/exlndbq3tw2thmmu into a VOTE mail since this is a very important decision. So I’m asking you to vote for defining a new direction for the XWiki Core Dev Team (i.e. for the XWiki GitHub Organization). The need was triggered by the Tour and CKEditor extensions which are currently in xwiki-contrib and that we want our users to have by default. For more details see this thread: http://markmail.org/message/exlndbq3tw2thmmu So here’s the strategy: * Make XWiki Github org == minimal runtime, where minimal means “basic wiki” (page edition, history, linking, wiki markup, etc). The notion of “basic wiki” would need to be better defined but this can be done later on. * Provide a "Base Flavor" which corresponds to this “basic wiki”, as part of xwiki-platform (this would be xwiki-platform-distribution). * Provide another flavor, the "Default Flavor” which would add some hand-picked third-party extensions (i.e. from contrib) such as the Tour app and CKEditor (to start with, we could also add the markdown syntax for example which is one of the most asked syntaxes). Note that this Default Flavor would actually be a “replacement" of xwiki-enterprise. * The Default Flavor would have at least the same release cycle as the base flavor but it could have more releases (if some of the bundled third-party extensions has some important bug fixes or new features that we want to offer quickly without waiting for the next base flavor release). * The consequence is that the XWiki Dev Team would need to be a bit more careful to monitor the quality of bundled third-party extensions in contrib (check commits, do some smoke testing, etc). Note that the goal of the Default flavor would not be to offer verticals (for this there should be some contrib flavors) and thus it wouldn’t bundle a lot of third-party extensions. Basically we’ll need to validate the version of those third-party extensions that include in the flavor. My POV is that globally this would offer more flexibility for our users (they’ll be able to install extensions such as CK and Tour in older XWiki versions and they’ll get more frequent releases) at the cost of some overhead to develop extensions that work in several versions. The dev team is pretty small and thus it means developing a bit less fast but it’s probably as important, if not more important, to make the code we develop available in older xwiki versions, as XWiki gains traction. Here’s my +1 Please cast your vote. Thanks -Vincent

8 years, 6 months

[xwiki-devs] [Contrib] Tour Application dependency in XWiki

by Alexandru Cotiuga

Hello all, As it was decided already, a Homepage Tour have to be implemented. However, no option regarding the place where the Tour Application should be added as dependency was discussed. There are some possible options: 1) XWiki Enterprise 2) XWiki Platform Distribution 3) XWiki Platform Helper 4) Is there any option to have the Tour Application as a part of the Core ? What would be the best way to include the Contrib applications in XWiki? Thanks, Alex

8 years, 6 months

[xwiki-devs] [ANN] XWiki 8.2 Milestone 2 released

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 8.2 Milestone 2. This milestone release features a redesigned default homepage, a new application index in the drawer and minor improvements to the template providers, the Flamingo skin and Ratings. For developers, we have some welcomed Livetable macro improvements and a long overdue change of behaviour for the getRenderedContent method. 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/ReleaseNotesXWiki82M2 The following people have contributed code to this release (sorted alphabetically): Alexandru Cotiuga Clemens Robbenhaar Denis Gervalle Ecaterina Moraru (Valica) Eduard Moraru Guillaume Delhumeau Marius Dumitru Florea Pascal Bastien Thomas Mortagne Vincent Massol Thanks for your support -The XWiki dev team

8 years, 6 months

[xwiki-devs] [VOTE] Retire MEETING

by Alexandru Cotiuga

Hi devs, Currently, the Meeting Manager Application [ http://extensions.xwiki.org/xwiki/bin/view/Extension/Meeting+Manager+Applic…] is marked, with a warning, as "This application is superseded by the Meeting Application". The application is written in xwiki/1.0 syntax and is full of deprecated usages which makes it unusable at least since XWiki 6.2. Considering the above reasons I propose to retire the MEETING Jira project. Thanks, Alex

8 years, 6 months

[xwiki-devs] [XWiki Day] BFD#107

by Alexandru Cotiuga

Hi devs, This Thursday is BFD#107: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 124 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#107 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13618 Happy Bug Fixing Day! Thanks, Alex

8 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs June 2016