xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] Watchlist icons improvements

by Guillaume "Louis-Marie" Delhumeau

Hi. The other thread about the content menus re-organization has deviated to talk about the watchlist, so I prefer to continue the discussion on this new thread. I have made some mock-ups that you can see there: http://design.xwiki.org/xwiki/bin/view/Proposal/WatchListButtonsonXE73 WDYT? Thanks, -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

9 years, 2 months

[xwiki-devs] [Proposal] Improvements to the Create/Delete/Move/Rename UIs

by vincent＠massol.net

Hi devs, Some users have raised that when you click on the pencil icon in the Create/Delete/Move/Rename UIs, the user has to understand the “dot notation” (ie the reference notation) and that it’s not user-friendly for simple users. Here’s what I propose: 1) Only display the pencil icon (and thus the advanced controls) for Advanced Users. 2) Note that we were doing this initially but it was modified to fix http://jira.xwiki.org/browse/XWIKI-12526. The idea would be to fix XWIKI-12526 differently by modifying how we perform validation on the title field: if the title field is empty, don’t expand the location edit controls and just highlight the title field (for simple users). 3) (suggested by Edy): Introduce controls in the modal document picker (tree) for creating empty documents in place (similar to creating new folders in an operating system's folder picker, where you would create new folders until you achieve the hierarchy you desire). We could even think about using a template (e.g. space homepage) for these "placeholder" documents. E.g. http://i.stack.imgur.com/umdE9.png http://www.mclures.net/java/struts/Together/Struts-screenshots/create_proje… (contextual menu) etc... The advantage of this would be that it would make more sense to simple users and it would also be something they could use. Of course, one downside would be the extra empty/placeholder documents that it would create, but you have the same thing in a filesystem, more or less. WDYT? Thanks -Vincent

9 years, 2 months

[xwiki-devs] [Brainstorming] Feel like trying Gitter.im?

by vincent＠massol.net

Hi devs, I feel it would help the XWiki project if we had some chat infrastructure more user-friendly than IRC channel (which is currently mostly used by the xwiki developers and a few power contributors/users). I think it would help spread xwiki more and be more friendly to our community (btw the same should be done for the mailing list by moving the user mailing list to a forum but that’s for another thread). I wonder if you guys would be interested to moving to another tool such as Gitter.im: https://gitter.im/ It seems to be nice for open communities. Nicer than Slack anyway (I’ve tried Slack for another community I’m in and we quickly reached the 10K messages and it’s not nice to have this red reminder message and you loose some messages that you can’t see - See http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-and-we-deeply-r…). Of course another strategy would be to ask a company to host a tool for us, such as http://www.mattermost.org/ but setting it up and maintaining it has a price and we’d need to convince some company like XWiki SAS to do that and I’m not sure it’s worth it. Let me know what you think and if you’re ok to try it, I’ll set up an org on gitter so that we can make an experiment and try it out. Thanks -Vincent

9 years, 2 months

[xwiki-devs] ShortURLs on 7.2?

by Paul Libbrecht

Hello XWiki community, I moved to shortURLs. The tutorial has been nicely effective. The home page serves well, the entry page of my wiki and my space all work well. However, almost all the pages that are there now break at view (with or without the action /bin/view/ in the URL). Similarly, /download/ breaks with 404. These are mostly pages in confluence syntax but moving them to xwiki syntax doesn't change anything. They display: A problem occurred while trying to process your request. Please contact the webmaster if this happens again. Their link is obtained in the index or tree views. These pages work fine at /edit/, save, and /preview/. With some debugging I seem to reach the error that: "No row with the given identifier exists" (at XWikiHibernateStore.loadXWikiDoc). Could it be that the ReferenceSerializer is behaving differently with ShortURLs? That seems bad. Why would it be different in /edit/ action? Is it changed on 7.3 candidates? thanks in advance. Paul

9 years, 2 months

[xwiki-devs] [Contrib] Request for 'livetable-checkbox-column' contrib project

by Raluca Stavro

I would like to contribute a new extension that adds the option to select the rows of a livetable by inserting a new column with checkboxes in the table. See more details there : http://extensions.xwiki.org/xwiki/bin/view/Extension/Add+Checkbox+Column+To… . Can someone please create the "livetable-checkbox-column" on xwiki-contrib for me ? Thank you, Raluca.

9 years, 2 months

[xwiki-devs] [ANN] XWiki 7.3 Milestone 2 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 7.3 Milestone 2. This is the first of the 2 stabilization releases that happen at the end of each yearly Cycles. Lots of polishing has been done, especially for the recently introduced Nested Pages feature and its consequences on the UI redesign (modified menus for example). Some extensions started exploit nested spaces to bring some improvements. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki73M2 The following people have contributed code to this release: Clemens Robbenhaar Eduard Moraru Guillaume Delhumeau Marius Dumitru Florea Sergiu Dumitriu Thomas Mortagne Vincent Massol Thanks for your support -The XWiki dev team -- Thomas Mortagne

