|
PITS /
00398Summary: enhancements to wiki trails
Created: 2005-03-19 00:38
Status: Suspended
Category: Feature
From: jr
Assigned:
Priority: 55554 4
Version: beta26
OS: all
Description: The mailing list has had various threads about navigating wiki trails and wiki categories. This is a summary. The requirements range from lite -- minor but useful extensions to existing capabilities -- to full strength -- major extensions to the power of trails -- to heavy duty -- the suburban assault (er, utility) vehicle hits the trail. Sorry to be picky, but should these not be different issues? I mean, which of these versions did I just vote for? :) -Radu
I guess you voted for as much as Pm wants to do, starting at the top and working down the page... Full Strength builds on Lite and Heavy Duty builds on Full Strength.
There is an opportunity to clarify the ways in which PmWiki/WikiTrails and Categories can complement one another. This page assumes you are familiar with both sets of capabilities. A trail page is like a table of contents; the category group is like an index. The following discussion uses the Contributors include chr, Pm, Radu, and others. Trails Lite (do now)Authors commonly put trail markup in a GroupHeader or a template. Provide a way to suppress trail output if the current page is off-trail:
Use DynamicWikiTrails trails, the URL determines whether a page is on or off trail. With the introduction of categories, authors want to use a category page as an automatically-maintained trail. How is this going to be maintained if the categories are dynamic? I mean, you can't make a trail simply by alphabetical order of page names or some such; the best feature of a trail is that people can decide on the order of the pages in the trail. -Radu Um, why not? If you need to define the order, use a manual trail page, not a category page. TINFL Always suppress trail output if the current page is off-trail:
With some pages containing multiple trails, we need a simple method to list multiple trail pages. Also, some people prefer directives to markup:
Use DynamicTrails, DynamicWikiTrails and PageListExtensions to automatically list all the trails the pages is on. Trails Full Strength (do later)It should be easy for an author to set up a new trail page and automatically get trail navigation links, without having to add new markup to the pages on the trail:
Um. Why not create the trail navigation from the trail pages? Why go to all the pages? -Radu Because then the author has to add <<|?NewTrailPage|>> to one or more GroupHeader pages. This way, the author only has to write [[!trail]] on the new trail page and all pages on the trail automatically get trail navigation.
There is nothing special about the words Now we turn to the question of dynamically turning trail navigation on and off, depending on what the visitor clicks... When a visitor arrives on a page for the first time, all trails through that page should be "lit". When the visitor starts following a trail, other trails through the current page should "turn off". If the visitor leaves the trail for another page, such as by following an off-trail link, any trails through the new page should light up. So:
This can be done with a combination of: DynamicTrails, DynamicWikiTrails and PageListExtensions. And this works whether the ?trail= a static wiki trail or a dynamic category trail. Trails Heavy Duty (do one day)But there is yet more we could do... An author may want to control the placement of the trail navigation on the page, using trail information from the GroupHeader, GroupFooter or template:
With DynamicWikiTrails an author may control the placement of the output. An author may want to create a hierarchy of categories with associated trail navigation:
CatPage
PageA
PageA1
PageA2
PageB
PageB1
PageB2
And somehow generating trail navigation using category pages has to be fast, so PmWiki can't search every page of the wiki every time to build the trail of pages in that category:
Trail extensions (possibly never necessary)If there's ever a need to centrally define stuff for a given trail, that should be done on the trail page (the alternative would be redundant repetition on every page that sports the trail markup, which is usually a very, very bad idea). In that case, we'd probably need a markup like Joachim Durchholz March 27, 2005, at 09:37 AM |