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

The Editor editor at fast.st
Fri Feb 2 17:37:23 CST 2007


On 2/2/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> 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);

Ok, I got it.  Thanks!


> > >> >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).

Calling it Home or Main might not be that bad, but I see your point.
(It could probably be hidden easily enough when printed with
conditionals...)  I wonder if others who want this kind of solution
would object to that requirement to get what they want?  If not, no
point pressing this forward until we figure out, as you noted below,
answers to the underlying questions.


> 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/

Agreed.  Not an adequate solution...


> > 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.

I think you are right, Pm.  Thanks for taking the time to explain this
so thoroughly, again.  Hg gives me the functionality I need
personally, even if not the "look" others might want.  It wouldn't be
hard if we required a homepage ending to use /'s (provided you fixed
PmWiki to allow [[Group.]] links to be defined), but it's not a
complete solution either.  So I guess I'll just leave Hg as is for
now.

I did update the Hg recipe page to clarify some of the things you
mentioned early, and will probably rewrite the Hierarchical Groups
page to be more of an information clearing house for similar recipes
if no one beats me to it. Also have made a few minor improvements to
the code.

> 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.

That would be interesting to look at.  I don't think I've seen it
yet--as I wasn't around PmWiki in 2004.  Maybe Hg could be a small
part of the final solution...  =|: )>

Cheers,
Dan



More information about the pmwiki-users mailing list