Edgewall Software
Modify

Opened 15 years ago

Closed 12 years ago

Last modified 10 years ago

#4507 closed enhancement (fixed)

Improve behavior of hierarchical page names

Reported by: christian@… Owned by: Remy Blank
Priority: normal Milestone: 0.12
Component: wiki system Version: 0.10.2
Severity: minor Keywords: hierarchy patch
Cc: osimons Branch:
Release Notes:
API Changes:
Internal Changes:

Description

I was looking for release notes for trac 0.10.3, when I opened the URL http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/0.10 and figured that there might be another page for it. So I removed th "0.10" from the URL's end - and got the standard "describe this page" dialog.

I could certainly search for that page, but that's not what I expected, although I'm a somewhat experienced trac user. I'd assume that trac handled this more elegantly, i.e.:

  • notice that the requested page doesn't exist
  • query for page names matching the requested pattern
  • link to those pages from the "create new page" dialog
    • "However, there are pages with a name similar to the one you've been looking for: … print linked list of page names"

It could be standard functionality to put a list of matching page names in HDF so the current page could easily display a list of sub-pages. This also references #2149, #2150.

Attachments (3)

4507-scoped-wiki-links-r7455.patch (3.6 KB ) - added by Remy Blank <remy.blank@…> 13 years ago.
Patch against 0.11-stable making wiki TracLinks in wiki pages scoped
4507-scoped-wiki-links-r7557.patch (3.6 KB ) - added by Remy Blank 13 years ago.
Updated patch for current trunk
4507-scoped-wiki-links-r7578.patch (5.1 KB ) - added by Remy Blank 13 years ago.
Improved usability for creating hierarchical pages

Download all attachments as: .zip

Change History (32)

comment:1 by Christian Boos, 15 years ago

Keywords: hierarchy added
Milestone: 0.11
Owner: changed from Jonas Borgström to Christian Boos
Severity: normalminor

Interesting idea. I'll look into it for 0.11, as we want to improve support for Wiki page name hierarchies there (see also #4412).

comment:3 by Christian Boos, 15 years ago

#3021 was also requesting better support for "namespaces" in the TracWiki, and was closed as duplicate.

comment:4 by Christian Boos, 14 years ago

Milestone: 0.11.10.12

