xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] Google Android Client for XWiki - GSOC project

by Chamika Weerasinghe

Hi devs, Since GSOC students have to start coding from today (23rd May) onwards I like to gather requirements and decide scope of the mentioned project. A short description of the project is included here<http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Androidclient> (http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Androidclient) Simply I will try to access XWiki dataset using REST API and implement Android Library. Then by using that Android Library a sample application will be developed. Before starting I would like to know all of your ideas related to this such as what should be implemented, what will you expect from an Android Library etc. So that I can get a better understand about the XWiki Android. Thank you all, Best Regards, Chamika Weerasinghe

13 years, 8 months

[xwiki-devs] Fail to build XWiki from GitHub

by Bogdan Flueras

Hello devs, Today I've cloned the xwiki - {platform and commons} modules from GitHub. 1) When I tried to build the platform module it gives me a strange error. See it at http://pastebin.com/HMTLkc76. It's xwiki-commons-tool-xar-handlers.3.1-SNAPSHOT dependency that is not fetched correctly. In an attempt to fix it, I've cleaned my local repo and forced updates via mvn .. -U command line option. So after getting the same error message [see above], I've inspected my repo and the following files were found: resolver-status.properties xwiki-commons-tool-xar-handlers-3.1-SNAPSHOT.jar.lastUpdated xwiki-commons-tool-xar-handlers-3.1-SNAPSHOT.pom.lastUpdated All these files contain the same content: #NOTE: This is an internal implementation file, its format can be changed without prior notice. #Thu May 26 16:37:28 CEST 2011 maven-metadata-xwiki-plugins-snapshots.xml.error= maven-metadata-xwiki-plugins-snapshots.xml.lastUpdated=1306420648539 maven-metadata-xwiki-plugins-externals.xml.lastUpdated=1306420648539 maven-metadata-xwiki-plugins-externals.xml.error= 2) I've also tried to clone the xwiki-trunks module and to build it, but I think there is a little inconsitency with respect to directory layout( SVN layout). See the <parent> section where the relative path is "commons" instead of xwiki-commons. Of course that I can go to the problematic submodules and further pinpoint the problem (this is what I will do now), but personally I would like to do nothing more than a simple "mvn install" at the root of the main module. Thanks and looking forward hearing from you, -- ing. Bogdan Flueras

13 years, 8 months

[xwiki-devs] [proposal] Remove fix-for version from all issues fix-for 3.1-RC1.

by Caleb James DeLisle

We have 17 unresolved issues which are labeled as needed to be fixed for 3.1-RC1. http://jira.xwiki.org/jira/secure/IssueNavigator!executeAdvanced.jspa?jqlQu… Some of these issues are relatively new and others are quite old and have had their fix-for version advanced at each release. In my opinion setting a fix-for version is equivalent to making a promise to produce a fix by a certain date. To make a promise and fail to keep it is bad but making a habit of periodically breaking promises and making new ones is far worse. Since I have proposed a freeze on new features I would like to propose removing these fix for versions. WDYT? Caleb

13 years, 8 months

[xwiki-devs] questions about XWiki-5820

by Jun Han

Dear all, Regarding REST API for XWiki, Source codes are in xwiki-trunk/xwiki-platform/xwiki-platform-core/xwiki-platform-rest. Test codes are in xwiki-trunk/xwiki-enterprise/xwiki-enterprise-test/xwiki-enterprise-test-rest. I hope I am looking at the correct places. XWiki-5820 is related to adding an endpoint for providing a rendered version of the page. Does REST API need to invoke xwiki-rendering library in order to render the html content? The current implementation will return various resources, (e.g., pages, tags, attachments), and produce XML responses in most cases. In XWiki-5820, only page resources will be rendered, right? A straight-forward way may be to add additional end point (getPage and getPageInHTML), and they will be invoked according to different Accept http headers. It would be great that an example can be given to show the expected input and output. Best regards Jun Han

13 years, 8 months

[xwiki-devs] [Discussion] Dashboardification of the Main.WebHome

by Luca Anca

Hello devs, as suggested before, I would like to make the main page of the wiki a full dashboard, namely to relocate the welcome message in a gadget so that the type of page of the main page is more clear. See this two screenshots about how it could look (one is with default style, other is with panels style). http://dev.xwiki.org/xwiki/bin/download/Design/GadgetIntegration/WikiDashbo… http://dev.xwiki.org/xwiki/bin/download/Design/GadgetIntegration/WikiDashbo… (also http://dev.xwiki.org/xwiki/bin/download/Design/GadgetIntegration/MainDashbo… ) if you want to import it in your own wiki and play with it. I want to discuss the following points now: 1/ is the title "Wiki Dashboard" ok for the main page of the wiki? 2/ Is the welcome message visible enough, is it accessible to users and explanatory about what the page is about and what they could do next? 3/ what would be the relation now with the old Main.Dashboard page, which, as you can see in the quick links panel, is a "Wiki Dashboard" itself? Should it be the same page? if so, is it ok that the welcome message appears on the wiki dashboard? if they're not the same page then it's a bit strange that they're called the same but 2 different pages... Should we rename one? Technically the welcome message is written in a new page, Main.Welcome, and then included in a gadget in the dashboard. This page can be translated for getting the message in different languages. WDYT? Thanks, Anca

