xwiki-devs September 2014

xwiki-devs@xwiki.org

26 participants
68 discussions

[xwiki-devs] [Brainstorming] Issue tracking for xwiki-contrib projects

by vincent＠massol.net

Hi everyone, ATM the rule we have for contrib projects is to use JIRA (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HHostingtools) I’ve heard that some people have been proposing using other trackers. So I’d like to poll your opinion on the following alternatives: Option A: all projects use JIRA =============================== This is the current option in use. Pros: * A single place for people to view and search for issues in the XWiki Ecosystem Cons: * For XWiki admins, creating a new JIRA project takes 5 minutes Option B: all projects use GitHub issues ======================================== Pros: * Simple to set up for admins (hosted by GitHub) * Simple to use (too simple sometimes?) Cons: * No single place to search all issues related to XWiki (both JIRA + GitHub) * No single place to report JIRA issues * Tied to the SCM choice. When we stop using Git as our SCM and move to the next SCM tool we’ll have to import all issues (see https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-i…) * Need to implement feature on extensions.xwiki.org to add a link to the issue tracker for each extension Option C: let each project decide ================================= Pros: * Simple to set up for admins when project decides on GitHub Cons: * No single place to search all issues related to XWiki (both JIRA + GitHub) * No single place to report JIRA issues * Tied to the SCM choice. When we stop using Git as our SCM and move to the next SCM tool we’ll have to import all issues (see https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-i…) * Need to implement feature on extensions.xwiki.org to add a link to the issue tracker for each extension Option D: XWiki Task Manager ============================ http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Applicati… Pros: * Eat our own dog food. * Forces us to improve this extension Cons: * Pressure to fix bugs * Increases volume of data on xwiki.org and thus impact performances * Maintenance cost: More work when upgrading xwiki.org * No single place to search all issues related to XWiki (both JIRA + GitHub) * No single place to report JIRA issues * Need to implement feature on extensions.xwiki.org to add a link to the issue tracker for each extension WDYT? Other options? Personally and based on all pros/cons I think the best ATM is really Option A. And if we really want, it’s possible to improve the cons by doing a bit of java coding: https://developer.atlassian.com/display/JIRADEV/Creating+a+Project+Template Thanks -Vincent

9 years, 11 months

[xwiki-devs] [Proposal] HomePage Application

by vincent＠massol.net

