3 May
2018
3 May
'18
10:58 a.m.
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)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
S1: This solution is good if users would work in isolation or in the
evaluation period, but for team and multiple people sharing spaces, I don't
see this as a valid solution.
-0
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.
S2: I see the blacklist solution more as a hack for things in XWiki that
should be fixed (have users outside XWiki space, move Sandbox into Help
space, hide Help pages and provide a dedicated Help entry in the User menu,
etc.) but we don't have the time to do it.
-0 in an ideal state
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
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).
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
S4: I don't know if for our users this separation between apps and content
is very clear. Also they might create their own apps and they will want
those to be part of the navigation. The ideal navigation should be able to
state some important pages to be shown (static aspect), order that list in
terms of priority, and later contain and navigate to pages created by the
user or team (dynamic aspect). Adding metadatas to pages and creating apps
on top of content is a major feature of XWiki and I don't want to remove
these pages from the navigation.
-0
I prefer solution 3, but with the ability to sort and also to include some
dynamic parts :) is this possible?
Thanks,
Caty
I prefer solution 4.
WDYT?
Thanks,
Marius