9 May
2018
9 May
'18
11:42 a.m.
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 <lucaa(a)xwiki.com>om>:
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 <
mariusdumitru.florea(a)xwiki.com> wrote:
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
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