2015-09-15 12:02 GMT+02:00 vincent(a)massol.net <vincent(a)massol.net>et>:
On 15 Sep 2015 at 11:59:03, Ecaterina Moraru (Valica) (valicac(a)gmail.com
(mailto:valicac@gmail.com)) 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 <
> > mariusdumitru.florea(a)xwiki.com> 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, vincent(a)massol.net <
> vincent(a)massol.net
> > >
> > > > wrote:
> > > >
> > > >>
> > > >>
> > > >>
> > > >> On 2 Sep 2015 at 13:34:27, Marius Dumitru Florea (
> > > >> mariusdumitru.florea(a)xwiki.com) wrote:
> > > >>
> > > >> On Mon, Aug 24, 2015 at 4:09 PM, vincent(a)massol.net <
> > vincent(a)massol.net
> > > >
> > > >> wrote:
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On 24 Aug 2015 at 14:21:19, Marius Dumitru Florea (
> > > >> mariusdumitru.florea(a)xwiki.com(mailto:
> mariusdumitru.florea(a)xwiki.com
> > ))
> > > >> 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
> > > >> devs(a)xwiki.org
> > > >>
http://lists.xwiki.org/mailman/listinfo/devs
> > <
>
https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?ur…
> >
> > > >>
> > > > _______________________________________________
> > > > devs mailing list
> > > > devs(a)xwiki.org
> > > >
http://lists.xwiki.org/mailman/listinfo/devs
> > <
>
https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?ur…
> >
> > > _______________________________________________
> > > devs mailing list
> > > devs(a)xwiki.org
> > >
http://lists.xwiki.org/mailman/listinfo/devs
> > <
>
https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?ur…
> >
> > >
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> >
http://lists.xwiki.org/mailman/listinfo/devs
> > <
>
https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?ur…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the