Hi, I also proposed the parent-child override implementation option a while ago, mainly because I believe there will always be people wanting to have a shortcut in the breadcrumbs without the need to move pages around and/or changing a page's URL in the process. On Wed, Jul 22, 2015 at 3:18 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
I am not too keen on the mixed solution, because we are going to remove the top menu navigation as we know it. So the breadcrumb will be the only way to identify where you are in the wiki.
Actually, we have been discussing the tree navigation (while clicking or expanding the home root element in the breadcrumbs) that would be in charge of displaying the page's location.
With the mixed solution, the breadcrumb will not show you the exact location of the current page.
Even with the tree navigation, I agree that it would be awkward to see one thing in the tree (actual location) and another thing just millimeters above in the breadcrumbs (location mixed with parent overrides), so the user might be easily confused, not knowing which one to trust. If we try to fix this by showing the same thing (reference + parent overrides) in the tree navigation, we end up creating a mess that I would prefer we stay away from.
It's a problem, because then it's harder to set rights on parent spaces : do they impact the current page or not?
Yeah, if we start doing it (reference + parent overrides) everywhere in the UI (where we use trees), but not also in the rights checking/applying, then we will be completely inconsistent.
So I'm -0 about this and more in favour if removing this use-case.
+0 for having it as an optional behaviour (but I wonder who will change the option just for this use case).
I also agree that the best call would be to no longer support shortcuts in the breadcrumbs and only base it on references, so +1 for that. Applications are free to call setParent and getParent in their logic to store and retrieve stored parents, but the standard UI (breadcrumbs) will just ignore it. This allows existing apps to use the parent-child relationship for any other purposes except breadcrumbs. Extreme workaround for apps insisting on simulating the same behavior: Manually add a wiki syntax page link inside the document's content so that the user can click it from the document's rendered content. The upside is that this link will be maintained if the linked document is moved/renamed. Thanks, Eduard
Thanks,
2015-07-22 14:12 GMT+02:00 [email protected] <[email protected]>:
On 22 Jul 2015 at 14:29:46, [email protected] ([email protected]
(mailto:
[email protected])) wrote:
Hi devs,
I’ve analyzed the issue of Nested Spaces on the IRC Bot application ( http://jira.xwiki.org/browse/XWIKI-12341) and I’ve found some interesting use case.
Use case: * An Application lets the user configure where to save pages the application generates or the Application simply generates pages in some space other than the app space. * We want the breadcrumb of the generated pages to point to the App’s home page
Before NS: * We’re calling setParent(“.WebHome”)
After NS (the problem!): * We’re loosing the link to the app’s home page since the breadcrumb is currently using references…
So the question is: how do we solve this use case?
I don’t have many answers. I can think of only 1 ATM:
* Keep the ability to set the parent in the Edit page UI * When displaying the breadcrumb for a page, check if the page has specified a parent and if so, uses it instead of the reference parent. * Possibly remove the configuration option to disable parent/child relationship and always use the parent when set, and the reference when not set up.
WDYT? Any idea for supporting this use case or for doing it differently?
The other option is to drop this use case…
Yet another option is to make the breadcrumb behavior configurable and have 3 implementations (for ex): * pure reference-based * pure parentchild-based * mixed reference + parent child override
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs