October 2014 - xwiki-devs@xwiki.org

[xwiki-devs] improve flamingo menu?
by Pascal BASTIEN 13 Oct '14

13 Oct '14

Hello If javascript on browser is disabled or (a javascript function crashed) flamingo menus is not expandable anymore... It is possible to write a expandable/collapsed menu in pure CSS(without javascript) to avoid that. WDYT? Perhaps you already think about that... Menu in pure CSS will generate more problems? Pascal B

5 6

[xwiki-devs] [Contrib] [Notice] Renaming 'application-forum2' to 'application-forum'
by Ecaterina Moraru (Valica) 13 Oct '14

13 Oct '14

Hi, This mail is sent for reference and gardening purposes. The following actions have been made: * https://github.com/xwiki-contrib/application-forum has been deleted ** This repo was created on 6 July 2011 by mpaun, but never released. It contained 2 commits (readme and pom.xml), but nothing beside that. Deleting it in order to preserve xwiki-contrib clean. * https://github.com/xwiki-contrib/application-forum2 has been renamed to the now available https://github.com/xwiki-contrib/application-forum Thanks, Caty

1 0

[xwiki-devs] [XWiki Day] BFD#65
by Eduard Moraru 10 Oct '14

10 Oct '14

Hi devs, Today is BFD#65: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays For the 1 year period we are at 114 bugs behind, we really need to catch up. See: http://jira.xwiki .org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-Resolved-Chart/10470 Here's the BFD#65 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12692 Thanks and happy bug fixing! -Eduard

2 3

[xwiki-devs] IE9 and flamingo
by Pascal BASTIEN 10 Oct '14

10 Oct '14

Hello, This bug on Xwiki 6.2.1 seem to be still there: XWIKI-10664: "Strange behaviour of the panels layout using the WYSIWYG editor, Flamingo, and IE9" and it is tagged "fixed on 6.2rc1"... http://jira.xwiki.org/browse/XWIKI-10664 I tested with 6.2.1 jetty package on Win7 and IE9. Thanks you. Pascal B

2 1

[xwiki-devs] Fwd: [Discussion] New location of the "Add" menu in the new Flamingo skin
by Guillaume "Louis-Marie" Delhumeau 08 Oct '14

08 Oct '14

Hi. I have done the "test-on-my-wife" thing :) She finds it more intuitive to add a page from the current page, so in the current location, instead of the "black bar that gives the impression of not beeing a part of that page" (that she did not manage to find by herself). I then explained that the buttons inside the page only concern the actions that you can do on that page, meanwhile adding a new page should be put in an other location. She did not like this logic :) Users' logic and developer's logic are not the same. I like the current location too, except that we should propose "create page" before "create wiki". I really would like to have some feedback of normal users, with the 2 proposals. We, as developers, are not good at making things that look simple for other people, so we should not take this decision alone. Thanks, -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 22

[xwiki-devs] [Discussion] What the "templates" directory should contain?
by Guillaume "Louis-Marie" Delhumeau 08 Oct '14

08 Oct '14

Hi. Since 6.2, we have the following issue: http://jira.xwiki.org/browse/XWIKI-11027 "The templates directory has VMs from Colibri". Until now, we used to have all *.vm files in this directory, and nothing in the "colibri" one, because Colibri was the default skin. Now that Flamingo is the default skin, we have to decide what we do with this directory. Should we move all Flamingo's files in that directory? Should we only put the files that Colibri & Flamingo have in common? I have reported a list of problems that these decisions make, on the Jira. Actually, the "templates" directory seems to mean that we should put only "generic" templates. But what does it mean? Most of the files depends on the skin, so they are not generic. Except some files for the Distribution Wizard that should not be skin-dependent. What do you think about it? Thanks, -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

4 11

[xwiki-devs] [Contrib] Request repository for Recruitment Application
by Alexandru Chelariu 08 Oct '14

08 Oct '14

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

4 3

[xwiki-devs] [Brainstorming] Issue tracking for xwiki-contrib projects
by vincent＠massol.net 07 Oct '14

07 Oct '14

Hi everyone, ATM the rule we have for contrib projects is to use JIRA (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HHostingtools) I’ve heard that some people have been proposing using other trackers. So I’d like to poll your opinion on the following alternatives: Option A: all projects use JIRA =============================== This is the current option in use. Pros: * A single place for people to view and search for issues in the XWiki Ecosystem Cons: * For XWiki admins, creating a new JIRA project takes 5 minutes Option B: all projects use GitHub issues ======================================== Pros: * Simple to set up for admins (hosted by GitHub) * Simple to use (too simple sometimes?) Cons: * No single place to search all issues related to XWiki (both JIRA + GitHub) * No single place to report JIRA issues * Tied to the SCM choice. When we stop using Git as our SCM and move to the next SCM tool we’ll have to import all issues (see https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-i…) * Need to implement feature on extensions.xwiki.org to add a link to the issue tracker for each extension Option C: let each project decide ================================= Pros: * Simple to set up for admins when project decides on GitHub Cons: * No single place to search all issues related to XWiki (both JIRA + GitHub) * No single place to report JIRA issues * Tied to the SCM choice. When we stop using Git as our SCM and move to the next SCM tool we’ll have to import all issues (see https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-i…) * Need to implement feature on extensions.xwiki.org to add a link to the issue tracker for each extension Option D: XWiki Task Manager ============================ http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Applicati… Pros: * Eat our own dog food. * Forces us to improve this extension Cons: * Pressure to fix bugs * Increases volume of data on xwiki.org and thus impact performances * Maintenance cost: More work when upgrading xwiki.org * No single place to search all issues related to XWiki (both JIRA + GitHub) * No single place to report JIRA issues * Need to implement feature on extensions.xwiki.org to add a link to the issue tracker for each extension WDYT? Other options? Personally and based on all pros/cons I think the best ATM is really Option A. And if we really want, it’s possible to improve the cons by doing a bit of java coding: https://developer.atlassian.com/display/JIRADEV/Creating+a+Project+Template Thanks -Vincent

10 27

[xwiki-devs] [Proposal] HomePage Application
by vincent＠massol.net 07 Oct '14

07 Oct '14

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

7 16

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

03 Oct '14

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.

1 0