On Wed, May 2, 2018 at 6:02 PM, Marius Dumitru Florea <mariusdumitru.flo...@xwiki.com> 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 > > > Solution 2: Blacklisting > > Add support for specifying a list of (top level) pages to exclude from the > navigation panel. > > 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 > * 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 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. > > 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. > > > 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).
Maybe a slightly better default criteria could be "extension page with type denying edit" (which means things like Main.WebHome won't be hidden by default). > 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). > > 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 Isn't this going to be a pain for pagination too since it's based on an information which is not stored in the database ? > > > I prefer solution 4. > > WDYT? > > Thanks, > Marius -1 for 1) -- Thomas Mortagne