13 years, 8 months

[xwiki-devs] Hidden documents

by Denis Gervalle

Hi Devs, Anyone of you will surely agree that the hidden document feature implemented in the store is very bad. IMO, it has never been fully implemented, probably in the hope of a better way to go, and it is so for too long. I think it is the time to take some decision about it, or I do not see the direction and I do not understand where we want to go ? I see 3 possibilities: 1) we remove it and found other way to solve the problem it solves, which are currently limited to the Blog, ColorThemes and Panels applications in a standard XE. 2) we keep it as it is, since it could be hard to implement higher in the current implementation, but then we need to fix the places where it cause issues. 3) we implement the feature using another method ? If we choose 1), early in 3.x release is the probably best moment for it, since it is a breakage in compatibility, I am -0 on this however. If we choose 2), we need to make it work properly by fixing places where we need to include all document, including hidden one. I have some old patch to the application-manager to export hidden document (ie: currently the blog application does not export properly), to the skinx plugin that does not apply 'always' skin extensions contained in hidden document, and there is probably other places. If we choose 3) now, what do you proposed to better implement it. I have read some comments that it was a UI level stuff implemented at the store level, but I do not see how it could be done better in the current implementation. Moreover, if we keep the feature, I think that it should be exposed somehow to the admins, allowing the creation of hidden document, but also listing them, deleting them properly, etc... Concerning the document provided with XE, I also wonder what could be the rules for hiding them or not ? Why not also hidding stock document in the XWiki space, just keeping users and some top level documents ? WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

13 years, 8 months

[xwiki-devs] How to access individual xwiki's class properties (in template) (velocity code)

by Karel Gardas

Hello, for authoring template code like: ## You can modify this page to customize the presentation of your object. ## At first you should keep the default presentation and just save the document. #set($class = $doc.getObject('Book store.AuthorClass').xWikiClass) #foreach($prop in $class.properties) ; $prop.prettyName : $doc.display($prop.getName()) : $prop.getName() #end is used by default. I need to modify this to extract some of the properties of the object and set it to the Xwiki context to be passed into another scripts, but besides #foreach I'm not able to extract individual properties from the properties collection by any possible way. Some of things I tried was (in my case I'm interested in "name" property) $class.properties.name $class.properties["name"] #set ($props = $class.properties) $props $props.name $props.get("name") $class.properties.getName() ($($class.properties).getName()) but so far w/o any success. On the other hand the code like: #foreach($prop in $class.properties) #if ($prop.getName() == "name") I FOUND THE NAME PROP! #end #end is working well, but is not that elegant as if properties would allow kind of map usage... Any help on this is highly appreciated. Thanks, Karel

13 years, 8 months

[xwiki-devs] [Proposal] User dashboard implementation

by Luca Anca

Hi devs, I was thinking to implement the user dashboard as follows: 1/ store the gadget objects for a user dashboard in the user page (XWiki.username) 2/ add a tab on the user profile to display (and edit) this dashboard 3/ make the Main.WebHome display the user dashboard when a user is logged in (with various mechanisms to provide nice UX when his dashboard is empty, etc) 4/ add a configuration flag in the user class to say if the behaviour described at 3/ should apply or not ("display my dashboard on main page") -- default value to be decided, I would say it should be 'true'. WDYT? I will start a proof of concept of this these days... Thanks, Anca

13 years, 8 months

[xwiki-devs] [IDEA] Distribute javadb based instead of hsqldb based packages

by Thomas Mortagne

Hi devs, Since we are now depending on java 6 I think we should probably change our default all in one distribution to be based on javadb. I'm not going to do any quality comparison between javadb and hsqldb and this package is not supposed to be used in production anyway, the only thing I'm interested in here is: javadb is embedded in java 6 so using it instead of hdsqldb mean one jar less for the exact same features. WDYT ? -- Thomas Mortagne

13 years, 8 months

[xwiki-devs] Update the pull request for the test code of XWIKI-5560

by 许凌志(Jamesxu)

Hi, I have refined the test code of XWIKI-5560, and update the pull request, waiting for code review again. -- Best wishes, 许凌志(Jame Xu) MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University Department of Computer Science and Technology, Xi’an Jiaotong University

13 years, 8 months

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