Hi Caty, > On 3 May 2018, at 10:58, Ecaterina Moraru (Valica) <[email protected]> wrote: > > On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < > [email protected]> 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 [snip] > 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
