October 2015 - xwiki-devs@xwiki.org

[xwiki-devs] [ANN] XWiki 7.3 Milestone 2 released
by Thomas Mortagne 29 Oct '15

29 Oct '15

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

1 0

[xwiki-devs] [Proposal] Extract the DocumentTree macro from the Index App
by vincent＠massol.net 27 Oct '15

27 Oct '15

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

5 9

[xwiki-devs] [Proposal] Register global wiki macro at wiki level when the macro document is in a subwiki
by Denis Gervalle 27 Oct '15

27 Oct '15

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

5 6

[xwiki-devs] Status about Hidden pages + Future direction
by vincent＠massol.net 27 Oct '15

27 Oct '15

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

5 7

[xwiki-devs] [Brainstorming] Best practices regarding nested XClasses
by Marius Dumitru Florea 23 Oct '15

23 Oct '15

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

2 1

Re: [xwiki-devs] [Contrib] Repository request for a "Rights UI Simplifier"
by vincent＠massol.net 21 Oct '15

21 Oct '15

Hi Paul, On 21 Oct 2015 at 12:05:10, Paul Pantiru ([email protected](mailto:[email protected])) wrote: > Hi, > > Some users consider the rights manager to be a bit to complex, so the purpose of this extension is to offer an alternative (simplified, even though it will have less options), while still keeping access to the more advanced (i.e. the default ui). While the concept for the new ui is still subjected to change, it will probably be basted on dropdown menus with predefined options like (view, view edit and comment etc.). > > Regarding the name, we will stick to "Rights UI Simplifier" and for the repo, unless someone proposes a better prefix than application, we will stick to "application-rightsui-simplifier". > Sorry about the private jira reference. So the idea is not to simply the existing Right UI but to add another UI. And I guess you’ll implement it as wiki pages. So I propose instead: "application-simplerights" I don’t think we need UI in the app name since that’s implied already. And I don’t think we need the “ier” suffix since it’s about providing a new UI and not making modifications to the existing one. WDYT? Thanks -Vincent > Thanks, > Paul > > > > On Tue, Oct 20, 2015 at 3:51 PM, [email protected](mailto:[email protected]) wrote: > > Hi Paul, > > On 20 Oct 2015 at 14:05:30, Paul Pantiru ([email protected](mailto:[email protected])(mailto:[email protected])) wrote: > > > > > Hello devs, > > > > > > I would like a repository on https://github.com/xwiki-contrib for the > > > extension I'm working on. The purpose of this is to make a simplified UI > > > for the rights manager, based on a client project (The jira issue for this > > > would be https://jira.xwikisas.com/browse/MUT-8 ). > > > > Errr… You’re posting on a public mailing list and you’re referencing some company-private and protected JIRA issue… :) > > > > > The name of the repo should be something on the lines of > > > "application-rightsui-simplifier", however I feel that this is not a very > > > appropriate name, since is not necessary an application, but a ui modifier > > > of the rights manager, so any input on the name would be very much > > > appreciated. > > > > What is your extension doing exactly? How does it plug into XWiki? > > > > > I would also like a jira project for this app. > > > > I can create this for you once we define the proper name. > > > > Thanks > > -Vincent > > > > > Thanks, > > > Paul Panțiru > > >

3 5

[xwiki-devs] [Contrib][Proposal] XWebIDE - Logical tree view
by Yann Flory 21 Oct '15

21 Oct '15

Hello devs, Thank you for your participation in the ranking of XWebIDE features, it was very helpful to determine the next steps. The three most important features, based on the results, were: - (TABS) Ability to use several tabs in the Web IDE (Done) - (LOGICAL_TREE) Ability to switch to a Logical tree view of all the elements of an application (sheets, JSX, SSX, Macros, Translations, etc) - (PAGE_RELATED_ELEMENTS) Show links to related elements in the tree: jsx, ssx, macros, sheet and includes used in the edited page. A new version with tabs has been released (v0.8) and now we have a proposal for the Logical tree view. You can find it on the design page: http://design.xwiki.org/xwiki/bin/view/Proposal/XWebIDE+Application+Improve… What do you think about that tree? Thanks, Yann

2 1

[xwiki-devs] [Proposal] Deprecating SpaceDocs and Spaces panels
by vincent＠massol.net 20 Oct '15

20 Oct '15

Hi devs, I’ve implemented http://jira.xwiki.org/browse/XWIKI-12599 and as part of this issue I needed to handle the SpaceDocs Panel, and we also need to handle the Spaces panel. Here’s my proposal: * In general we should list only Panels that work for the Nested Pages (NP) mode in the Panel Wizard (i.e. not show any Panels containing the word “Space” in their title or content). The rationale is that the majority of uses of XWiki will be for NP. * We should continue to provide Panels that work for the Nested Spaces (NS) mode (e.g. SpaceDocs, Spaces), but as extensions on e.x.o and not bundled by default in XE * However we shouldn’t break existing XWiki instances and thus I’m proposing this: ** Deprecate the SpaceDocs and Spaces panels by displaying a message (when the user is Admin), trying to push the move to the newer Panels (Children, Siblings and Navigation panels). For example, this is what I’ve done for SpaceDocs: https://www.evernote.com/l/AHfvmKs-DSZBh4IJf1Wp7VV5JfK2pEmfgME Note that this allows Admins to see that message in the Panel Wizard too and thus not be tempted to use them. ** Keep the deprecated Panels for 1 full cycle (i.e. remove them in XWiki 9.0, i.e. move them to xwiki-contrib at that time). Basically a similar strategy than for young apis. WDYT? Thanks -Vincent

3 4

[xwiki-devs] [Contrib] Repository request for a "Rights UI Simplifier"
by Paul Pantiru 20 Oct '15

20 Oct '15

Hello devs, I would like a repository on https://github.com/xwiki-contrib for the extension I'm working on. The purpose of this is to make a simplified UI for the rights manager, based on a client project (The jira issue for this would be https://jira.xwikisas.com/browse/MUT-8 ). The name of the repo should be something on the lines of "application-rightsui-simplifier", however I feel that this is not a very appropriate name, since is not necessary an application, but a ui modifier of the rights manager, so any input on the name would be very much appreciated. I would also like a jira project for this app. Thanks, Paul Panțiru

2 1

[xwiki-devs] [Proposal] Rename the "Page" column to "Page Title" in the LT for AllDocs + Children/Siblings
by vincent＠massol.net 16 Oct '15

16 Oct '15

Hi devs, I’d like to rename the Page column to Page Title to avoid confusion with the previously called Page column which has been moved to the Location column. (see http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki73M2#HPag… for details). It’s also more accurate IMO. WDYT? Thanks -Vincent

4 6