15 Sep
2015
15 Sep
'15
12:02 p.m.
On 15 Sep 2015 at 11:59:03, Ecaterina Moraru (Valica)
(valicac@gmail.com(mailto:valicac@gmail.com)) wrote:
On Mon, Sep 14, 2015 at 6:42 PM, Guillaume Lerouge
wrote:
Another reason is if you want to delegate the administration (choose the skin, color
theme, permissions, etc).
Thanks
-Vincent
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 :) 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:
mariusdumitru.florea(a)xwiki.com
subwiki
the
https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?ur…
https://mailtrack.io/trace/link/5cdaba15b1a0ee796e40340be950c6540850990f?ur…
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 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:
vincent(a)massol.net
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 <
> 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: ))
> >> 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 > >> >> 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 > >> >> 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
module,
>> >> Edy pointed out, there are
places where we consider the main wiki
to
> >> >> be the "parent" of the subwikis (e.g. in the
authorization by
since
>> >> 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 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
< >>
> _______________________________________________
> 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
<