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

[chr at home.se]

On Tue, 15 Mar 2005, Patrick R. Michaud wrote:

> Actually, I think it does, or at least gets us as reasonably close
> as we can within the boundaries of efficiency and utility.

Good :-)

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

That figures... well, I just needed to be very clear on what I was talking
about (either is fine by me, although I'd prefer "trail map" over merely
"trail" for clarity, and let "trail" refer to the whole thing). Anyway, to 
avoid further confusion I'll stick with my definitions above, and also not 
refer to "page trail", but instead write "page on a trail" :-)

Btw, I just looked at PmWiki.WikiTrails and wonder if there isn't a small 
error in the initial description:

	The WikiTrails feature allows wiki authors to create "trails" 
	through sequences of pages in the wiki. To do this, an author
	creates a "trail page" that...

Here it looks like "trail" actually do mean the sequence of pages, but
that's a minor detail. What I wonder is if this sentence isn't inaccurate:

	... the markup "<<|TrailPage|>>" ... will then be replaced with
	links to the previous and next pages in the trail, as defined by
	the TrailPage.

Doesn't "<<|TrailPage|>>" also link to the trail map page (i.e. trail
page)? Let me know and I can add that description, otherwise it's well 
written.

> No, there was no confusion 

Oh, good... well, better safe than sorry.

> syntax we have  <<|?{?trail}|>> and <<|?{$TrailPage}|>>.

Ok with me (although I'd (:trail {?trail}.), for it's verbosity).

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

Well, I'm not fanatic about putting the argumetn in the URI... :-)
(and does look less nice)

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

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

A very good point.

> So, instead of modifying URLs, let's use cookies.

Sure, it's less transparent but persistent. This might cause other
confusion (imagine someone who bookmarks a page and when he then visits it
later on the trail is completely different...)

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

Do you mean that {?arg} would check for 'arg' in the user's cookie? I 
still think we should have a general mechanism here, it might be useful 
for lots of stuff. However, I really like being able to extract arbitrary 
arguments from the URI, so I'd like to keep {?arg} for that purpose...

> The cookie gets set by any trail map page containing a (:trailpage:)

Couldn't we use an explicit directive for this, e.g.

	(:cookie-set trail={$FullName}:)

and then

	(:trail (:cookie-read trail:):)

/Christian

A slight side note... Swedish law now requires web sites to inform users 
that the site uses oookies. So we'd have to do that in Sweden... hmm, 
wonder what law applies to me when I administer a wiki site that is hosted 
in Norway...

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