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
> > 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 :)
Another reason is if you want to delegate the administration (choose the skin,
color theme, permissions, etc).
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
> >
> > On Wed, Sep 2, 2015 at 5:07 PM, Eduard Moraru
> > 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
> > > > 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
> >
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
