[Pmwiki-users] Re: can pmwiki handle hierarchical content?

[Stefan Candea]

First, thanks for the reply.

>> > I know there was a ton of discussions on this.  However, can someone
>> > explain simply (what did it come down to?) why having pages as files
>> and
>> > groups as subdirectories was a no-no from the begining?
>>
>> The fundamental problem is simply one of clarity in creating relative
>> page links to other pages--nothing more.
>
> I've drawn a picture hoping it will help clarify the issue,
>
> 	http://www.md.kth.se/~chr/pmwiki/organization/page-tree1.png
>
> where the current page is called 'B' and has the imaginary URI
>
> 	http://<wiki-URI>/A/B
>
> from which I define the 'page path' of that page as '/A/B'.
>
> Now let us assume that the page '/A/B' contains the markup [[A]] which
> links to a page called 'A'.  To which page should this link point?
>
> Here are some of the possible candidates:
> * The child page, /A/B/A
> * The sibling page, /A/A
> * The parent page, /A
>
> It is not always clear which one you really want

For clarity and siplicity sake, and unless we have a better wheel to
invent, the traditional directory reference (relative or absolute) should
be applied.

So [[A]] should refere only to the page within the group!  It makes it
also simple and possible to do the search within a group (or below). 
Relative notation would be used for pages at a relative 'short distance',
e.g. ../A or SubGroup/etc/A and absolute for the others.  This eliminates
confusion and makes the hierarchy possible.

It would be nice to have some 'smarter' defaults, however, due to the
logic complexity it is not worth it (Unless some very clear definition or
behaviour makes sense and is agreed upon - e.g. if page does not exist in
the group [[A]] then refers to 1 group only, [[Definitions/]] for
instance, defined by the Administrator, or some other default).

If it is a new page then is created within the group like it is today.

How does this sound?

--
Stefan