[pmwiki-users] Nested groups
Joachim Durchholz
jo at durchholz.org
Thu Jun 2 14:55:36 CDT 2005
Hi all,
I had my thoughts drifting and had a flash of inspiration about nested
group hierarchies that I'd like to share. (That particular inspiration
may be helpful or not, I don't know - I still don't have a good grasp of
the issues involved, I can only guess what the problems were.)
One of the problems that Pm mentioned was "no good default policies when
incomplete page names are given". I interpret this to mean things like:
if the URL is pmwiki.php?n=Cookbook, it will be redirected to
pmwiki.php?n=Cookbook.Cookbook. There's no good way to extend that kind
of policy to a hierarchical group structure.
It occurred to me that such a policy isn't really required. Wiki pages
need not be restricted to sitting at leaves, they can also sit at
internal nodes. I.e. there's no need at all to forward ?n=Cookbook
anywhere else, simply let the page be named Cookbook and be done with
it. This also makes it unnecessary to do redirects (which tend to
complicate both the internal processing of PmWiki and the mental model
of the visitor, so good riddance *g*).
Another one was "no good syntax for relative links". I have toyed with
various ideas, and found this:
* It's a solved problem with path-like syntax (i.e.
/Main/HomePage is an absolut path, HomePage is a
relative path to a page on the same hierarchy level,
../HomePage is the home page "one level up").
* It doesn't work for dot syntax. Absolute path names like
.Main.HomePage look silly, and people tend to overlook
that tiny leading dot (this is a frequent source of errors
in DNS records which use absolute and relative domain names
with dots as separators).
The .. convention will degenerate into dot-counting madness.
Seems like the dot syntax should be deprecated, or replaced with
something else. (I'm in favor of deprecating it. Having two ways to
write the same thing just confuses people.)
Regards,
Jo
More information about the pmwiki-users
mailing list