[pmwiki-users] pagelist is creating links relative to the current group?
jo at durchholz.org
Wed May 24 17:32:38 CDT 2006
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
For reference, this is the relevant passage from
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
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
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
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
(:pagelist group=ClassSubclassSomepage list=normal fmt=simple:)
(: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
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 ;-)
More information about the pmwiki-users