xwiki-devs June 2015

xwiki-devs@xwiki.org

20 participants
47 discussions

[xwiki-devs] Solr search use cases regarding nested spaces

by Marius Dumitru Florea

Hi devs, As we started to work on addind support for nested spaces, we need to think about search use cases that we expect the Solr search to cover regarding nested spaces. Currently, with one level of space, we support: UC1: Search for documents in space X (exact match) UC2: Search for documents in a space like X (free text search) With nested spaces we need to take into account several new use cases: UC1: Search for documents that are direct children of the path X.Y.Z (exact match for path) -> matches X.Y.Z.Page but not X.Y.Page and neither X.Y.Z.A.Page UC2: Search for documents that are descendents of the path X.Y.Z (exact match for path) -> matches X.Y.Z.Page and X.Y.Z.A.Page but not X.Y.Page UC3: Search for documents that have space X as parent anywhere in the hierarchy (exact match for space) -> matches A.X.Page and X.Page but not A.X.Y.Page UC4: Search for documents that have space X as ancestor anywhere in the hierarchy (exact match for space) -> matches X.Page and A.X.Y.Page but not Y.Z.Page UC5: Search for documents that have the path like X.Y.Z (free text search) -> matches X.Page, Z.Y.Page, Y.Z.X.Page UC6: Search for documents that have the parent space like X (free text search) Do you see any other use cases? Is any of the use cases I listed not useful, and can be discarded? Thanks, Marius

9 years, 6 months

[xwiki-devs] [Proposal] Introduce the notion of Nested Documents

by Guillaume "Louis-Marie" Delhumeau

Hello XWiki committers. Vincent have proposed the development of nested spaces for 7.2 and some of us have already agreed. But the concept of nested spaces introduces a problem that Denis have mentioned during some internal discussions at XWiki SAS, and that I am going to report here. >From a UI perspective, differentiating pages `A.B.C.WebHome` and `A.B.C` could become very difficult. Moreover, we know that a lot of users do not understand the notion of spaces, and they are lost when you look at them during usability sessions. The situation is even worse if you consider the notion of parent/child documents, which is completely unrelated to the actual hierarchy. It creates confusion! To fix these problems, we propose to introduce the notion of "nested documents", i.e. the ability to create documents inside documents. Say differently, if a page `A.B.C` exists, nothing should stop the user to create the document `A.B.C.D`. In JCR[1], there is only one concept: the "node". A node can have a content, and a list of child nodes. In XWiki, documents could become a kind of nodes, and we do not need spaces anymore. If we don't have space anymore, we could ask ourselves: "How the rights will be propagated to the children documents? How do we distinguish rights applied to the documents and the rights applied to the children?" I think the easiest solution is to inherit the rights from the parent to the children, unless an object prevent it. We already have this kind of mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would be applied for the current document, and XWikiGlobalRights for the document and its children. But changing the XWiki model is a lot of work, that we don't have time to achieve for 7.2. So we propose to make it step by step. The first step is to change the UI to hide the notion of space to the users. Concretely, each time a user wants to create a page called `A`, we actually create the document `A.WebHome`. So any child of this page would be created in the `A` space, like `A.Child`. But this child would be in a space too, so it would be `A.Child.WebHome` actually. Then, when we display the `A.WebHome` page, we remove all mentions to the `WebHome` name. In the UI, it will just be presented as the document `A`. This is a good point, knowing the fact that the term `WebHome` have no sense for the user, neither in English or in other languages. Again, these changes are only for the UI. For the applications, it is the developer's job to decide if the app will create documents like `Document.WebHome` or basic documents just as before. The question of what to do with AWM comes up. When a user creates an entry, should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an old-kind-of-document (`AppSpace.Entry`)? The first option is good for consistency and for the new possibilities it offers, but the second is better for retro-compatibility. And the question will be the same for all existing applications that create pages. I believe we should answer these questions on a case-by-case basis and deserve their own mail threads. This proposal also implies to change some macros, like the {{space}} one, and some panels. But I believe there is no blocking-point there. Finally, after these steps are accomplished in 7.2 and polished until the end of the 7.x cycle, we will refactor the XWiki model (something we dream about for years). To sum up, the idea we propose is: On the short run: - Hide the notion of space in the UI. - Hide the `WebHome` name in the UI. - When a user creates a page from the UI, it actually creates a space with a WebHome. - Remove the current parent/child mechanism which is outdated (and confusing) compared to the new hierarchy. On the long run: - Remove the notion of space in the model, and replace it by "nested documents". - Tune the rights system to inherit rights from parents to children. Of course, we can discuss the technical details and the implementation strategies. But for now, we need to know if you accept the general idea (nested documents). So, I hope you will like this proposal, and here is my +1. Thanks, Guillaume D. [1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

