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

[Patrick R. Michaud]

On Tue, Mar 15, 2005 at 04:50:06PM +0100, chr at home.se wrote:
> I've read this post (and the follow-ups) and think that this functionality
> will be quite useful. However, isn't this really only a simple extension
> of the current trail functionally? It will unfortunately not quite allow
> me to do what I'd like. 

Actually, I think it does, or at least gets us as reasonably close
as we can within the boundaries of efficiency and utility.  But I'll
go through the post in some detail and we'll see where things diverge...

>   A "trail" is comprised of a "trail map" and one or more "trail pages".  

Unfortunately, this definition is at odds with the way we've traditionally
used the terms "trail" and "trail page".  Traditionally, a "trail" is a 
bullet or numbered list of pages, and a "trail page" is a page containing
such a list.  Still, to avoid confusion here I'll just use your terms 
"trail map" and "trail map page" for this post and avoid any mention of 
"trail page" (which is traditionally a synonym for your "trail map page").  
A page that appears in a trail map is simply a "page on a trail".

> I think there was a confusion when what I said could be interpreted as me
> being fine with placing a directive on each "trail page"... what I
> actually meant was that I'm fine with placing a directive on each "trail
> map page"...

No, there was no confusion -- I understood fully that you intended
(:trailpage:) to be a directive on the trail map page (as opposed to
the pages on the trail).  I just don't think it solves the real problem.

> In my mind though, we are still required to specify the trail both on the
> trail map page and the trail pages, the effort in the latter part has just
> been reduced. Please note that it is not zero, since even in the most
> extreme implementation there will still be one page specifying all trail
> map pages in the entire wiki, and when you create another trail you will
> have to modify this page.

Not at all, I didn't necessarily rescind the {?trail} markup (and
explicitly mentioned <<|{$TrailPage}|>>), so we can still get the
trail from some other dynamic parameter.  If we extend to John's
syntax we have  <<|?{?trail}|>> and <<|?{$TrailPage}|>>.

> What I want is to be
> able to set up a wiki so that when an author creates another trail, all he
> has to do is create a new trail map (page). 

Okay, we can still do this.

> There are other reasons, but this post is long as it is... essentially I
> think I loose too much control with the situation above. However, I think
> my needs are quite easily satisfied. All I really need is two things:
> 	1) The directive (:trailpage:) should cause ?trail={$FullName} to 
> 	   the be appended to the HREF of page links
> 	2) The "directive" {?trail} should extract the URI argument.

I still don't like that ?trail= argument in URIs.  

> With this, I can simply use (:trails {?trail}:) in for instance the page 
> template to allow me to create the kind of trails I want.

I propose <<|?{?trail}|>> instead, see below.

> I'm aware that I'll have to add something like (:trails {?trail}:) at 
> least once, but that's fine with me. I'm also aware that if you go 
> directly to a page, the trail links will not be visible. And that 
> ?trail=... will be part of google etc doesn't bother me at all...
> 
> Actually, why not generalize the directives above as follows:
> * The directive (:append-to-page-links "?trail={$FullName}":) will append 
>   it's argument to the destination URI on page links on the current page.

As you mention, too wordy, so we'd need something better.

But a big problem I see with the ?trail= approach is that the
trail gets lost if the reader ever follows a (non-trail) link from a 
page on the trail, making it difficult to return to the trail from
any "side excursions".  Yes, there's the "back" button, but this feels
like a lot less than what we're really looking for, and a reader is
likely to be confused by the disappearing trail links.

For example, I follow some trail links to get to page ABC, then from
that page I see that page DEF looks interesting so I go read it,
DEF has a link back to ABC so I follow it but the trail marker I saw
before has now (mysteriously) disappeared.  Gee, I know I saw that trail
here somewhere...

So, instead of modifying URLs, let's use cookies.  We can set a "trail"
cookie on the browser that identifies the reader's current trail,
then the <<|{?trail}|>> or <<|{$TrailCookie}|>> markup displays the 
trail path corresponding to the cookie.  The cookie gets set by any 
trail map page containing a (:trailpage:) directive, so when someone 
visits a trail page, they're setting the implicit {?trail} for any 
pages they visit later (or at least until they come to another 
(:trailpage:)).  This stays in place even if they visit pages not
on the trail, or follow non-trail links.

(Alas, message cut short for now because of other conflicts -- I'll 
pick it back up again later.)

Pm