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

[chr at home.se]

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

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.

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

Ok, back to the topic...

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

Sounds good to me.

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

Umm.. I'm not quite sure I see the problem, but it's early in the 
morning here. If you start from a trail page, you will automatically get 
?trail=... appened to the URI, so you will be on the trail...

If you go directly to a page that belongs to a trail, the problem of
determining *the* trail page is actually ill-posed since there can be many
trails that contain a certain page.  (Which is why I want this markup to
begin with...)

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

Maybe we could say that ?trail=... is only added if the user manually 
places the directive (:trailpage:) on the page?

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.

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

Btw, is there a problem with calling the URI-argument 'trail'? The reason 
I ask is that I just realized that this might be a useful way to traverse 
categories... Imagine we have the category page 'Category.Cars', which 
first contains an ordered list of page links and then the (:pagelist...:) 
magic to list the rest of the pages in that category. Now imagine that we 
could use a trail to traverse this combined list of pages in the 
category...

Would 'trail' be misleading in this case? Would something like 'index=...' 
be better?  (I think trail should be fine).

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

Slightly off topic... but maybe the script that is used to check for links 
to pages that doesn't exist could be augmented to look for pages with a 
"trail reference" to a trail page that doesn't exist?

/Christian

-- 
Christian Ridderström, +46-8-768 39 44               http://www.md.kth.se/~chr