Improve behavior of hierarchical page names

[christian@…]

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.

[cboos]

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).

[cboos]

See also googlegroups:trac-dev:3f9bbc0bcb3158e2.

[cboos]

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

[cboos]

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

[Remy Blank <remy.blank@…>]

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

[Remy Blank <remy.blank@…>]

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:

• FirstLevel -> FirstLevel
• SecondLevel -> FirstLevel/SecondLevel
• ThirdLevel -> FirstLevel/SecondLevel/ThirdLevel
• OtherThirdLevel -> FirstLevel/SecondLevel/OtherThirdLevel
• [wiki:/OtherThirdLevel] -> OtherThirdLevel
• MissingPage -> MissingPage

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

[rblank]

Updated patch for current trunk

[rblank]

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

[cboos]

Patch looks great.

[rblank]

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

[rblank]

Improved usability for creating hierarchical pages

[rblank]

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.

[rblank]

Patch applied in [7685].