In order to better support "namespaces" (as in #3021 and #4412), I think it would be good that when resolving a Wiki page link, we first look in the local scope.

Example:

  • TracInstall referenced from within a page starting with the '0.11/' prefix should link to 0.11/TracInstall as that page exists
  • TracInstall reference from within a page starting with the 'TracDev/' prefix will link to the toplevel TracInstall, as TracDev/TracInstall doesn't exist
  • for disambiguation needs, it's possible to refer to the toplevel page using the ["/TracInstall"] or [wiki:/TracInstall] syntax

by Remy Blank <remy.blank@…>, 13 years ago

Patch against 0.11-stable making wiki TracLinks in wiki pages scoped

comment:5 by Remy Blank <remy.blank@…>, 13 years ago

Cc: remy.blank@… added
Keywords: patch added

The patch above makes wiki TracLinks in wiki pages scoped. Given the following pages:

  • FirstLevel
  • FirstLevel/SecondLevel
  • FirstLevel/SecondLevel/ThirdLevel
  • FirstLevel/SecondLevel/OtherThirdLevel

Then the links below, placed on FirstLevel/SecondLevel/ThirdLevel, resolve as follows:

  • FirstLevelFirstLevel
  • SecondLevelFirstLevel/SecondLevel
  • ThirdLevelFirstLevel/SecondLevel/ThirdLevel
  • OtherThirdLevelFirstLevel/SecondLevel/OtherThirdLevel
  • [wiki:/OtherThirdLevel]OtherThirdLevel
  • MissingPageMissingPage

The patch also adds a test case for the typical scenarios.

comment:6 by osimons, 13 years ago

Cc: osimons added

by Remy Blank, 13 years ago

Updated patch for current trunk

comment:7 by Remy Blank, 13 years ago

Owner: changed from Christian Boos to Remy Blank

Oops, I didn't notice the milestone for this ticket. The patch above is the same but for the current trunk. Feedback appreciated.

comment:8 by Christian Boos, 13 years ago

Milestone: 0.130.12

Patch looks great.

comment:9 by Remy Blank, 13 years ago

Thanks for the review. I'll apply it later this week, and also update the documentation.

by Remy Blank, 13 years ago

Improved usability for creating hierarchical pages

comment:10 by Remy Blank, 13 years ago

Cc: remy.blank@… removed

I wasn't too happy with the usability of the previous patch. This patch adds two improvements:

  • Non-existing pages link to a sibling page of the container page, instead of a top-level page. This means that, in the same situation as comment:5 (i.e. when a link is placed on FirstLevel/SecondLevel/ThirdLevel), the following mapping is done:
    • MissingPage -> FirstLevel/SecondLevel/MissingPage
  • When accessing a non-existing hierarchical page, in addition to to the "Describe … here." message, a list of links to the same page, but higher up in the hierarchy, is presented. For example, when viewing FirstLevel/SecondLevel/MissingPage, the following links are displayed:
    • FirstLevel/MissingPage
    • MissingPage

These improvement should make it easier to create the desired page.

I am not sure about one thing, though. Currently, the links on non-existing hierarchical pages point to the page viewer. Should they point to the editor instead (i.e. with action=edit)?

Comments welcome.

comment:11 by Remy Blank, 13 years ago

Resolution: fixed
Status: newclosed

Patch applied in [7685].

in reply to:  10 ; comment:12 by Christian Boos, 13 years ago

Resolution: fixed
Status: closedreopened

Replying to rblank:

  • Non-existing pages link to a sibling page of the container page, instead of a top-level page. This means that, in the same situation as comment:5 (i.e. when a link is placed on FirstLevel/SecondLevel/ThirdLevel), the following mapping is done:
    • MissingPage -> FirstLevel/SecondLevel/MissingPage

eblot recently reported to me a non-intuitive behavior, due to the above feature. Inside a page called "HwDocs/HwBoards", he was using the following links:

=== [wiki:HwDocs/HwBoards/B1 Board1] ===

=== [wiki:HwDocs/HwBoards/B2 Board2] ===

=== [wiki:HwDocs/HwBoards/B3 Board3] ===

The following HTML was generated:

<h3 id="Board1"><a class="wiki"
href="/trac/sdk/wiki/HwDocs/HwBoards/B1">Board1</a></h3>
<h3 id="Board2"><a class="wiki"
href="/trac/sdk/wiki/HwDocs/HwDocs/HwBoards/B2">Board2</a></h3>
<h3 id="Board3"><a class="missing wiki"
href="/trac/sdk/wiki/HwDocs/HwDocs/HwBoards/B3"
rel="nofollow">Board3</a></h3>

HwDocs/HwBoards/B1 exists and is correct, HwDocs/HwDocs/HwBoards/B2 also exists, but was wrongly created at that location when the link looked like the one for Board3.

What about having HwDocs/HwBoards/xyz behave like ./xyz here, as we're on the ! HwDocs/HwBoards page? Perhaps more generally, when a sub-path correspond to some existing page higher in the hierarchy of the current page, chances are that one wants to target a page starting from there. E.g. in the same HwDocs/HwBoards page, HwDocs/Overview would point to /HwDocs/Overview.

in reply to:  12 ; comment:13 by Remy Blank, 13 years ago

Replying to cboos:

What about having HwDocs/HwBoards/xyz behave like ./xyz here, as we're on the HwDocs/HwBoards page? Perhaps more generally, when a sub-path correspond to some existing page higher in the hierarchy of the current page, chances are that one wants to target a page starting from there. E.g. in the same HwDocs/HwBoards page, HwDocs/Overview would point to /HwDocs/Overview.

Heh, not sure I follow you there ;-)

Let me try to reformulate: if the current page and the destination path have a non-empty common base pointing to an existing page, the destination should be rooted there. Is that what you mean?

My initial reaction is -0, for the following reasons:

  • The path resolution rules become quite complicated to explain. Scoped pages are already not that easy to grasp. but this is becoming really difficult.
  • The situation Manu describes is only non-intuitive because of an initial page creation error. The fix is quite simple, delete the bad page.
  • However, it seems that it's not easy to pick the right page name when creating a scoped page. Currently, all possible variants are proposed for a non-existing page, starting with the one that is rooted deepest in the hierarchy. This is clearly not ideal.

