Hi Denis, On Tue, Sep 29, 2015 at 11:56 PM, Denis Gervalle <[email protected]> wrote:
> On Tue, Sep 29, 2015 at 4:54 PM, Guillaume Lerouge <[email protected]> > wrote: > > > Hi Denis, > > > > thanks for your message. Please see my thoughts below. > > > > On Tue, Sep 29, 2015 at 11:12 AM, Denis Gervalle <[email protected]> wrote: > > > > > Hi devs, > > > > > > I am opening this discussion to move the discussion started in an issue > > > (XWIKI-12628) to its proper place, the ML. (Discussing into JIRA is > very > > > bad since it lower the audience, we tend to have done it too much > > > recently). > > > > > > So the issue is that, in the Nested Document concept, we can create > > > children to inexistent (WebHome) page. This introduce some > abnormalities: > > > - Administering inexistent page (including page rights, see > > > http://jira.xwiki.org/browse/XWIKI-12629) > > > - Children of inexistent page (see > > > http://jira.xwiki.org/browse/XWIKI-12628 > > > ) > > > > > > Since we agree that having nodes in the tree of pages is fine without > > > having the intermediate document created, > > > > > > I know that's what has been decided so far, but I was wondering what was > > the rationale behind it? Is there a specific benefit that comes from > > allowing this behavior? > One use case I've thought of since yesterday: when you move a page within a hierarchy without moving its children. For instance: say you have "A/B/C" and "D/E/F", then you move "B" to the end of "D/E/F" without moving B's children. You end up with "D/E/F/B". However, you probably still want to have something where "B" used to be in "A/B/C", but with no content in there. Thus the need. > > > we definitely need to better show > > > this concept to the final user. It would be a pain to explain to a user > > > that access rights for page children of an inexistent page is > > administrable > > > from that inexistent page. It is also very poor when you navigate from > > the > > > breadcrumb to a inexistent page as a normal user to reach "The > requested > > > page could not be found." with no way to navigate further. > > > > > > > Agreed. > > > > These inexistent page are not necessarily invisible, there are links to > > > them, and showing that as "error" page looks inappropriate IMO. > > > > Agreed. > > > > > > > So there are probably a couple of things we could do to improve this: > > > > > > A) display the list of children in addition to the actual message > > > > > > > As you point out below, this doesn't fully solve the navigation problem > > since you can only go down, not further up. > > That's not fully true, since you have the breadcrumb. What I do not like, > is that it looks first as an error page, then propose a way out. IMO those > "empty" node are not errors, just nodes without content, just there for > supporting their children. > Ok, I hadn't understood that the breadcrumb would still be shown. > > B) display a "default" and nice (not an error) dashboard on them that > > allow > > > navigation (with a button for those that can edit, to create the page) > > > C) create them all the time, with the dashboard above by default > > > > > > > To me, B) and C) are almost the same in the end, though I'm not sure a > > dashboard is best. I'd rather create an empty page, with the list of > > children available from the menu and/or in a tab in the footer, as on > every > > other standard page. > > > > > > > D) do not propose links to those page in the breadcrumb to users > without > > > edit right on them ? > > > > > > > How would you then display the breadcrumb? With holes in it? It would > also > > make the breadcrumb inconsistent with the URL. > > > > All I was proposing here is to remove the link, not the text, so you cannot > click on them to reach them. I agree, this is far from a perfect solution, > but since we have the Sibling viewer, it is not really breaking the > navigability of the site. I was just suggesting here a way that limit the > situation where a normal user reach those page, that could also be seen as > useless to reach (else the user should had create it). Any other place with > a link to those page should be treated the same. So only user with the > ability to really act on those pages (administering or creating them) will > have link to access them. > I see. Indeed, this could work. Thanks, Guillaume > > > > E) ... (please add more idea) > > > > > > I am in favor of B) currently, since I do not think we are in an > "error" > > > case like A) seems to expose. > > > I am wondering if D) could be useful as well to limit navigation to > those > > > page or not for user that will not find them so useful... but it may > > exists > > > opposite UC. > > > > > > WDYT ? > > > > > > > I think my favorite one is C). I don't really like having pages that > exist > > from a rights management and hierarchy standpoint but not from a content > > standpoint - but maybe there's a good reason for this that I'm missing? > > > > Thanks, > > > > Guillaume > > > > -- > > > Denis Gervalle > > > SOFTEC sa - CEO > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Denis Gervalle > SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
