Edgewall Software

Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#11455 closed enhancement (fixed)

TitleIndex Macro should also take relative prefixes — at Version 6

Reported by: glinders@… Owned by: Peter Suter
Priority: normal Milestone: 1.1.2
Component: wiki system Version:
Severity: normal Keywords: TitleIndex
Cc: Branch:
Release Notes:

Added support for the prefix in TitleIndex macro to be resolved relative to current wiki page. (E.g. [[TitleIndex(./)]] lists all subpages.)

API Changes:
Internal Changes:

Description

The TitleIndex macro only takes the full path of a Wiki page.

For instance, if you are on Wiki page WikiStart:Top/Deeper/Deepest and want to include a list of all subpages of Deepest, you have to include [[TitleIndex(Top/Deeper/Deepest/)]] in your page.

It would be great if you could also use [[TitleIndex(./)]] to achieve the same.

Similarly, [[TitleIndex(../)]] should give the same result as [[TitleIndex(Top/Deeper/)]]

Change History (9)

comment:1 by Peter Suter, 8 years ago

Keywords: TitleIndex added
Milestone: 1.1.2
Owner: set to Peter Suter
Status: newassigned

The attached patch implements this functionality that I've been missing myself.

by Peter Suter, 8 years ago

by Jun Omae, 8 years ago

Attachment: 20140310T002856.png added

comment:2 by Jun Omae, 8 years ago

I tried the patch. It is inconsistent between [[TitleIndex(./)]] and [[TitleIndex(SandBox/)]].

Also, we should add unit tests for this feature.

comment:3 by Peter Suter, 8 years ago

Thanks for testing. You are of course correct on both accounts. I will attach an updated patch later.

in reply to:  2 ; comment:4 by Peter Suter, 8 years ago

Replying to jomae:

It is inconsistent between [[TitleIndex(./)]] and [[TitleIndex(SandBox/)]]. Also, we should add unit tests for this feature.

This updated patch fixes the inconsistency ([[TitleIndex(./)]] does not list the current wiki page anymore) and adds unit tests.

(The fix is changing _resolve_relative_name:

-elif comp and comp != '.': 
+elif comp != '.': 

It is not immediately obvious that this breaks no other callers, but I can not come up with a scenario where this change would affect the only other caller after pagename.rstrip('/') and pagename.startswith(('./', '../')) or pagename in ('.', '..').)

in reply to:  4 comment:5 by Jun Omae, 8 years ago

(The fix is changing _resolve_relative_name:

-elif comp and comp != '.': 
+elif comp != '.': 

It is not immediately obvious that this breaks no other callers, but I can not come up with a scenario where this change would affect the only other caller after pagename.rstrip('/') and pagename.startswith(('./', '../')) or pagename in ('.', '..').)

After the changes, in SandBox page,

Before the changes, both will link to WikiStart page.

But I think the patch is okay because page name doesn't have repeated-slashes.

Unit and functional tests pass on Python 2.5 - 2.7 with SQLite, PostgreSQL and MySQL on Linux.

comment:6 by Peter Suter, 8 years ago

Release Notes: modified (diff)
Resolution: fixed
Status: assignedclosed

Committed in [12584]. Thanks for reviewing and testing. I had not considered such "invalid" page names with repeated slashes.

Note: See TracTickets for help on using tickets.