[pmwiki-users] New Hierarchical Groups Recipe...

[Patrick R. Michaud]

On Fri, Feb 02, 2007 at 01:09:09PM -0500, The Editor wrote:
> On 2/2/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> >You don't have to take out the default one (ResolvePageName) --
> >if the pagename is already a PmWiki-standard pagename, then
> >ResolvePageName leaves it alone.
> 
> Sorry to be dense, but if I type index.php?n=Animal/Canine/Dog into my
> browser, do I just put something like $pagename =
> MySpecialResolveFunction($n) into Hg to get PmWiki to load
> Animal-Canine.Dog?

At the point of loading local/farmconfig.php or local/config.php,
PmWiki will have already initialized $pagename with the value of
any ?n= or PATH_INFO string.  However, PmWiki doesn't normalize
$pagename until ResolvePageName is called.

So, it's just

    $pagename = MySpecialResolveFunction($pagename);

> >> >The problem with using a closing / or . at the end to indicate the
> >> >group is that many people won't see them there, or recognize that
> >> >they're a required part of the url.
> >>
> >> Yes that crossed my mind too.  Do you have a suggestion?  I suppose if
> >> we just require them to manually enter Homepage, and get [[Group.]] to
> >> go to Homepage, that would solve the problem, wouldn't it?
> >
> >While it's one approach, I don't think it "solves the problem", since
> >the end result is to shift the work away from the computer and
> >onto people (and add some surprises/frustration in the process).
> 
> What exactly is the problem?  I thought it was related to pages not
> being both groups and pages simultaneously.  It would largely solve
> that...  Specifying a Homepage is not that much extra work.  And I'm
> not sure where the surprise might be.  It seems like it would work...

By analogy to urls outside of the PmWiki context, requiring
someone to specify HomePage is roughly equivalent to the difference
between

    http://www.example.com/foo/bar/

    http://www.example.com/foo/bar/index.html

People don't expect to have to write the name of the index page
at the end of the url, and I don't know that people want to see
it in published/printed materials (e.g., business cards and the like).

As far as surprise goes, many visitors would be very surprised
that these two urls result in different pages:

    http://www.example.com/wiki/Group/Main

    http://www.example.com/wiki/Group/Main/

> And what issues specifically still should to be decided? It would be
> nice to get up at least one good option...
> 
> Sorry for [being] so persistent.  Somehow I feel we are just on the
> brink of fuller solution.  

Persistence is good... but so far this feels like territory
that's been covered several times before, so I don't yet have the 
impression we're on the brink of a fuller solution.  

The hyphen-as-group-separator approach can work in a limited fashion
because there remains a clear distinction between group and 
pagename, and the hyphens are substantially distinguishable from 
existing url syntax.  But once we try to alias those hyphens 
into slashes or dots, then people expect the resulting urls
to work the same as what they see everywhere else on the web,
and that's where things break down at the moment and cause
frustration and confusion.

That's why addressing and/or resolving the issues on
http://www.pmwiki.org/wiki/PmWiki/HierarchicalGroups-Proposals
is important -- once we have a clean notation for 
parent, child, sibling, and grandparent (ancestor) references, 
the rest basically works itself out.

At some point I'll repost the proposal I had for using 
"nearest-ancestor page references"-- when I posted it in 2004 lots 
of people thought it was too confusing, but I think that may have
been because there were too many competing (and totally confusing)
proposals flying around at the same time.

Pm