xwiki-devs August 2017

xwiki-devs@xwiki.org

14 participants
31 discussions

[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

7 years, 4 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.

7 years, 4 months

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

by Alexandru Cotiuga

Hello devs, Today is BFD#147: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is: * -28 bugs over 120 days (4 months), i.e. we need to close 28 bugs to have created bugs # = closed bugs # * -38 bugs over 365 days (1 year). * -37 bugs over 500 days (between 1 and 2 years) * -102 bugs over 1600 days (4.3 years) * -783 bugs since the beginning of XWiki See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#147 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13909 Happy BugFixing Day, Alex

7 years, 4 months

[xwiki-devs] [Proposal] Design of the Notifications Center.

by Clément Aubin

Hi devs ! So … it’s yet another proposition on "How should we design the notifications center". Today, two proposals are made in order to integrate the options that we have currently in the watchlist preferences into the notification center UI. We have two ideas described in this design page : http://design.xwiki.org/xwiki/bin/view/Proposal/NotificationPreferenceCente… and dicussed in this JIRA issue : https://jira.xwiki.org/browse/XWIKI-14597 As those two UI are quite different from each other, we would love to get your feedback on these proposals. WDYT ? Thanks, -- Clément Aubin Web Developer Intern @XWiki SAS clement.aubin(a)xwiki.com More about us at http://www.xwiki.com

7 years, 4 months

[xwiki-devs] Release of DokuWiki importer Milestone 2 [GSOC]

by Shubham Jain

Greetings everyone! I’m pleased to announce the second milestone of the Dokuwiki importer. The additions are : > Support for a wide range of archives in the input. > DokuWiki Syntax parser supporting full grammar. You can find it here: http://extensions.xwiki.org/xwiki/bin/view/Extension/DokuWiki/ Please feel free to experiment, and report any bug that you encounter. Cheers! Shubham

7 years, 4 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

7 years, 4 months

Re: [xwiki-devs] Your form "Downloading XWiki (xwiki.org)" got a response

by Vincent Massol

Hi Sascha, Thanks for filling out this form, this help us! :) See below > On 3 Aug 2017, at 20:05, Response Report <report(a)formassembly.com> wrote: > > Your form "Downloading XWiki (xwiki.org)" has received the following response: > > Submitted on: 03/08/17 20:05:15 [snip] > Would you like to get into details? > Q. Suggest Improvements > R. Dashboard Design - Ready to start designs / Templates - improvement in navigation > Missing features: Professional project management with milestones, deadlines, effort, time measuring, UML diagram support Let me try to explain what exists and you can tell me if it’s enough or not, ok? :) * "Dashboard Design". We have this: http://extensions.xwiki.org/xwiki/bin/view/Extension/Dashboard%20Application (and http://extensions.xwiki.org/xwiki/bin/view/Extension/Dashboard%20Macro). You can drag and drop widgets to move them around, add columns, etc. What’s missing? * "Ready to start designs / Templates”. We are bundling these templates: http://extensions.xwiki.org/xwiki/bin/view/Extension/Templates%20Applicatio…. Is that good enough? * " improvement in navigation”. Could you give some examples/more details? * "Missing features: Professional project management with milestones, deadlines, effort, time measuring”. Indeed but it’s not the goal of XWiki to provide a professional project management tool; there are plenty of (web)apps that do this much better already :). We do have a lightweight version though: http://extensions.xwiki.org/xwiki/bin/view/Extension/Generic%20Project%20Ma… * "UML diagram support”. We do support this through several macros. - http://extensions.xwiki.org/xwiki/bin/view/Extension/PlantUML%20Macro - http://extensions.xwiki.org/xwiki/bin/view/Extension/YUML%20Macro - http://extensions.xwiki.org/xwiki/bin/view/Extension/Sequence%20Diagram%20M… WDYT? I’d love to know more from you and to understand what we’re missing. Thanks -Vincent XWiki committer > > Q. Anything else > R. > > > Where should we send the data? > Q. Send to > R. - Keep the data anonymously on XWiki.org > > > Who are you? > Q. Name > R. Sascha Wichert > > Q. Email > R. Wichert(a)inztitut.de > > Q. Job Title > R. > > Q. Country > R. Germany > > > > > > >

7 years, 4 months

[xwiki-devs] [VOTE] Bundle the blame-api as core extension

by Eduard Moraru

Hi, devs, During a hackathon session, I have done a refresh on XWiki's code viewer ("code.vm") and integrated the Blame API [1] developed by Denis to add line-by-line blame information, just like GitHub's blame feature. Please see the associated Jira issue that also includes before and after screenshots: https://jira.xwiki.org/browse/XWIKI-14578 The Blame API module is a commons module since 2014 but not bundled neither in the WAR nor in the flavor, so, in order to go along and merge my work, I'd need it to be available as a core extension (to be also usable by code.vm). I have not studied it deeply, but the module seems to be doing its job well and the result is very nice and it is very generic. Being able to perform a blame analysis builds upon the diff module and both are features of XWiki's versioning capabilities, so, IMO, both should be considered core extensions (and not only the diff module, which already is core). The PR is available at https://github.com/xwiki/xwiki-platform/pull/605 Here is my (obvious) +1 to bundle the blame-api and merge the PR which includes the UI. Thanks, Eduard ---------- [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Blame%20Module

7 years, 4 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

7 years, 4 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

7 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs August 2017