So I'd rather introduce a fix to avoid creating the wrong page in the first place, rather than introduce more complex scoping rules. How about applying the algorithm you propose to select the first page to use when navigating to a non-existing page? For the case you describe, when clicking on "HwDocs/HwBoardds/B2", that would be:

  • This page doesn't exist. It looks like you are trying to create "HwDocs/HwBoards/B2". You can do so here.
  • Alternatively, you can also create the page at other locations in the page hierarchy:
    • HwDocs/HwDocs/HwBoards/B2

So this would not change the path resolution algorithm, only the suggestion for creating a new page.

in reply to:  13 ; comment:14 by Christian Boos, 13 years ago

Replying to rblank:

Let me try to reformulate: if the current page and the destination path have a non-empty common base pointing to an existing page, the destination should be rooted there. Is that what you mean?

Yes.

My initial reaction is -0, for the following reasons:

  • The path resolution rules become quite complicated to explain. Scoped pages are already not that easy to grasp. but this is becoming really difficult.

Agreed, I'm all for finding a simpler solution.

  • The situation Manu describes is only non-intuitive because of an initial page creation error. The fix is quite simple, delete the bad page.

No, see "Board3". The problem comes from the repetition "HwDocs/HwDocs/…" in the missing link. Manu interpreted that as a bug, and so did I until I read again the explanation in comment:10.

  • However, it seems that it's not easy to pick the right page name when creating a scoped page. Currently, all possible variants are proposed for a non-existing page, starting with the one that is rooted deepest in the hierarchy. This is clearly not ideal.

So I'd rather introduce a fix to avoid creating the wrong page in the first place, rather than introduce more complex scoping rules. How about applying the algorithm you propose to select the first page to use when navigating to a non-existing page? For the case you describe, when clicking on "HwDocs/HwBoardds/B2", that would be:

  • This page doesn't exist. It looks like you are trying to create "HwDocs/HwBoards/B2". You can do so here.
  • Alternatively, you can also create the page at other locations in the page hierarchy:
    • HwDocs/HwDocs/HwBoards/B2

So this would not change the path resolution algorithm, only the suggestion for creating a new page.

Yes, that's a good solution.

comment:15 by Remy Blank, 12 years ago

Fixed the relative page resolution for non-existing pages according to comment:12 in [8449].

I'm not happy about the list of page suggestions, though. Currently, it will display existing pages as if they didn't exist. I'd like to improve it at least so that it doesn't display existing pages, and maybe even make it a "Related pages" list showing both page name suggestions and existing pages with the same name.

comment:16 by Remy Blank, 12 years ago

An even better algorithm was committed in [8450].

comment:17 by Christian Boos, 12 years ago

Thanks for looking back at this one, one nasty problem less to worry about ;-)

Especially the unit test in r8450 is nice as it shows the problem reported by Manu is fixed. Anything else that prevents the ticket from being closed?

in reply to:  17 comment:18 by Remy Blank, 12 years ago

Replying to cboos:

Anything else that prevents the ticket from being closed?

Yes, I am working on improving the display of the page name suggestions for non-existing pages. There are two issues:

  • Currently, all suggestions are displayed as non-existing pages, even if they do exist.
  • I'd like to add another section below the suggestions, something like "Possibly related pages" that lists pages with similar names. Not sure yet how to generate it.

I'd like to fix at least the first issue, and see if I can come up with something sensible for the second.

comment:19 by Christian Boos, 12 years ago

Ah, good! Also, remember the discussion about improving the readability of the relative links? We could strip off the "./", "../" and "/" prefixes, that are kind of "implementation details" and getting in the way when reading the rendered wiki text.

comment:20 by Remy Blank, 12 years ago

#8558 was closed as a duplicate, and suggests making it clearer that the page doesn't exist and what the options are for the user.

comment:21 by Remy Blank, 12 years ago

Fixed the formatting for page suggestions higher in the hierarchy, and added a list of pages with similar names in [8461].

in reply to:  19 comment:22 by Remy Blank, 12 years ago

Replying to cboos:

Also, remember the discussion about improving the readability of the relative links? We could strip off the "./", "../" and "/" prefixes, that are kind of "implementation details" and getting in the way when reading the rendered wiki text.

