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

chr at home.se chr at home.se
Mon Mar 14 09:05:19 CST 2005


On Mon, 14 Mar 2005, Patrick R. Michaud wrote:

> Well, using this syntax for general URI-parameters was my intent

Good (just checking really:-)

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

Ok

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

Might be confusion here.. I just meant the first link *in an item*, not
just the first item in a list...

> Seems to me as though every page ought to identify its trail.

Eh.. I think you might mean that every page link in the list of pages on 
the page trail should contain ?trail=..   If you mean that every page 
belonging to a page trail should identify all page trails it belongs to I 
don't agree.

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

Hmm.. the overhead seems like a pity... other than ?trail=... and using 
referring page, are there any alternatives for this? Cookies??

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

I actually like the idea of specifically saying that *this page is a trail
page*, in contrast to what we do now, i.e. mark every page belonging to a
trail (once for each trail it belongs to).

> Plus I'm still not entirely happy with having ?trail= show up in uris
> all over the place (e.g., in search engine results).

Hmm.. I'm not quite sure why this would happen so often, could you give an 
example?

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

Yeah.. and it'd be annoying for people using another language, they'd 
still be stuck with 'TrailPage' as the name of the category.

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

Ok.
/Christian

Btw, from a book analogy... pages in a book are organized into chapters,
but OTOH a book is typically linear, whereas a the threads through a wiki
site are often more twisted..


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





More information about the pmwiki-users mailing list