xwiki-devs August 2014

xwiki-devs@xwiki.org

29 participants
65 discussions

[xwiki-devs] [Proposal] Automatic creation of objects with HTTP parameters

by Jean SIMARD

Hi devs, In XWiki, if you send a POST request at the following URL ('MySpace.MyPage' is a document that doesn't exist at the moment) /bin/save/MySpace/MyPage with the following HTTP parameters: * template=MySpace.MyTemplate * XWiki.XWikiRights_0_users=XWiki.Me * <others parameters> with 'MySpace.MyTemplate' a template document and 'XWiki.Me' a user of the wiki. 2 cases: 1. If 'MySpace.MyTemplate' contains a 'XWiki.XWikiRights' object, then the resulting document 'MySpace.MyPage' will have this object with its property 'users' initialize with the value 'XWiki.Me' (see HTTP parameters) 2. If 'MySpace.MyTemplate' does not contain a 'XWiki.XWikiRights' object, the resulting document 'MySpace.MyPage' will not contain it either ### PROPOSAL Create automatically the objects if they don't exist in the template document. ### To make it possible, it seems that we would need to refactor the method 'readObjectsFromForm(EditForm, XWikiContext)' in the 'com.xpn.xwiki.doc.XWikiDocument' class. And probably modify also the 'getObject(String)' from 'com.xpn.xwiki.web.EditForm' class. 2 things to take care: * It seems there is no unit test for these methods. * May this proposal be a security problem? WDYT? -- Jean

9 years, 5 months

[xwiki-devs] [Proposal] Split XE pages into platform modules

by Vincent Massol

Hi devs, Here's a proposal to move pages currently located in XE into platform modules: * ColorThemes/*.xml --> xwiki-platform-colorthemes * Main/Activity.xml --> xwiki-platform-activitystream-ui (move current xwiki-platform-activitytream into xwiki-platform-activitystream-api) * Main/AllDocs.xml (and XWiki.Tableview, XWiki.Treeview, XWiki.OrphanedPages, XWiki.AllAttachments*, XWiki.DeletedDocuments, XWiki.DeletedAttachments and all pages used by those) --> new xwiki-platform-navigation module * Main/RssFeeds.xml --> new xwiki-platform-help module or xwiki-platform-rss-ui module (see below) * Main/SpaceIndex.xml --> xwiki-platform-navigation * Main/Spaces.xml --> xwiki-platform-navigation * Main/UserDirectory.xml --> xwiki-platform-user-ui * Main/WebHome.xml --> xwiki-platform-dashboard-ui * Main/WebRss.xml --> new xwiki-platform-rss-ui module, we would create a xwiki-platform-rss-api module too where we will move the feed plugin * Main/Welcome.xml --> move to xwiki-platform-dashboard-ui since it's a dashboard gadget which we could consider as a default widget * Sandbox/*.xml --> xwiki-platform-sandbox module (or xwiki-platform-help module) * XWiki/XWikSyntax.xml --> xwiki-platform-help module * XWiki/AttachmentSelector.xml --> xwiki-platform-user-ui or new xwiki-platform-attachmentselector module * XWiki/ClassSheet, ClassTemplate, ObjectSheet, XWikiClasses, * XWiki/GadgetClass.xml --> xwiki-platform-dashboard-ui * XWiki/LiveTableResult*.xml --> new xwiki-platform-livetable module * XWiki/MessageStreamConfig.xml --> new xwiki-platform-messagestream-ui module (and move xwiki-platform-message in xwiki-platform-message-api module) * XWiki/RequestsStatus.xml --> xwiki-platform-administration module or remove from platform till we integrate it in the Admin as an admin tool somewhere since right now I think it's available in the Admin tools application * XWiki/RequiredRightClass.xml --> since it's used in lots of other ui modules I'd propose to move it in java code as a class created on startup. Alternatively start creating a xwiki-platform-rights-ui module (or xwiki-platform-permission-ui module) and move it there * XWiki/SharePage.xml --> not sure…. maybe in a xwiki-platform-share or xwiki-platform-sharepage module * XWiki/TemplateProvider*.xml --> xwiki-platform-administration for the moment * XWiki/WebHome.xml --> xwiki-platform-administration module * XWiki/WebPreferences.xml --> xwiki-platform-administration module WDYT? Please try to tell me if you're ok for each line if you have time ;) Thanks -Vincent

9 years, 6 months

[xwiki-devs] Inject Warning in Page when Macro in Space not exists

by Matthias Wegner

Hi All, i want to put a {{warning}} in the header of a page when a specific macro is not contained. How can i do that. I tried in a Listener when the needed Macro-Block is not contained with doc.getXDOM().getRoot().addChild(new WordBlock("{{warning}}Warning Text.{{/warning}}")); context.getWiki().saveDocument(doc, context); This not works. What is the correct way to manipulate the Document DOM on Load? Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Inject-Warning-in-Page-when-Macro-in-Spac… Sent from the XWiki- Dev mailing list archive at Nabble.com.

9 years, 6 months

[xwiki-devs] Overwrite Method of Component in Velocity

by Matthias Wegner

Hi All, I want to create a component where i can overwrite a method of the component from velocity or groovy script inside a wiki page. Its also fine if i can "read" a groovy script to the component so i can use the defined logic. Maybe i have to use a own programmed macro for that. Is that possible? Do you use something similar somewhere? Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Overwrite-Method-of-Component-in-Velocity… Sent from the XWiki- Dev mailing list archive at Nabble.com.

9 years, 6 months

[xwiki-devs] Questions about fixing getRenderedContent() bug

by Vincent Massol

Hi, Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274 Basically if you do $xwiki.getDocument("someDoc").getRenderedContent() it'll get executed in the context of the current doc which I believe is wrong especially since other signatures of getRenderedContent() execute in the target document's context. I have fixed this locally but found that admin.vm for example is assuming that getRenderedContent() will get executed in the context of the calling doc (i.e. XWiki.Import when doing an import for example). FYI the chain flow is admin.vm -- getRenderedContent() --> XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which requires the current doc to be XWiki.Import (to get/put attachments from/to it). I can fix this easily using a new getRenderedContent signature I've introduced. However I'm wondering if we have other places that incorrectly use getRenderedContent() and assume it won't be rendered in the context of the target document. Is this change too dangerous to make? If not know, we'll need to it quickly (2.1M1?) since it's an important bug IMO. WDYT? Thanks -Vincent

9 years, 6 months

[xwiki-devs] [VOTE] Have extension repositories in the "xwiki" GitHub Organization

by vincent＠massol.net

Hi devs, Following the proposal thread at http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on. Rationale/Need =============== The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc * Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features). Governance ========== Details: * Extensions are VOTEd in on a case by case basis. * Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other). * When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization. * FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise. * The Git repository name should be of the form xwiki-<short project name>. <short project name> should be part of the VOTE. * All rules from http://dev.xwiki.org apply * Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes. * Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership). If not then either they’re ok to send Pull Requests or the extension should not be moved. * If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE * We would create one JIRA project per extension * We would create a new JIRA Category called “XWiki Extensions” * We would put the extensions in our CI at http://ci.xwiki.org * The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.<short project name>. Exceptions would need to be discussed. * The group id for extensions having their own repo should be org.xwiki.<short project name>. The <short project name> needs to be part of the VOTE when proposing a new extensions. Here’s my +1 Thanks -Vincent

9 years, 9 months

Re: [xwiki-devs] Semester of Code

by vincent＠massol.net

Hi Scott, This is a great idea, I love it! :) Speaking for myself, I’d really like to see the XWiki project participating to it. What do we need to do to participate? Thanks a lot -Vincent On 14 Jul 2014 at 18:36:15, Scott Wilson (scott.bradley.wilson@gmail.com(mailto:scott.bradley.wilson@gmail.com)) wrote: > Hi everyone, > > I'm working with an initiative similar to Google Summer of Code, called Semester of Code, and I think it would be great to have students work on XWiki. Below is more detailed information, but basically its like GSoC, except students are involved as part of their courses or industrial placements, so receive academic credit rather than money for their work. > > Hopefully this is of interest to the XWiki community! > > If any questions aren't answered by the FAQ[1] or invitation below, feel free to ask. > > All the best, > > - Scott > > ~~~ > > The VALS Semester of Code [1] project is working with European universities and FOSS communities to give students real-world experience working in open source software projects while receiving academic credit. The benefit to your projects will be valuable and hopefully ongoing contributions. VALS will also benefit the wider sector by helping to produce graduates with the skills and experience needed to engage with open development. > > Our first Semester of Code will involve approximately 75 student placements, starting in September. We would like to invite your organisation to participate in this pilot by offering mentored placements within your projects. > > If you have participated in Google Summer of Code before, you will find our process similar; we will seek placements for student projects, and will use the a system similar to Google's Melange platform to manage placements. However, VALS differs from Summer of Code in that instead of receiving money for their participation, students will receive academic credit. For this reason the mentors from your project will need to liaise with the student's academic tutor. The VALS project will support this process to ensure it runs as smoothly as possible. We also ensure the admin overhead is minimal. > > The VALS initiative is a partnership of European universities and SMEs who have been working for several months to plan the pilot of Semester of Code, which will run during the next academic year. We have now reached the stage where we are signing up FOSS projects who are willing to provide mentors. We have already seen interest from smaller, single-company projects to larger software foundations, and would like to see more. > > If you'd be willing to provide one or more mentored projects, we’d love to talk to you about joining Semester of Code. In return, you’ll get an enthusiastic student providing a valuable contribution to your project. The VALS team will be on hand throughout the project to answer any questions and help unblock communication issues between mentors, students and academic supervisors. > > To join in the Semester of Code or to simply find out more you can email mark.johnson(a)it.ox.ac.uk, or you can sign up to our mailing list directly by using the web form [1]. > > More detail about the Semester of Code are available on our FAQ page [2]. If you have any other questions, don’t hesitate to ask on the mailing list, and one of the VALS team will get back to you! > 1: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=VALS-SOC&A=1 > 2: http://semesterofcode.com/?p=22 > > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

9 years, 10 months

[xwiki-devs] [Contrib] Request repository for Recruitment Application

by Alexandru Chelariu

Hello, I would like to request a repository on xwiki-contrib for the Recruitment Application i am working on. I'd like the repo to be named application-recruitment and also jira component. My github username is chalx. Thank you, Alexandru Chelariu

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs August 2014