xwiki-devs

xwiki-devs@xwiki.org

9399 discussions

[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

11 years

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

by Bryn Jeffries

Thomas Mortagne said: > An alternative not listed by Guillaume depending on what is your need is to > put your groovy code in a wiki macro which is then used from any wiki code > (in that case only the wiki macro document require programming right). > There is several kinds of "macros" in XWiki, wiki macros as in > http://platform.xwiki.org/xwiki/bin/view/DevGuide/WikiMacroTutorial > as not deprecated, on the contrary (they actually are components). This is a very promising route, thanks. Any yes, I did get confused about what was deprecated. I said macros, when I think it's actually plugins that are deprecated.

11 years, 1 month

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

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!

11 years, 1 month

[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

11 years, 1 month

[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.

11 years, 1 month

[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

11 years, 1 month

[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

11 years, 1 month

[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

11 years, 1 month

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 > > >

11 years, 1 month

[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

11 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs