October 2014 - xwiki-devs@xwiki.org

[xwiki-devs] [XWiki Day] BFD#64
by Eduard Moraru 03 Oct '14

03 Oct '14

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!

2 3

[xwiki-devs] Where to commit the new tree widget?
by Marius Dumitru Florea 03 Oct '14

03 Oct '14

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

3 5

[xwiki-devs] Help getting started on a table-generating extension
by Bryn Jeffries 03 Oct '14

03 Oct '14

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.

4 5

[xwiki-devs] [Discussion] New location of the "Add" menu in the new Flamingo skin
by Eduard Moraru 02 Oct '14

02 Oct '14

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 38

[xwiki-devs] [Proposal] Interface and Content Language Separation
by Ecaterina Moraru (Valica) 01 Oct '14

01 Oct '14

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

12 28

[xwiki-devs] [Proposal] Adding new velocity methods to simulate try/catch in Velocity
by vincent＠massol.net 01 Oct '14

01 Oct '14

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

6 13

Re: [xwiki-devs] [Contrib] Requesting repository for the 'Query Generator and Query Macro' application
by vincent＠massol.net 01 Oct '14

01 Oct '14

On 1 Oct 2014 at 08:47:24, Paul Pantiru ([email protected](mailto:[email protected])) 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, [email protected](mailto:[email protected]) wrote: > > Hi Paul, > > On 30 Sep 2014 at 14:27:03, Paul Pantiru ([email protected](mailto:[email protected])(mailto:[email protected])) 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 > > >

1 0