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

[Patrick R. Michaud]

On Mon, Mar 14, 2005 at 09:28:52AM +0100, chr at home.se wrote:
> On Sun, 13 Mar 2005, Patrick R. Michaud wrote:
> 
> > 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.
> 
> Do you think that is suitable for extracting general URI-paramters? (For 
> me it works well, with the '?' similar to how arguments are appended to 
> a URI, and also similar to {$arg}. Btw, {&trail} would also work with the 
> same reasoning, although I'd prefer {?trail}.

Well, using this syntax for general URI-parameters was my intent, on the 
theory that I prefer generalized solutions over specific ones.  And I'd
be against {&trail}, simply because one doesn't have to use '&'.

> But... in the general case, what should {?arg} produce when there is no 
> such argument? Should it be empty?  I guess {?arg | default text} could be 
> used to indicate what to show when it is empty.

Empty by default.  I probably would push {?arg | default text} as being
initially too much featuritis.

> Is there any risk that {?arg} is used in "normal" text?

I don't believe I've ever seen it.  :-)

> [...]
> Oh wait... you mean that the problem is that since any page with an 
> unordered list of page links can be used as trail page, we might be forced 
> to always add '?trail=...' to the first link in an item in an unordered 
> list -- that does sound a bit messy...

Yes, that's exactly the problem I'm identifying.  And then, why just
the first link of the list -- is it required that a reader start with
the first page of a trail to be on it?  Seems to me as though every
page ought to identify its trail.

> Another alternative might be to rely on the browser to be nice and tell us 
> the name of the referring page? I have a vague memory that some browsers 
> do this.. OTOH, it's not so nice to have to rely on something like that.

Yes, I think that using the referring page in this manner (to identify
a trail) might be a useful addition.  But it does add some overhead
to *all* page reads to do it this way.

> Anyway, I'd be happy with having to add (:trailpage:) on trail pages...  
> it's not that much of a bother, and will in addition provide an easy way
> to find all trail pages. 

Somehow I find that to be a bit of a bother -- more than the result
is worth.  Plus I'm still not entirely happy with having ?trail= show 
up in uris all over the place (e.g., in search engine results).

> (Or... we could say that belonging to the
> category TrailPage makes it a trail page, i.e. we'd add [[!TrailPage]]
> to indicate its a trail page...)

Just as some people don't like having lots of predefined groups in the
distribution, I'm not sure we want a lot of predefined categories (even
though we're clearly heading in that direction on pmwiki.org).

> Btw, is there a problem with calling the URI-argument 'trail'? 
> [...]
> Would something like 'index=...' be better?  

"trail" seems to be the most logical choice, since it implies
an ordering among pages.  "index=" doesn't normally have that meaning.

Pm