[pmwiki-users] Re: Dynamic wiki trails - passing along the name of the trail page

Patrick R. Michaud pmichaud at pobox.com
Sun Mar 13 21:36:21 CST 2005


On Thu, Mar 10, 2005 at 10:53:10AM +1300, John Rankin wrote:
> On Thursday, 10 March 2005 3:35 AM, chr at home.se wrote:
> >I think using GroupHeader/GroupFooter could work well for me... 
> >especially if there was someway to only insert this special markup 
> >if the argument is there... This means we'd need something
> >like:
> >
> >	(:if URI-arg-exists=trail:)
> >	Current trail: <<|{$URI-arg trail}|>>
> >	(:ifend:)
> 
> I think it's simpler than that: let the GroupHeader contain
> 
> <<|TrailPage|>>
> 
> If the current page is not on the trail, the markup returns ''
> instead of the current <<|TrailPage|>>.
> 
> This will also automatically drop the trail navigation from the
> Printable View.

Unfortunately, it can also mean that someone intended a page to be
on a trail but forgot to add it to the trail.  There are a number of
times when I've seen

   <<|DocumentationIndex|>>

on a PmWiki documentation page, which told me that this page was supposed
to be available on the documentation trail but never was added.

That said, I wouldn't have a big issue with making this behavior be the
default, but it would be nice to have a markup or syntax that said to
display the <<|TrailPage|>> link even if the current page is not on
the trail defined by TrailPage.

In answer to Christian's suggestion about {$URI-arg trail}, perhaps a
better markup is simply:

   {?trail}

which substitutes the current value of the "trail" uri-parameter.
We would then end up with the following:

  - <<|TrailPage|>> generates nothing if the current page is not listed
    on TrailPage
  - If the current page is on TrailPage, then the previous/next links
    generated by <<|TrailPage|>> have ?trail=Group.TrailPage added to
    the urls.
  - The markup {?trail} is replaced with the value of "trail" from the url
  - Thus <<|{?trail}|>> results in links to the next/previous page for
    the trail currently being "followed", as given by the ?trail parameter,
    and as long as the reader remains on the trail.

Of course, the problem with the {?trail} approach (where the trails come
from the urls) is figuring out how someone manages to get on the ?trail
in the first place.  :-|

That said, I think it's very fair to say that <<||>> should be
changed to no output, and we need a decision about what <<|TrailPage|>>
should produce when the current page is not on TrailPage.

Pm



More information about the pmwiki-users mailing list