Hi devs, Problem ======= This week end I’ve had an idea that solves the following issue: - Make it easy for the user to be able to change his wiki's home page - Make it understandable when clicking “edit” on the home page Solution ========= At some point in the past, I moved the dashboard which was on the home page to the Dashboard space. My rationale at the time was: - if the user removes the home page then the user will still be able to navigate to the Dashboard by clicking on the “Dashboard” link in the Applications Panel - when editing the home page it’s “just” an Include Said differently, I considered that the home page can be configured to point to any app. This is what I’d like to push for and make it easy for the user to configure the home page so that it can point to any app. Implementation =============== - A HomePage.HomePageClass XClass with one “reference” field which is the reference to the document to include from the home page (the app to point to if you prefer) - A HomePage.HomePageSheet which is bound to the HomePage.HomePageClass - One instance of the HomePage.HomePageClass put in Main.WebHome so that when you click “edit” on the home page, HomePage.HomePageSheet is called and displays some instructions about changing the home page. Here’s an example: https://www.evernote.com/shard/s119/sh/b682040d-6a09-4cfc-b6aa-1eab4b4d8d5e… Here’s the content of HomePageSheet (not finished, I still need to code the part that changes the “reference” property): {{velocity}} #if ($xcontext.action == 'edit') #set ($previewenabled = 'false') The content of this home page can be the content of any page you wish. Right now it is displaying the content of the [[$doc.getValue('reference')>>$doc.getValue('reference')]] page. In order to change it, click the "Use as Home Page" link in the table below for the page you wish to use as your new home page. #set($collist = ['doc.name', 'doc.space', 'doc.date', 'doc.author', '_actions']) #set($colprops = { 'doc.title' : { 'type' : 'text' , 'size' : 30, 'link' : 'view' }, 'doc.fullName' : { 'type' : 'text' , 'size' : 30, 'link' : 'view' }, 'doc.name' : { 'type' : 'text' , 'size' : 30, 'link' : 'view' }, 'doc.space' : { 'type' : 'text', 'link' : 'space' }, 'doc.date' : { 'type' : 'date' }, 'doc.author' : { 'type' : 'text', 'link' : 'author' }, '_actions': { 'html': true, 'sortable': false, 'actions': ['Use'] } }) #set($options = { 'translationPrefix' : 'platform.index.' }) #livetable('documents' $collist $colprops $options) #else ## If there's content don't use the default app #if ($doc.content.trim().length() > 0) $doc.content #else {{include reference="$doc.getValue('reference')" context="new"/}} #end #end {{/velocity}} - Note that if the user forces the edition in wiki mode or WYSIWYG mode of the home page he gets an empty page and he can put content and when he saves his content is displayed! (this is achieved through the following portion of the script in HomePageSheet: ## If there's content don't use the default app #if ($doc.content.trim().length() > 0) $doc.content #else {{include reference="$doc.getValue('reference')" context="new"/}} #end - Also note that I’d like to propose to add the ability to configure the buttons to display in edit mode. ATM I think only the preview one can be hidden but we could do the same for all. In our case here we could decide to only leave the “Cancel” one active since clicking on “use” in the Livetable could set the page to include immediately. The other option is to use a different picker than the livetable and keep the save buttons. Any suggestion for this? The idea would be to package this as an HomePage Application in xwiki-platform and would be bundled by default in XE. WDYT? Thanks -Vincent

9 years, 11 months

[xwiki-devs] [Discussion] New location of the "Add" menu in the new Flamingo skin

by Eduard Moraru