Is this what you had in mind?

  • trac/wiki/api.py

    diff --git a/trac/wiki/api.py b/trac/wiki/api.py
    a b  
    267267
    268268    def _format_link(self, formatter, ns, pagename, label, ignore_missing,
    269269                     original_label=None):
     270        if pagename == label:
     271            label = label.lstrip('/')
     272        elif label.startswith('./') and pagename.endswith(label[2:]):
     273            label = label[2:]
     274        elif label.startswith('../') and pagename.endswith(label[3:]):
     275            label = label[3:]
    270276        pagename, query, fragment = formatter.split_link(pagename)
    271277        version = None
    272278        if '@' in pagename:

comment:23 by Christian Boos, 12 years ago

I think we shouldn't modify a label specified explicitly.

So currently we have:

 - [./SubPage] => ./SubPage
 - [./SubPage ./SubPage] => ./SubPage

What I meant was:

 - [./SubPage] => SubPage
 - [./SubPage ./SubPage] => ./SubPage

So I think the replacement should happen earlier.

comment:24 by Christian Boos, 12 years ago

Ah, forgot to say: I tested the rest of the new enhancements, and that looks really good now!

in reply to:  23 comment:25 by Remy Blank, 12 years ago

Replying to cboos:

I think we shouldn't modify a label specified explicitly.

Yes, that's what I thought, too, but the information that no label was specified is lost quite early during parsing, and so far I haven't found a good place to insert that modification. OTOH, it was late last night, so I'll give it another go :-)

comment:26 by Remy Blank, 12 years ago

Resolution: fixed
Status: reopenedclosed

Ok, I think [8464] solves this adequately. A few additional test cases show how the prefixes are stripped.

Now can we close this or what? ;-)

comment:27 by Christian Boos, 12 years ago

Yes, we can close it, the patch looks good ;-)

in reply to:  14 comment:28 by rgasler@…, 10 years ago

Replying to cboos:

Replying to rblank:

Let me try to reformulate: if the current page and the destination path have a non-empty common base pointing to an existing page, the destination should be rooted there. Is that what you mean?

Yes.

My initial reaction is -0, for the following reasons:

  • The path resolution rules become quite complicated to explain. Scoped pages are already not that easy to grasp. but this is becoming really difficult.

Agreed, I'm all for finding a simpler solution.

  • The situation Manu describes is only non-intuitive because of an initial page creation error. The fix is quite simple, delete the bad page.

No, see "Board3". The problem comes from the repetition "HwDocs/HwDocs/…" in the missing link. Manu interpreted that as a bug, and so did I until I read again the explanation in comment:10.

  • However, it seems that it's not easy to pick the right page name when creating a scoped page. Currently, all possible variants are proposed for a non-existing page, starting with the one that is rooted deepest in the hierarchy. This is clearly not ideal.

So I'd rather introduce a fix to avoid creating the wrong page in the first place, rather than introduce more complex scoping rules. How about applying the algorithm you propose to select the first page to use when navigating to a non-existing page? For the case you describe, when clicking on "HwDocs/HwBoardds/B2", that would be:

  • This page doesn't exist. It looks like you are trying to create "HwDocs/HwBoards/B2". You can do so here.
  • Alternatively, you can also create the page at other locations in the page hierarchy:
    • HwDocs/HwDocs/HwBoards/B2

So this would not change the path resolution algorithm, only the suggestion for creating a new page.

Yes, that's a good solution.

Hi,

I would like add a small late comment to this thread:

In case 'HwDocs' and 'HwDocs/HwBoards' don't exist all the links will resolve to 'HwDocs/HwDocs/HwBoards' instead… I find this behavior not being very intuitive or consistent.

Adding the following test to the wiki page HwDocs/HwBoards:

[wiki:HwDocs/HwBoards/B1]

will produce

<a class="wiki"
href="/trac/sdk/wiki/HwDocs/HwDocs/HwBoards/B1">Board1</a>

comment:29 by Christian Boos, 10 years ago

Ok, we have already discussed this glitch before, the real problem IMO is that this link will lead to a page showing the following:

 The page HwDocs/HwDocs/HwBoards/B1 does not exist. You can create it here.

 You could also create the same page higher in the hierarchy:

 HwDocs/HwDocs/B1?
 HwDocs/B1?
 B1?

i.e. among the proposed targets, the HwDocs/HwBoards part is gone. The (only) proposition should have been HwDocs/HwBoards/B1 as that was specified in the link itself. If we can agree on that (or a better solution), let's create a follow-up ticket.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Remy Blank.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Remy Blank to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.