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

Patrick R. Michaud pmichaud
Fri Oct 15 09:46:35 CDT 2004


On Fri, Oct 15, 2004 at 10:57:33AM -0400, Stefan Candea wrote:
> 
> 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.  

For example, if we're currently in a page called "Linux.Hardware.SoundCards",
then [[HardDrives]] would be a link to "Linux.Hardware.HardDrives" -- no 
problem.  But what about [[Hardware]] -- is it a link to "Linux.Hardware"
or to "Linux.Hardware.Hardware"?  And then what about 
[[Hardware/HardDrives]] -- is this a link to "Hardware.HardDrives", 
"Linux.Hardware.HardDrives", or "Linux.Hardware.Hardware.HardDrives"?

This was discussed in a lot of gory detail last June (see the pmwiki-users
archives), and it was all very confusing--to the point that a number of
people wrote to me to beg that we keep the one-level group hierarchy as
the default.

And to anticipate the question:  "Why not just make it work like
filesystem directories?", the short answer is that there appears to
be a fundamental differences between wiki pages and filesystem
directories in that in such a system a wiki page name identifies both
a page (content) and a collection of subpages, while a filesystem directory
only identifies a collection of subitems (it has no content of its own).
The result is that authors can be easily confused as to whether a 
page reference targets a sibling, child, parent, parent's sibling, or 
some other ancestor.

If one is willing to impose the restriction that all references to pages
outside of the current group must be fully qualified (i.e., no relative
references to other subgroups), then there's little confusion, but I
authors will quickly become frustrated about the inability to create 
relative page references, which leads us back to the problem above.

(Also, fully qualified names is exactly what PmWiki does now--we
can add the syntactic sugar of allowing '.' and '/' in group names if
that would help.)

I'm still open for suggestions, but thus far I haven't seen anything
that garners wide acceptance or understanding, so keeping it simple
and understandable to the widest audience of authors seems to be the best
approach thus far.

Pm



More information about the pmwiki-users mailing list