I prefer solution 4, that's the more intuitive. You just should add a button to enable/disable the filter, so if you really need to see everything, you can. To me it's simple and cover 99% of everyday usages.
+1 for S4. Thanks, 2018-05-03 17:20 GMT+02:00 Anca Luca <[email protected]>: > Hello all, > > so, if I remember correctly, the navigation panel is just a call to the > documentsTree macro. Unless otherwise specified, my remarks below are about > the documentTree macro features. > > On Wed, May 2, 2018 at 6:02 PM, Marius Dumitru Florea < > [email protected]> wrote: > > > Hi devs, > > > > Some users have complained that the navigation panel shows top level > pages > > that they don't need/want to navigate to, most importantly the XWiki > page. > > > > There are multiple ways in which we can fix this. > > > > Solution 1: Content Page > > > > Create a top level "Content" page for user content and configure the > > navigation panel to show the contents of this page. > > > > Pros: > > * Namespace isolation (no conflicts between user pages and application > > pages) > > > > Cons: > > * The user may want to navigate to a top level application page (although > > it's better to use the application panel for this instead) > > * All the paths / references used to access the user content will start > > with this "Content" page > > > > The documentTree macro already has this feature, actually, to be able to > start in a given root and I thought about this solution (manually > implemented with a custom documentTree with a custom root). > However, I think it's too restrictive (to force all content to be rooted in > "Content") and in order to technically make it happen you'd need to change > too many places of XWiki: the create, copy and move screens (when location > is chosen) in order to make sure that user does not create content > somewhere else. > > > > > > > > Solution 2: Blacklisting > > > > Add support for specifying a list of (top level) pages to exclude from > the > > navigation panel. > > > > Most of the usecases I had fall into this category, with blacklisting only > at root level (if this makes it easier to implement or doesn't introduce > perf. issues). > So to me the pages to exclude would be a feature of the documentTree macro > (which can also be used as a gadget on a dashboard). > > > > > > Pros: > > * The user (top level) pages created later on will be visible in the > > navigation panel > > * The blacklist could be used to filter not only top level pages but also > > any nested page from the navigation panel. > > > > Cons: > > * The blacklist depends on the installed apps. The administrator may have > > to update the blacklist when new applications are installed > > > > Actually, this is a feature :) : any page (be it extension or user created > content) is whitelisted until an administrator decides that it should not > be in the tree. Note that it's the administrator that installs extensions > on a wiki, and at least in theory it's not done every morning. For the > management of the blacklists of the navigation panel (what navigation panel > will pass to the documentTree macro), we can use an administration section, > just like we do for what the applications panel displays by default :D. In > addition, it would be consistent with what we already have! > > > > * The blacklist depends on whether you view hidden pages or not. If you > > don't view hidden pages then the blacklist probably contains 4 pages: > Help, > > Menu, Sandbox, XWiki (there is an application panel entry for each of > them > > except XWiki), which is manageable. If you view hidden pages then you > need > > to black list 28+ pages which is hard to manage and maintain. > > > > The fact that you see too many pages when you activate hidden pages in your > profile is a problem that is not specific to the tree, so it shouldn't > surprise anyone that the tree also shows too many things. > To me, seeing hidden pages is not a "regular user in production" setting, > it's mostly for setup / development phase. > > > > * The filtering needs to happen on the database (otherwise we break the > > pagination) so the database queries will become a bit more complex, which > > could led to some performance penalty, depending on how long the > blacklist > > is. > > > > > > Solution 3: Whitelisting > > > > Add support for controlling the list of top level pages that are > displayed > > in the navigation panel. > > > > this is the same principle as blacklisting (only "reversed"), and as far as > I can project now, it already has a workaround: having multiple > documentTree calls with the root parameter set and showroots to true. > Also, the default create button of the wiki creates pages on the root of > the wiki, next to "Main" and this would mean that the administrator would > need to update the navigation panel any time a page is created, which is > way more often than "any time an extension is installed". > > > > > > 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. > > > > err, how? The create button displayed on the homepage - the only create > button that you see when you start on an empty wiki - creates top level > pages! (there's actually a bug in 9.11.3, I explicitly changed the location > to the "Home" page, and it still created a toplevel page). > > Indeed, if the administrator has an idea about what would be put on the > wiki, he can create the toplevel pages, but 1/ it's not always the case, 2/ > he might not want to, leaving users to organise their content as they wish. > > > > * the whitelist controls only the first level in the tree. The next > levels > > will be dynamic (database queries) and with the default order. > > > > > > Solution 4: Exclude extension pages > > > > Exclude from the navigation panel the top level pages that belong to an > > installed extension, allowing the administrator to make some exceptions > > (e.g. keep the home page). The rationale is that if an installed > extension > > has a top level page then that page is most probably the application home > > page which should be accessible from the application panel. This can be > > implemented on top of solution 3 (the whitelist is basically dynamic: we > > collect the top level pages that don't belong to an extension). > > > > This is _very_ close to the cases I had, but the difference between > "exactly" and "very close" is relevant, to me: obviously, some XWiki, > Sandbox and other standard content needed to be removed, but also a custom > page that I had created and manually put in the application panel. > > So, in my opinion, the work to do this is comparable to the work for > implementing explicit blacklisted roots, so between this and 2, I choose 2. > > Long story short: > I believe, as Vincent said, that we need to have the generic whitelist / > blacklist parameters for the documentTree macro, in order to cover the > maximum cases possible, and in my opinion, they all exist, because there is > a great diversity in what users can do on the wiki but also in how they > interpret some things: some people see applications as "special", some > others don't, etc. > > For the navigation panel default blacklist we can make some dynamic > computing of the parameters we pass to the documentTree call, e.g. all > extensions, or some configuration in administration. > > As a priority choice between blacklist and whitelist, I would choose > blacklist, as some sort of whitelist already exists, even if not fully > complete and anyway it covers less "user content" cases than the blacklist > one. > > Thanks, > Anca > > > > > > Pros: > > * It does a clear separation between applications (accessible from the > > application panel) and content (accessible from the navigation panel). > The > > navigation panel is currently mixing application pages and (user) content > > pages. > > * The administrator doesn't need to update the navigation panel > > configuration to exclude a top level application home page each time an > > application is installed > > * The hidden top level extension code pages are not shown even when "show > > hidden pages" is set to true > > * The user top level pages created later on appear in the tree > > automatically > > > > Cons: > > * The user won't be able to navigate easily to an application home page: > > ** if the application panel is not shown > > ** or if the application doesn't provide an application panel entry > > ** or if the administrator has removed the entry from the application > panel > > > > > > I prefer solution 4. > > > > WDYT? > > > > Thanks, > > Marius > > > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
