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

chr at home.se chr at home.se
Tue Mar 15 09:50:06 CST 2005


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

> No, I think there are other much cleaner ways to do this.  First, we can 
> generalize the $TrailPage variable to be an array.  But since we're 
> talking about automatically finding and placing pages on trails, let's 
> call it $AutoTrailsFmt:

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. For me the difference is where you conceptually
specify that a page belongs to a trail, but in order to be clear I'll
first define some terms...

  A "trail" is comprised of a "trail map" and one or more "trail pages".  
  The trail map is an ordered list of links to the trail pages, where the
  trail pages are simply normal wiki pages. Let's refer to the page that
  contains the trail map as the "trail map page" (*). Any page (even a
  trail map page) may belong to several trails, i.e. it may be a trail
  page of several trails. The trail manifests itself on trail pages
  through "trail links" that point to
	A) the previous trail page;
	B) the trail map page; and
	C) the next trail page.

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

In order to avoid further confusion, let me rephrase Patrick's suggestion
to show how I understood it.

  A potential trail page should list all the trail maps it might belong to
  through the use of either of these directives:
 
    (:trails <trail-map-page> <trail-map-page> ... :)
    <<|<trail-map-page> <trail-map-page> ...|>>

  These directives may be placed on pages, group headers, group footers 
  and page templates. The key here is that the trail link corresponding 
  to a specific trail map is in *general* only rendered if the current
  page belongs to that trail map. This means that the page will only 
  appear as a trail page if it actually belongs to one of the specified 
  trail maps.

Back to where and how a trail is specified... today a trail that is
working properly needs to be specified on the trail map page as well as on
all its trail pages. Patrick's extended version reduces the effort in
specifying the trail since we could now for instance use (:trails...:) in
GroupHeader-pages to specify *all* trail map pages. This was inpractical
earlier, since <<|TrailPage|>> was rendered even if the current page was
*not* listed on that trail map page.

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.

I might sound a bit negative now and that's not my intention. I do like
this extension, buut it does not achieve what I want. 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). This specifically means that
he shouldn't have to modify all the pages belonging to the trail, nor the
GroupHeader page of each group belonging to the trail pages, nor even a
single extra page in the extremely centralized case.

So what is wrong with having to modify *one* extra page each time you
create another trail?  Well, a minor issue is the extra step(s). Slightly
more important is the fact that the author will have to know which page(s)
to modify in addition to creating the trail map. More importantly however,
it prevents you from creating a trail without junctions. What I mean here
is that if a page always lists all the trails it belongs to, the user
might loose the trail he is following. This will sometimes be a very good
thing, but in other cases you may want to keep the reader on track..
(actually, I often find that I loose my way as it is with all the links on
wiki pages).

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.

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'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.
* The "directive" {?arg} extracts the corresponding argument from the URI.

A better name than (:append-to-page-links:) is probably useful... and 
maybe something like: (:link-append page-links trail={$FullName}:)

/Christian

(*) Note: I separated the concept of "trail map" from "trail map page"
    since we might someday wish to have many trail maps on one page...

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







More information about the pmwiki-users mailing list