Re: [xwiki-devs] [Brainstorming] Issue with removed Parent/Child Relationship

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 < gdelhumeau(a)xwiki.com&gt; wrote: 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. 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. 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. 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