9 years, 6 months

[xwiki-devs] Improvements proposals for a gallery photo

by Cray xWiki

Dear all, For reminder, we are a groupe of four students working on a XWiki photo gallery improvements under the supervision of Ludovic Dubost. Please find on the link below (in the attachments section) a benchmark of Photo Albums and our requirements including wireframes and mock ups : http://design.xwiki.org/xwiki/bin/view/Proposal/PhotoAlbumBenchmark Feel free to give us feedback an our work and give us your opinion. We are open to any suggestions you may have Thank you in advance. Best regards, CRAY team

9 years, 6 months

[xwiki-devs] XE distribution still growing

by vincent＠massol.net

Hi devs, Not sure we want to do anything about it but just wanted to point out that our XE distribution is still growing in size, see https://www.evernote.com/l/AHeoW5wLif9LwqNbItVqgFUOuiHipy8rINA Two questions: * Why is 7.1 bigger by 14MB than 7.0. Probably some JARs we updated like SOLR. Could be interesting to check. * Why are 6.4.x releases smaller than 6.4? Probably some JAR update too. Anyway this is more a FYI, I’m not proposing any plan ATM. Thanks -Vincent

9 years, 6 months

[xwiki-devs] [ANN] XWiki 7.1.1 released

by Guillaume "Louis-Marie" Delhumeau

The XWiki development team is proud to announce the availability of XWiki 7.1.1. This is a stabilization release that fixes important bugs discovered in the 7.1 version. 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/ReleaseNotesXWiki711 The following people have contributed code to this release: - Vincent Massol - Guillaume Delhumeau Thanks for your support -The XWiki dev team

9 years, 6 months

[xwiki-devs] [VOTE] Drop support for IE8/IE9 in 7.x

by Ecaterina Moraru (Valica)

Hi, One year ago (Mar 2014) [1] we discussed dropping support for IE8 for the 6.x cycle. The vote did not pass. Since then, we started the support for IE10/IE11 (Jun 2014) [2]. You can see some statistics and the current browsers we support at http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy This mail is about voting the drop of support for IE8/IE9 for cycle 7.x. WDYT? My +1 Thanks, Caty [1] http://markmail.org/thread/es5ghym4gphlj4mz [2] http://markmail.org/thread/mzvcovh2da2t4e3w

9 years, 6 months

[xwiki-devs] [VOTE] Drop support for Colibri Skin in 7.x

by Ecaterina Moraru (Valica)

