xwiki-devs October 2014

xwiki-devs@xwiki.org

19 participants
67 discussions

by Eduard Moraru

Hi devs, As mentioned last week, I propose we do a BFD (BFD#64) tomorrow: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays We have not really made any progress on this yet, since for the 1 year period we are at 106 bugs behind. See: http://jira.xwiki .org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-Resolved-Chart/10470 Here's the BFD#64 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12602 Thanks and happy bug fixing!

10 years, 2 months

[xwiki-devs] Where to commit the new tree widget?

by Marius Dumitru Florea

Hi devs, Following the vote on http://lists.xwiki.org/pipermail/devs/2014-September/057560.html I started working on a generic tree widget based on jsTree. I'm almost done now and I'm wondering where's the best place to commit my work. There are 3 parts: (1) A generic JavaScript tree widget (used by all trees) The common practice so far was to put the new JavaScript code in xwiki-platform-web (resources/uicomponents). But since we started using webjars I'm wondering if it's not better to create a webjar. The advantage is that the applications will be able to explicitly declare a dependency on the tree widget. The downside is that the JavaScript code is a bit harder to modify. Another option is to put the tree widget in a JSX object but we may need to use it in Velocity templates also (e.g. the report step of the DW). I prefer the webjar. (2) A couple of wiki pages that define specific trees: * One page for the All Docs Tree (space-page-child) * One page for the XWiki Entity Tree (wiki-space-page-[translations|attachments|objects|properties|sections]) * One page for the Hierarchy Tree (page-child) * One page for the XAR import tree (space-page) * others later maybe I'm hesitating between creating a dedicated module (xwiki-platform-tree-ui) and putting them in existing modules like the xwiki-platform-index. (3) A couple of jobs (Java code) to perform tree operations that can take time, like deleting or renaming a space. For these I could use the xwiki-platform-refactoring module since they are generic operations, not limited to trees. We have a Delete space entry in the top menu and we probably want a Rename space one. WDYT? Thanks, Marius

10 years, 2 months

[xwiki-devs] Help getting started on a table-generating extension

by Bryn Jeffries

I'm appreciate some pointers on getting started on writing an extension component that retrieves data from an external database and presents it as a table. I have reviewed a lot of the available documentation, but must admit to getting a little lost with the various changes in standards, as a lot of the available code and documentation describes macros, which I believe are now deprecated in favour of components. I am happy creating a new component using the Maven archetype, and writing the necessary code to retrieve data from the external database. What I would like help with are: 1) How can I get the current user, so that I can use this contextual information in my query? 2) How should I return the tabular data? I'm sure these are very naïve questions, but please take pity on me and by all means point me at the relevant documentation if it exists already.

10 years, 2 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

10 years, 2 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

10 years, 2 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

10 years, 2 months

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

by vincent＠massol.net

On 1 Oct 2014 at 08:47:24, Paul Pantiru (paul.pantiru@xwiki.com(mailto:paul.pantiru@xwiki.com)) wrote: > Yes, actually I do. Done: - http://jira.xwiki.org/browse/SRA - http://jira.xwiki.org/browse/QGA Enjoy! -Vincent > Thanks > > On Tue, Sep 30, 2014 at 7:19 PM, vincent@massol.net(mailto:vincent@massol.net) wrote: > > Hi Paul, > > On 30 Sep 2014 at 14:27:03, Paul Pantiru (paul.pantiru@xwiki.com(mailto:paul.pantiru@xwiki.com)(mailto:paul.pantiru@xwiki.com)) wrote: > > > > > 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 assume your goal is to move the sources of this extension on github. > > > > Done: https://github.com/xwiki-contrib/application-querygenerator > > > > > I would also like an account on http://nexus.xwiki.org . > > > > Already done earlier. > > > > Won’t you need JIRA projects for both repos created today for you? > > > > Thanks > > -Vincent > > >

10 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2014