[Pmwiki-users] Hierarchical groups - possible notation
Patrick R. Michaud
pmichaud
Wed Jun 9 13:05:30 CDT 2004
On Wed, Jun 09, 2004 at 02:03:56PM -0400, J. Perkins wrote:
> John Feezell wrote:
> >Well then how about one of these to resolve to top level group with
> >pagename?
> > (very much snipped)
>
> Oof. I was concerned about users not being able to understand ".." but
> even I am having trouble understanding all of the combinations of . and
> / and now ^. I am starting to think that Pm should just keep the
> existing Group.Page notation and if at all possible make it replaceable
> by a local customization.
It's definitely replaceable in 2.0 -- all conversions of strings
to pagenames is handled by a single MakePageName(...) function,
which can be overridden by a local customization. Indeed, I'm
leaning towards keeping the Group.Page notation since it is
simple, consistent, and fairly easy to understand.
> No one seems to like the idea of unix paths, but I haven't seen any
> specific objections.
Oh, I like the idea of unix paths, I just see some potential problems
with any form of hierarchical scheme. Read on...
> Out of curiosity, can anyone tell me why it would
> be a bad idea? I'd like to know if there is some big flaw that I haven't
> noticed [...]
I don't know that this will count as a "big flaw", but here's a simple
"real world" scenario I came up with I have that may illustrate some
difficulties: Let's suppose I have a set of pages that collectively
describe PmWiki, such as documentation, FAQs, etc. Clearly they belong
in a common group, such as "PmWiki", thus I have PmWiki.DocumentationIndex,
PmWiki.Installation, etc. Now then, I also need an page to serve as the
"entry page" to the group, to describe PmWiki itself. What should I call
this entry page?
If I call it just "/PmWiki" (at the root), then this page has to
use "PmWiki/" to link to any of the other pages in the group, thus
[[PmWiki/DocumentationIndex]], [[PmWiki/Installation]], etc. Worse,
since '/' no longer suppresses part of the name as it used to, I
have to write [[(PmWiki/)documentation index]] and [[(PmWiki/)installation]]
instead of the more convenient [[documentation index]] and
[[installation]]. Hmm, that's icky--let's try again.
If I call the entry page "PmWiki.PmWiki"--essentially duplicating the group
name as the page name (like PmWiki does now), that works okay--all of
the pages can now reference each other without the extra group+slash.
Except now the reference [[/PmWiki]] goes to a blank page and the
authors have to remember to always do [[/PmWiki/PmWiki]] to link to
the one with the content. I could put a redirect on the [[/PmWiki]] page
to go to PmWiki.PmWiki, but it gets annoying to have to create redirects
for every group and subgroup. We could have the system automatically
convert a reference of [[/PmWiki]] to be PmWiki.PmWiki. It seems
obvious that [[/PmWiki/PmWiki]] should also go to PmWiki.PmWiki,
but what if there's a PmWiki.PmWiki.PmWiki page? What does
[[/PmWiki/Installation]] do if both PmWiki.Installation and
PmWiki.Installation.Installation exist, or if one exists and the
other is later added?
Perhaps this sounds contrived, but I can see it happening. We
start with a page of PmWiki.Installation. Someone later adds a
page called PmWiki.Installation.Windows. Woops, this is just like
the case I started with--where there are now multiple pages dealing
with installation--so now I need a PmWiki.Installation.Installation
page as the entry point to the PmWiki.Installation group, and the
links get more complex...
Again, I don't know if this counts as a "fatal flaw", but I can see
people being confused by it all. A significant difference between
a filesystem hierarchy and the one proposed here is that in a filesystem a
directory never has any content of its own beyond simply listing the
files contained in the directory.
Pm
More information about the pmwiki-users
mailing list