[pmwiki-users] pagelist is creating links relative to the current group?

[Joachim Durchholz]

Patrick R. Michaud schrieb:
> On Wed, May 24, 2006 at 06:59:00PM +0200, Joachim Durchholz wrote:
>> Patrick R. Michaud schrieb:
>>> The crux of the problem is that there are multiple possibilities for
>>> a group's "default home page"-- i.e., for a group XYZ the default
>>> home page can be either "XYZ.XYZ" or "XYZ.HomePage".
>> This might also help create an infrastructure for a hierarchical group 
>> structure. Naming the group's home page was one of the major trouble 
>> spots there IIRC.
> 
> Yes, but the big problem is that it's difficult to know if 
> a reference like [[Group]] should refer to the parent (group), the 
> current page, or a child of the same name.

We'd have to use different link syntax for each case (assuming that each 
case is indeed worth the trouble).

> (There are other problems related to this as well -- this is a
> simplification.)

For reference, this is the relevant passage from 
http://pmwiki.org/wiki/PmWiki/HierarchicalGroups:

--

On the second point, the problem comes from trying to decide what one 
should do with markup such as "Canine.StBernard" inside of the 
"Animal.Mammal" group, especially if there's a top-level group named 
"Canine". If we treat Group.WikiWord links as always being absolute, 
then there's not much organizational advantage to having hierarchies. If 
we allow relative paths, then there's all sorts of room for ambiguity 
unless even more markup is added to resolve it, and it's possible that 
someone creating a page in an intermediate subgroup inadvertently 
changes the target of existing links. All of which just makes things 
more difficult for naive users.

--

To which I just added:

--

There's indeed a problem here. Hierarchical file systems solve this by 
distinguishing absolute paths syntactically (i.e. in Unix they have a 
leading /).
The obvious solution would be to say that absolute links should have a 
leading dot, i.e. [[.Canine.StBernard]] would be an absolute link, and 
[[Canine.StBernard]] a relative one. Only that's so counter to the usual 
usage of dots that people wouldn't accept this. Maybe we could use a 
colon, which is similar enough to a dot that it would be intuitive, and 
obvious enough for practical use; i.e. [[:Canine.StBernard]].
For links that use slashes, it's far simpler: [[Canine/StBernard]] would 
now be a relative link, while [[/Canine/StBernard]] would be an absolute 
one.
Whatever syntax is used, upgrading to a PmWiki version that supports 
absolute and relative links would require an upgrade script that went 
through all pages and turned those Group.Page and Group/Page links into 
absolute paths.

--

What I forgot is a syntax for "going up the hierarchy". It *might* be 
acceptable to say ".." from StBernard to reach the Canine group page.

>> So far, this all could easily be naming pages according to a 
>> ClassSubclassSubsubclass.Item schema.
>> However, there are two problems with that:
>> 1) It's difficult to organize wikitrails. The "natural reading order" of 
>> the entire hierarchy would be what's called a "preorder" (because nodes 
>> in the tree come ''before'' their child nodes), but there's no easy way 
>> of setting up a wiki trail that lists the items in preorder. 
> 
> What's wrong with (besides being a bit ugly):
> 
>     * [[ClassSubclass.SomePage]]
>     ** [[ClassSubclassSomePage.Item1]]
>     ** [[ClassSubclassSomePage.Item2]]
>     ** [[ClassSubclassSomePage.Item3]]
>     * [[ClassSubclass.AnotherPage]]
>     ** [[ClassSubclassAnotherPage.Item1]]
>     ** [[ClassSubclassAnotherPage.Item2]]
> 
> (A useful exercise:  See if having hierarchical links makes any
> improvement to the above. :-)

Not on the above. But hierarchical groups would allow PmWiki to 
automatically generate a group list that has the above structure. 
Currently, I'd have to write

* [[ClassSubclass.SomePage]]
(:pagelist group=ClassSubclassSomepage list=normal fmt=simple:)
* [[ClassSubclass.AnotherPage]]
(:pagelist group=ClassSubclassAnotherPage list=normal fmt=simple:)

(with some variations to generate a level-two bullet list in the 
(:pagelist...:) markup that I'm too lazy to look up), and have to 
manually correct that list whenever I rearrange the hierarchy. All of 
this manual maintenance would go away if I could write

(:pagelist group=Class.Subclass depth=2 list=normal fmt=simple:)

and have PmWiki autogenerate the new page list as appropriate. (That's 
particularly important/interesting if the page list is used for a wiki 
trail: I could then encode an entire book with chapters and subsections 
as wiki groups and have the trail automatically generated from the 
pagelist, which in turn would be automatically generated in the correct 
fashion.)

I have also just extended 
http://pmwiki.org/wiki/PmWiki/HierarchicalGroups with the second 
paragraph in the following excerpt:

----

 From a practical view point, how would an "implied relationship" change 
anything in terms of how pages are rendered or interpreted? --Pm

PmWiki would "know" the relationship between the Animal group, the 
Animal.Mammal group, and the Animal.Mammal.Canine group. This affects 
various functions: group searches (would cover subgroups), renaming 
(moving a group to a different place would also affect the pages in the 
subgroups), pagelist generation (again, would include subgroups - good 
for generating wikitrails that span several hierarchies). 
--JoachimDurchholz May 24, 2006, at 04:54 PM


----

Sorry for writing such a long post. I didn't have the time to write a 
shorter one ;-)

Regards,
Jo