3 May
2018
3 May
'18
1:03 p.m.
Hi Caty,
[snip]
On 3 May 2018, at 10:58, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
[snip]
Solution 3: Whitelisting
Add support for controlling the list of top level pages that are displayed
in the navigation panel.
Pros:
* the whitelist doesn't depend on the installed extensions or hidden pages
so it's easier to maintain.
* the whitelist can be used to order the top level pages visible in the
navigation panel.
* the whitelist can be used to show at the top level (for navigation
purpose) a page that is not really a top level page
* No performance penalty
Cons:
* The user (top level) pages created later on will not be visible in the
navigation panel. The administrator will have to add them to the whitelist
if they are useful for the navigation. Although creating top level pages
should happen less often than creating nested pages under the existing top
level pages.
* the whitelist controls only the first level in the tree. The next levels
will be dynamic (database queries) and with the default order.
S3: I prefer this solution, but with the ability to also display some
dynamic pattern, something like: display X, Y and all children of Z, or
all pages starting with A, or all pages created by group N :) (they are
just ideas, I know some are very hard to implement).
+1 I prefer solution 3, but with the ability to sort and
also to include some
dynamic parts :) is this possible?
Thanks,
Caty
FTR I don’t like solution 3 alone because I find it a bit less useful than blacklisting.
If the need is to display only some known elements in the Nav, it’s already possible (not
easy though ;)) to create your own Nav tree.
IMO the difficulty is when users want to benefit from the automatic navigation for new
pages (they’re listed by default) but they also want to control things they don’t want to
see in the navigation (not because they necessarily want to hide them in the wiki for
everyone to see but because it’s a navigation and they want to not display some parts that
are less important - ie not provide a top level nav to them).
This is why I’m advocating to have both a blacklist and a whitelist so that we can support
all use cases. If this is doable technically then it’s the best solution. Now the Nav tree
already has an issue: it’s very slow. So we need to fix this slowness and yet be able to
filter with a whitelist and a blacklist too :)
I guess it depends if we want to fix the configurability issue for good or only fix some
aspects of it (ie. XWiki space, Home space, apps when they’re installed).
[snip]
Thanks
-Vincent