Hi, my main point was that in our current paradigm, there can be both spaces in the main wiki AND sub-wikis listed under the main wiki home page in the breadcrumb, which creates a consistency issue that isn't easy to fix.
On Tue, Sep 15, 2015 at 1:03 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote: > 2015-09-15 12:02 GMT+02:00 [email protected] <[email protected]>: > > > > On 15 Sep 2015 at 11:59:03, Ecaterina Moraru (Valica) ([email protected] > > (mailto:[email protected])) wrote: > > > > > On Mon, Sep 14, 2015 at 6:42 PM, Guillaume Lerouge > > > wrote: > > > > > > > Hi, > > > > > > > > I've been thinking a lot about this (while also considering the > > discussion > > > > about the "Main" space in the other discussion thread). To me, > ideally, > > > > there is one and only one hierarchy, which is consistent everywhere. > As > > > > discussed at length already, this poses a challenge for at several > > reasons: > > > > > > > > 1. Technically, there is no hierarchy relationship between the main > > wiki > > > > and sub-wikis. However, in practice the main wiki often plays the > role > > > > of a > > > > portal. > > > > 1. This means that rights will not be inherited between the main wiki > > > > and sub-wikis, which poses a coherency issue > Thanks for the clarification on this, I didn't know that rights from the main wiki were inherited by subwikis. > > > > 2. Having a global breadcrumb puts 2 different things at the same > level > > > > under the home page of the main wiki: top-level spaces in the main > wiki > > > > on > > > > one hand, sub-wiki home pages on the other hand > > > > 1. This is solved for some implementations by simply having one wiki, > > > > without any sub-wikis, and relying only on the nested spaces > > > > mechanism to > > > > handle things > > > > 2. A potential converse would be to have just a global home page, > > > > then use sub-wikis for everything (effectively eliminating the > > > > portal), but > > > > this would cause myriad of issues when using the global search, > > > > accessing > > > > user profiles and so on. > > > > > > > > In the end, I think what this boils down to is an ongoing conflict > > between > > > > 2 ways of organizing information inside of XWiki: > > > > > > > > 1. The Farm paradigm, where you create sub-wikis for everything > > > > 2. The Nested Spaces paradigm, where you have just one big wiki with > > > > spaces, sub-spaces and so on > > > > > > > > On a daily basis, it's already difficult to tell users when they > should > > > > create a sub-wiki versus a space. > > > > > > The reason IMO to want to create a sub-wiki is to have custom > > applications > > > installed and isolate/dedicate the subwiki to a team. > > > For any other reason, create a space :) > So if the marketing team wants their own app, they get a sub-wiki, but the sales team which didn't need an app got a space, and then you need to switch them to their own wiki? > > Another reason is if you want to delegate the administration (choose the > > skin, color theme, permissions, etc). > > > Nope, you can do that in a space too. To me it's still not so clear when one should be chosen and not the other :-) Guillaume > Thanks > > -Vincent > > > > > > This is going to be even harder with > > > > Nested Spaces. In my view, many of our discussions come from a > tension > > > > between these 2 ways of organizing content inside of XWiki. > > > > > > > > Obviously, going all in for one of these 2 ways would make choices > much > > > > simpler for the future but cause a retro-compatibility nightmare... > All > > > > this to say that I'm not sure which compromise is best for the > > breadcrumb > > > > :-) > > > > > > > > Food for thought, > > > > > > > > Guillaume > [SNIP] _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