Hi, This mail is about dropping support for Colibri Skin [1]. Colibri Skin has been developed in version 2.0 (Sep 2009) and used as a default Skin until version 6.2 (Sep 2014), when it was replaced by Flamingo Skin [2]. Colibri is still supported for 6.x branch (currently we are developing version 6.4.5). Since the Flamingo Skin had stabilized, I propose we drop support for Colibri Skin in 7.x, in order to focus on Flamingo. This means the improvements and bugfixes will not be mandatory to be ported on Colibri anymore. We can still have Colibri bundled for one more cycle and after we can retired it. WDYT? Here is my +1 Thanks, Caty [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Colibri+Skin [2] http://extensions.xwiki.org/xwiki/bin/view/Extension/Flamingo+Skin [3] http://design.xwiki.org/xwiki/bin/view/Proposal/SupportSkin

9 years, 6 months

[xwiki-devs] [ANN] XWiki 7.1 released

by Ecaterina Moraru (Valica)

The XWiki development team is proud to announce the availability of XWiki 7.1 This release adds important changes and improvements for Extension Manager, Solr Search, Watchlist, a new experimental Flavors mechanism and a Debug mode for performance analysis. Extension Manager provides a summary for the extension diff view in order to ease the navigation of the local code changes. A new Extension History section has also been added, offering support for selective export, import and replay of extension-related history records. Solr Search UI is improved by making it responsive on small screens. The users can now sort, paginate and filter the search results without a page reload. The Flavors and Watchlist Realtime option are currently still experimental, but you are encouraged to test them and provide feedback. The WatchList performance has been improved, especially for the Realtime notification option. The Realtime Watchlist messages are displayed in a more user-friendly way, sending mails for a variety of events, threaded by your email client by the document they occurred in. The Flavor mechanism is allowing the selection of Flavors in the wiki creation step. In the future, XWiki will offer different Flavors and these are steps towards this direction. Under-the-hood there are various mail and job module improvements. The developers can now trigger old Prototype event listeners from jQuery and a new API is available to escape wiki syntax. 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/ReleaseNotesXWiki71 The following people have contributed code to this release: Thomas Mortagne Vincent Massol Guillaume Delhumeau Eduard Moraru Marius Dumitru Florea Denis Gervalle Sergiu Dumitriu Manuel Smeria Gabriela Smeria Ecaterina Moraru (Valica) Anca Luca Jean SIMARD Clemens Robbenhaar Thanks for your support -The XWiki dev team

9 years, 6 months

[xwiki-devs] [Proposal] Change the naming of Programming Right

by vincent＠massol.net

Hi devs, With the intoduction of http://jira.xwiki.org/browse/XWIKI-12171 (Add a script right to manage script macro execution permissions) in 7.2, we should also think about renaming what we call "Programming Right" (PR for short) since "Script" and "Programming" are close. At least to change that in the UI (and possibly even at API level by introducing new methods ands deprecating old ones). First step would be to find a new name. I can think of: * Privilege Right (nice thing is that PR is still valid ;)) http://dictionary.reference.com/browse/privilege "a right, immunity, or benefit enjoyed only by a person beyond the advantages of most:". This would mean that people with the Privilege Right would be able to use Privileged APIs. * System Right * God Right My preference goes to "Privilege" or "Privileged". WDYT about 1) Changing the name 2) The new name to use if you agree with 1) ? Thanks -Vincent

9 years, 6 months

[xwiki-devs] [Nested Spaces] Database Model design and issues

by vincent＠massol.net

Hi Devs, At http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces#HDatabaseModel I have started drafting some naive impl for Nested Spaces. I believe Edy has provided some other links with probably more elaborate algorithms that we should study (such as http://www.slideshare.net/billkarwin/models-for-hierarchical-data). In any case I’ve also started a Problem section at http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces#HProblems where I’ve listed one item FTM. I’m pasting it here: “ * For ex if you do HQL (or you use an extension that does) like {{code}}where doc.space = 'somespace'{{/code}} and add a parent or child Space for ##somespace## then the query will not return anything anymore since you can have something like ##parent.somespace.child## in the DB in the ##space## column (since we store the full space reference in there for NS). ** Solution 1: Rewrite the queries to use something like {{code}}where doc.space = 'somespace' or doc.space like '%.somespace'{{/code}}. ** Solution 2: Don't modify the ##space## column and add a ##spaceReference## one. This is not perfect in case there are several spaces named ##somespace## ** Solution 3: ?? “ I’d be curious to know what you think about it and if you have ideas. Feel free to list other problems you can see there and your ideas for solving them. Thanks -Vincent

9 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs June 2015