9 years, 2 months

[xwiki-devs] [Proposal] Extract the DocumentTree macro from the Index App

by vincent＠massol.net

Hi devs, I see that the DocumentTree macro is used more and more in several places (as it should) and I’d like to propose to extract the DocumentTree macro from the Index App. Proposal 1: =========== xwiki-platform-tree |_ xwiki-platform-tree-generic |_ ... |_ xwiki-platform-tree-document |_ ... Proposal 2: =========== xwiki-platform-index |_ xwiki-platform-index-ui |_ xwiki-plarform-index-tree |_ … WDYT? Any other proposal? Personally I prefer proposal 1. Thanks -Vincent

9 years, 2 months

[xwiki-devs] [Proposal] Register global wiki macro at wiki level when the macro document is in a subwiki

by Denis Gervalle

Hi devs, It looks like a bug to me, but wiki macro defined for global level in a subwiki, are effectively influencing the whole farm. I would like to change that like this: * global level macro are registered global only if defined in the main wiki * global and wiki level macro defined in a subwiki are registered at wiki level The rationals are: * if the same global macro document is deployed on more than one wiki, which just means the same extension defining that document is installed on multiple wiki, maybe in different version, all those macros will be in conflict, it will not be easy to know which one wins, and even more difficult to detect the problem in the first place. * there is risk (of course limited by the PR), that user of subwiki influence the behaviors of the whole farm, which IMO is quite opposite to the logical structure, and even the physical storage we are used to. * I do not see any benefit of putting a global macro in a subwiki wdyt ? -- Denis Gervalle SOFTEC sa - CEO

9 years, 2 months

[xwiki-devs] Status about Hidden pages + Future direction

by vincent＠massol.net

Hi everyone, I wasn’t sure about current rule for hiding pages so I researched it and I’m listing below what I believe is our current status. I’d like to document it on dev.xwiki.org if we’re ok with this status. Current rules: ============== * Technical documents must be hidden * Technical apps must be hidden and not appear in the Document Tree. These are apps that don’t generate content data. For example the following apps (not exhaustive list) have their pages hidden (including WebHome): ** Stats app ** Active Installs app ** AWM app ** Color Themes app (it generates data but not content data) ** Dashboard app ** Scheduler app * Apps that generate content pages (ie pages that should be appear in global search results) must have their WebHome page not hidden (and the generated content pages must also not be hidden). As a consequence these apps will appear in the Document Tree. Future: ======= It would also be nice to discuss if in the future we wish to separate more Apps from Content and hide all Application pages (including Webhome), so that it is less confusing for users who would: * Use the App bar to navigate to applications * Use the Document Tree to navigate to content pages I personally would like this I think but the current problem is that generated content pages won’t be found in global search results. Each app can provide a specialized search ofc but it’s not good enough. Thus we’d need to find a way for the entries to appear in the global search results even though they are hidden. One solution would be to have a way to mark a space as an application space and exclude those from the DocumentTree (for example). Before we dive into the solutions in details, would you agree that it would be good to better separate Apps from Content? Some Links: =========== * Currently documented best practices about hiding technical documents: http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… * Mail thread: http://xwiki.475771.n2.nabble.com/Brainstorming-Rules-for-hidden-documents-… * JIRA issue: http://jira.xwiki.org/browse/MOCCACAL-85 Thanks -Vincent

9 years, 2 months

[xwiki-devs] [Brainstorming] Best practices regarding nested XClasses

by Marius Dumitru Florea

Hi devs, While fixing XWiki.ClassSheet to work with classes defined in nested spaces, I realized that if the class is defined in a non-terminal (WebHome) document then XWiki.ClassSheet creates WebHomeSheet and WebHomeTemplate, which made me wonder: (1) Does it make sense to have a class defined in a non-terminal (WebHome) document? One good thing about it, I guess, is that we could group the sheet, template and any class related pages (e.g. translation page for class properties) under the class document itself. Path.To.DiagramClass |- Sheet |- Template This would be consistent with the old parent-child relationship were we use to set the class as the parent of the sheet and template. (2) What naming convention should we use for classes defined in non-terminal documents? If we keep the sheet and the template as (terminal?) siblings of the class then we should use the current naming convention: Path.To.DiagramClass.WebHome Path.To.DiagramSheet Path.To.DiagramTemplate If we nest the sheet and the template inside the class then we could have: Path.To.DiagramClass.WebHome <-- this is the class Path.To.DiagramClass.Sheet Path.To.DiagramClass.Template We could also group the class, sheet and template like this: Path.To.Diagram.Class Path.To.Diagram.Sheet Path.To.Diagram.Template i.e. when you create a class you create a space with 3 terminal documents. WDYT? Thanks, Marius

9 years, 2 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