xwiki-devs October 2014

xwiki-devs@xwiki.org

19 participants
67 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

10 years

[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

10 years, 1 month

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

10 years, 1 month

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

10 years, 1 month

[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

10 years, 1 month

[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

10 years, 5 months

[xwiki-devs] Home Page - Use cases, proposals, what we have until now and what we want to achieve

by Eduard Moraru

Hi devs, We have already had some discussions recently on how we can improve XWiki's homepage. After talking to Vincent in private, we have decided to come up with a set of use cases/goals[1] that we want to have/achieve with the improvement of the homepage so that we make sure that we all speak the same language and consider all use cases when proposing something. On the same page as the use cases[1], you have a link below for the existing proposals[2] and each proposal that was discussed until now (I added one too) is listed and compared to the use cases it had to cover. Please have a look and tell us what you think about the use cases and the analysis of each proposal. This is not yet a vote, but just an attempt to get everybody on the same boat in terms of expectations. Thanks, Eduard ---------- [1] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageUseCases [2] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals

10 years, 5 months

[xwiki-devs] [Discussion] About Icon Themes

by Guillaume "Louis-Marie" Delhumeau

Hi. In XWiki 6.2, we have introduced the Icon Theme Application [1]. The idea was to be able to use Font Awesome in the Applications Panel without breaking all extensions. So we have a mapping between silk icons (that the extensions used until now) and the font awesome equivalents [2]. But, of course, the mapping is currently incomplete. For 2 reasons: 1/ It takes time to make it perfect (so feel free to improve it, directly on the wiki page! [2]) 2/ Some silk icons have no equivalent. Where a silk equivalent is missing, the Icon Theme Application automatically failbacks to the Silk icon, so something appears. Of course, it does not look very good when all icons are monochromatic except only one [3]. When there is no equivalent, we could have a strategy to not failback on Silk but instead using the most similar icon in Font Awesome. For example http://www.xwiki.org/xwiki/resources/icons/silk/flag_blue.png and http://www.xwiki.org/xwiki/resources/icons/silk/flag_green.png can both be mapped to http://fortawesome.github.io/Font-Awesome/icon/flag/ . But it would be problem if an extension use both icons to represent 2 different actions. In my opinion, we should not do this and let the failback-process happens. But actually, having this mapping should be only used for backward compatibility. What I want to propose is about the future. We should not use the silk icons anymore with the hope that it will be correctly mapped in other icon themes. What I want to create, is our own list of icons. The XWiki icon set. But I am not talking about drawing new icons. I am talking about create an official mapping for the icons we support and that have a mapping in all existing icon themes. For example, I have create the "wiki" icon, which is mapped to http://www.xwiki.org/xwiki/resources/icons/silk/world.png in silk and on http://fortawesome.github.io/Font-Awesome/icon/globe/ in font-awesome. I believe we need to create that list and create a documentation about it somewhere (maybe in a page integrated in XE, but at least on the extension page). So when a user create an application, she no longer chose an icon from the Silk collection but from our own list. If we agree on that principle, we also need to agree on a convention about the name of our icons. I propose: 'some-name' which means everything in lower case and words separated by '-'. I hope you'll like the idea. Thanks, [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Icon+Theme+Application (The Icon Theme Application) [2] http://design.xwiki.org/xwiki/bin/view/Proposal/IconSet (The mapping) [3] http://tof.canardpc.com/view/debc907e-d1ee-4e01-baff-dc740801e68d.jpg (Problem) -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

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

10 years, 5 months

[xwiki-devs] [Brainstorming] Add Export UI for space-level + homogenisation

by vincent＠massol.net

Hi devs, <bad idea but kept for the sake of the discussion> Now that I’ve implemented http://jira.xwiki.org/browse/XWIKI-11337 I was wondering if it would be a good idea to have 2 menu entries (they would be visible only for admins by I think): - Export Space (in the Space menu of the navbar) - Export Wiki (in the Wiki menu of the navbar) When you click on them they would open a popup similar to the one that opens when you click on Export Page but with 2 options only ATM: XAR and HTML (since these are the 2 that support exporting at space and wiki levels). Now when the multipage export UI is ready, click on any Export (page level, space level or wiki level) would open that UI with a preselection (current page, current space or current wiki selected). We would also need to decide what to do with the Export screen of the Admin UI: Would it be dropped in favor of the “Export Wiki” menu action? </bad idea but kept for the sake of the discussion> <more thinking happened here… :)/> <better idea> More generally speaking we need to think about Admin actions and where we want them. I don’t think it’s a good idea to start putting more and more admin actions in menus. Actually what we should probably do is generalize the concept of the Admin UI at all levels: Page level, Space level and Wiki level. Thus I think I’d prefer the following: - Add an Export admin UI screen at the space level for exporting only a space as XAR - Introduce an admin UI screen at page level too and start moving features in there. I can think of at least 2: Export Page, Page level rights </better idea> WDYT? Thanks -Vincent

10 years, 5 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2014