On Mon, Sep 14, 2015 at 6:36 PM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote: > 2015-09-14 17:42 GMT+02:00 Guillaume Lerouge <[email protected]>: > >> 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 >> > > That is wrong. The rights DO inherit between the main wiki sub-wikis, at > least since the Denis' module has been written.
Yes rights are is inherited since 4.0. Most authenticators also usually fallback on main wiki. So right now there is a hierarchy relationship between main wiki and sub-wikis at least in several important places. > > >> 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. 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 >> >> On Wed, Sep 2, 2015 at 5:07 PM, Eduard Moraru <[email protected]> >> wrote: >> >> > Because of the "Subwikis" pseudo-element? Even so, still looks better in >> > that direction. >> > >> > In any way, I am not sure we even want to (or even can) be 100% >> consistent >> > with the breadcrumbs, because the breadcrumbs only show a single path in >> > the tree and does not care about scaling horizontally in the tree >> hierarchy >> > (i.e. siblings). However, an actual tree view would suffer from the >> > scalability issues you`ve mentioned because the root can have both >> subwikis >> > and documents as it's first level children, so I believe a compromise is >> > inevitable. >> > >> > ATM we have these 2 options: >> > >> > 1. Lose the hierarchy between the main wiki and display it as a regular >> > subwiki, and the user should guess (or find out through some visual cues, >> > like an icon or something... or simply because of the name) that one of >> > them is the main wiki. There would also be scalability issues in finding >> > the main wiki amongst 30 other wikis. Sure, search/filtering would be a >> > solution, but I am afraid that such an operation would be language >> > dependent (searching for a translated string). >> > 1.1 Note that we would also lose the breadcrumb's hierarchy information >> for >> > subwikis, since we would not be showing the main wiki in te breadcrumbs >> any >> > more, to be consistent with the tree. A sort of revert to what we were >> > previously doing. >> > >> > 2. Lose a fraction of the consistency by having the extra "Subwikis" (or >> > call it whatever we want) pseudo-element showing up in the tree that will >> > not be displayed in the breadcrumbs, though I am not sure anybody would >> > want/like to see such an entry in the breadcrumbs of any subwiki >> document. >> > >> > Other ideas? >> > >> > That's all I got right now. >> > >> > Thanks, >> > Eduard >> > >> > On Wed, Sep 2, 2015 at 4:19 PM, Marius Dumitru Florea < >> > [email protected]> wrote: >> > >> > > On Wed, Sep 2, 2015 at 4:15 PM, Eduard Moraru <[email protected]> >> > > wrote: >> > > > Would this be viewed as an improvement? >> > > > >> > > > Home >> > > > |-- Subwikis >> > > > |---- Sub Wiki 1 >> > > > |---- Sub Wiki 2 >> > > > |---- ... >> > > > |---- Sub Wiki N >> > > > |-- Document 1 >> > > > |-- Document 2 >> > > > |-- ... >> > > > |-- Document N >> > > > >> > > > ...same logic we apply for objects, and attachments in a document. >> > > >> > > Still not consistent with the breadcrumb. >> > > >> > > > >> > > > Of course, when displaying the tree only for Sub Wiki X (isolated), >> > there >> > > > would be no "Subwikis" entry as first child. That would be the >> > difference >> > > > when displaying a subwiki or when displaying the main wiki. >> > > > >> > > > I`m not 100% on this, just mentioning a possibility. >> > > > >> > > > Thanks, >> > > > Eduard >> > > > >> > > > On Wed, Sep 2, 2015 at 3:22 PM, [email protected] < >> [email protected] >> > > >> > > > wrote: >> > > > >> > > >> >> > > >> >> > > >> >> > > >> On 2 Sep 2015 at 13:34:27, Marius Dumitru Florea ( >> > > >> [email protected]) wrote: >> > > >> >> > > >> On Mon, Aug 24, 2015 at 4:09 PM, [email protected] < >> > [email protected] >> > > > >> > > >> wrote: >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > On 24 Aug 2015 at 14:21:19, Marius Dumitru Florea ( >> > > >> [email protected](mailto: >> [email protected] >> > )) >> > > >> wrote: >> > > >> > >> > > >> >> Hi devs, >> > > >> >> >> > > >> >> I recently discussed with Edy about how the breadcrumb should >> look >> > > and >> > > >> >> there may be an inconsistency with the hierarchy displayed by the >> > > >> >> document tree. >> > > >> >> >> > > >> >> Breadcrumb on the main wiki: >> > > >> >> >> > > >> >> Home Icon (pointing to the main wiki home page) / MDoc1 / MDoc2 / >> > > ... / >> > > >> MDocX >> > > >> >> >> > > >> >> Breadcrumb on a subwiki (that has only global users): >> > > >> >> >> > > >> >> Home Icon (pointing to the main wiki home page) / Subwiki Pretty >> > Name >> > > >> >> (pointing to the subwiki home page) / SDoc1 / SDoc2 / ... / SDocX >> > > >> >> >> > > >> >> After seeing the breadcrumbs both on the main wiki and on a >> subwiki >> > > >> >> the user might think that the document MDoc1 and the wiki >> "Subwiki >> > > >> >> Pretty Name" are on the same level: both children of the main >> wiki. >> > > >> >> >> > > >> >> Next if the user tries the document tree macro using: >> > > >> >> >> > > >> >> {{documentTree showWikis="true" /}} >> > > >> >> >> > > >> >> he will notice that "Subwiki Pretty Name" is not actually a child >> > of >> > > >> >> the main wiki but a top level node (a child of the "farm"), on >> the >> > > >> >> same level with the main wiki. >> > > >> >> >> > > >> >> Can this be considered as an inconsistency? In our model (e.g. >> > > >> >> document reference) there is no hierarchy between wikis, >> although, >> > as >> > > >> >> Edy pointed out, there are places where we consider the main wiki >> > to >> > > >> >> be the "parent" of the subwikis (e.g. in the authorization >> module, >> > by >> > > >> >> inheriting access rights from the main wiki). >> > > >> >> >> > > >> >> WDYT? Is the main wiki the parent of the subwikis or just a >> > sibling? >> > > >> > >> > > >> > Good question and indeed we need to decide what we want to do >> since >> > we >> > > >> have the 2 options. >> > > >> > >> > > >> > Personally I think it’s interesting to mark the main wiki as >> special >> > > >> since it is special (accounts there are different than on subwikis) >> so >> > > I’d >> > > >> be in favor of considering subwikis as children of the main wiki. >> > > >> > >> > > >> >> Should the breadcrumb be synchronized with the tree? >> > > >> > >> > > >> >> > > >> > I’d say the other way around. The tree should probably show the >> main >> > > >> wiki as the parent of all subwikis. And when there’s only one wiki >> (ie >> > > the >> > > >> main wiki), we could simply not show the wiki level for simplicity. >> We >> > > >> could also decide to open the tree to the level below the main wiki >> by >> > > >> default so that users don’t have to open it themselves. >> > > >> >> > > >> I find it strange to display: >> > > >> >> > > >> Home >> > > >> |-- Sub Wiki 1 >> > > >> |-- Sub Wiki 2 >> > > >> |-- ... >> > > >> |-- Sub Wiki N >> > > >> |-- Document 1 >> > > >> |-- Document 2 >> > > >> |-- ... >> > > >> |-- Document N >> > > >> >> > > >> Not to mention the pagination. If there are too many subwikis then >> you >> > > >> may not see the documents initially. I much prefer the current >> > > >> display. >> > > >> I would find it painful to have to open the tree for nodes that you >> > need >> > > >> to open anyway. >> > > >> >> > > >> Another idea: when you click on Document Index from a menu, the Tree >> > > opens >> > > >> on the current doc. >> > > >> >> > > >> Thanks >> > > >> >> > > >> -Vincent >> > > >> >> > > >> >> > > >> >> > > >> Thanks, >> > > >> Marius >> > > >> >> > > >> > >> > > >> > Thanks >> > > >> > -Vincent >> > > >> > >> > > >> >> >> > > >> >> Thanks, >> > > >> >> Marius >> > > >> _______________________________________________ >> > > >> devs mailing list >> > > >> [email protected] >> > > >> http://lists.xwiki.org/mailman/listinfo/devs >> > < >> https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url=http%3A%2F%2Flists.xwiki.org%2Fmailman%2Flistinfo%2Fdevs&signature=5e2b6f767b5ff9fb >> > >> > > >> >> > > > _______________________________________________ >> > > > devs mailing list >> > > > [email protected] >> > > > http://lists.xwiki.org/mailman/listinfo/devs >> > < >> https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url=http%3A%2F%2Flists.xwiki.org%2Fmailman%2Flistinfo%2Fdevs&signature=5e2b6f767b5ff9fb >> > >> > > _______________________________________________ >> > > devs mailing list >> > > [email protected] >> > > http://lists.xwiki.org/mailman/listinfo/devs >> > < >> https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url=http%3A%2F%2Flists.xwiki.org%2Fmailman%2Flistinfo%2Fdevs&signature=5e2b6f767b5ff9fb >> > >> > > >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> > < >> https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?url=http%3A%2F%2Flists.xwiki.org%2Fmailman%2Flistinfo%2Fdevs&signature=5e2b6f767b5ff9fb >> > >> > >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Guillaume Delhumeau ([email protected]) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
