On Wed, May 2, 2018 at 7:24 PM, Thomas Mortagne <[email protected]> wrote:
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
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).
Good point! We should do this indeed.
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 ?
Well, in this case (only for the top level) will do the pagination in Velocity. I think it's OK because having thousands of pages at the top level is quite uncommon. The top level defines the "categories" (the buckets) where the users put content so it doesn't make sense to have many pages there at the top level.
I prefer solution 4.
WDYT?
Thanks, Marius
-1 for 1)
-- Thomas Mortagne