Hi devs, I`m not sure if we already have a discussion started on this topic, but in my opinion, it's long overdue. I see people start being confused and questions like this [1] start to be asked. The new location of the Add menu in Flamingo is problematic IMO for a various number of reasons: - It falsely gives the impression that it adds page-related entries (i.e. related to the current page), due to its current location (i.e. in the page content) - It conflicts with AWM`s "Add new Entry" button - from my POV, looking at the page from a far, the new location looks completely randomly selected: -- It's not on the left/top (as left-to-right language specific brains are trained to follow) -- it's not exactly at the top either -- it's not at the right -- it's not next to the type of elements it creates (i.e. next to WIKI/SPACE/PAGE) -- it basically is almost in the middle of the screen - etc. (i.e. others that don`t come right now to my mind) I`d like to open a discussion on this, since it's quite an important aspect of the UI and, due to it's shiny green color (which I like :)), it`s hard to miss. Is it just me who's resistant to change, or do others see a problem here with this as well? Thanks, Eduard ---------- [1] http://xwiki.markmail.org/thread/rqcxryksa2ckjhpm

9 years, 11 months

[xwiki-devs] [Proposal] Interface and Content Language Separation

by Ecaterina Moraru (Valica)

Hi devs, We have http://jira.xwiki.org/browse/XWIKI-10745 (Improve the display of available languages in Flamingo) which is related to http://jira.xwiki.org/browse/XWIKI-6402 (Separate Interface language and page language settings) While in Flamingo we could just make the language links look better, without changing the functionality, for the future, the separation is something we might want to tackle, that's why I've created this proposal page http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage… I am interested in what you think about the variants. Thanks, Caty

9 years, 11 months

[xwiki-devs] [Proposal] Adding new velocity methods to simulate try/catch in Velocity

by vincent＠massol.net

Hi Devs, Example of a use case: * In contentview.vm we need to be able to catch when getRenderedContent() throws an exception in order to be able to still display the page title, content menu and last modification line. We want only the content part to display an error. I’ve tried implementing the following: * Modified Document.getRenderedContent() to not throw exceptions any more * I’ve added Document.setError() and getError() * Then added a #displayRenderedContent($renderedContent) velocimacro to display an error, calling Document.getError() However that’s no good because we have lots of places in our code (and in extensions we don’t control) that call getRenderedContent() and they expect the whole page rendering to fail in case of an error… Thus after discussing quickly on IRC and with Thomas we’d like to propose instead: * Add a new #try() velocimacro that would push a new empty List<Exception> in the Execution Context to a Stack variable * Add a new uberspector that would, based on this flag do a try/catch around the method called (can be done easily by returning a custom VelMethod) * The uberspector catch would add the exception to the List<Exception> in the Execution Context * Add a new #catch() velocimacro that would pop from the Stack in the Execution Context and that would set 2 variables in the Velocity Context: ** $exception: the first exception ** $exceptions: the list of all exceptions that happened between the #try() and #catch() The good part with this is: * No change in behavior to all existing code * Code that want to do something in case of error can do it using #try()/#catch() for java methods throwing exceptions (like getRenderedContent()) Of course for the future we would need to decide if script services should stop doing try/catch or not but that’s another debate I’d prefer to separate from this thread. WDYT? Thanks -Vincent

9 years, 11 months

[xwiki-devs] [Contrib] Requesting repository for the 'Query Generator and Query Macro' application

by Paul Pantiru

Hello devs, I would like a repository (called application-querygenerator , I guess) for the < Query Generator and Query Macro > on https://github.com/xwiki-contrib. The application is available on the extensions wiki here: http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Generator with version 1.0. Quoting from the description "The Query Generator uses XWiki's core capabilities to generate search forms and a query automatically.". I would also like an account on http://nexus.xwiki.org . Thanks, Paul Pantiru

9 years, 11 months

[xwiki-devs] [ANN] XWiki 6.2.1 released

by vincent＠massol.net

The XWiki development team is proud to announce the availability of XWiki 6.2.1. This release is a stabilization version that fix important bugs discovered in the 6.2 version. 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/ReleaseNotesXWiki621 Thanks -The XWiki dev team

9 years, 11 months

[xwiki-devs] [Contrib] Requesting repository for the application-internschools

by Paul Pantiru

Hello devs, I would like a repository for the application-internschools on https://github.com/xwiki-contrib. The application is not yet available on the extensions wiki, but can be found on my own repository here: https://github.com/ppantiru/application-internschools . Quoting from the description of the app: "An application meant to help keep track of schools for possible internship/part-time job candidates, and the duration of the ongoing internships/part-time jobs." I would also like a jira project for this app. Thanks, Paul Pantiru

9 years, 11 months

[xwiki-devs] Proposal: moving the "create wiki" and "create space" actions

by Guillaume Lerouge

Hi Devs, I'm currently testing XE 6.2, it's a great release, I love the new look a lot - well done guys! I have a quick remark that is related to the new location of the "Create" button. I think we should move the "create wiki" and "create space" options from where they are located now. The "Create wiki" button could be moved under the list of wikis on this page: http://<server>/xwiki/bin/view/WikiManager/ We would probably need a similar "space index" page with the "Create space" button there, a bit like what we have on the dashboard now: http:// <server>/xwiki/bin/view/Dashboard/ The objective being that when doing those create actions, they would be done with the context of the wikis / spaces that already exist. What is also a bit confusing for users is that since creating a new wiki is much much bigger and less frequent than creating a new page, the action should not be available from every single page. This issue has become much more salient than before to me because of the new location of the "Create" button. What's your opinion about this? Thanks, Guillaume

9 years, 11 months

[xwiki-devs] XWiki 6.2.1 release in progress...

by vincent＠massol.net

Hi devs, Please hold your commits for the 6.2.x branch, I’ve started the 6.2.1 release. Thanks -Vincent

9 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 September 2014