[Pmwiki-users] More on WikiTrail

John Rankin john.rankin at affinity.co.nz
Wed Nov 6 15:50:44 CST 2002


> (Just joined the list) I like the idea of listing the stops in a=20
> vertical column, showing the current stop and the trail name. Look=20
> forward to seeing it. What happens if a page is on 2 trails or is=20
> this disallowed?

Multiple trails would be allowed but would be presented as multiple
menus, and also the wiki administrator would have to be fairly savvy about
being able to code it into the system.  I'm not planning to do vertical
column display of trails with wiki markup--it'd have to be something=20
directly enabled in PHP/HTML by the wiki administrator (relatively easy=20
for one trail, more complicated for multiple trails).

> Pushing my luck: would it be useful if on the page specifying the list =
of stops the author could choose to show (say) the first sentence / 15 =
words of fame or whatever from the stop page?=20

Yes, you might be pushing your luck.  :-)  But I'd say even this is =
possible
as a customization, if we define a special markup for it (the "T:stop" =
markup
you suggested might work).  But I feel a "slippery slope" here again;
after having the first few words of text from the target page, folks will
want to be able to add date/time of last revision for the target page, and
we start getting into weird markup details again.  I might code up a
sample add-on script just to show how it could be done, but it would =
likely
be a per-wiki customization and not anything that ever evolved to be a=20
PmWiki "standard feature".

Also, in converting T:stop to :stop:text, would we need to strip out=20
the markup from the target page?  I would think so, but am curious as to
what you had in mind there...
----
Up to a point, Minister. One reason wiki works is it brings "power through =
simplicity, simplicity through generality".=20

If wiki add-in does its T:stop to :stop:text before the rest of the page =
rendering happens, then I'd have thought it could cope with most in-line =
mark-up, except perhaps [[include:wikiword]] (which might reasonably be =
translated into wikiword). Even a first sentence of the form :text:=
moretext ought to do something sensible, if unexpected. To be consistent =
with the rest of the mark-up rules (invoking the "simplicity" clause), =
probably the terminator of the T: syntax would be a /n in the stop page, =
rather than the first period. Then first sentence is just a special case =
under author control.

I see no reason to go down a slippery slope. Invoking the "generality" =
clause, folk should only be able to do things with T:stop that they can do =
with existing mark-up. Using your example of date/time of last revision, =
according to BracketAbuse, [[$LastModified]] already provides this feature.=
 An author could reasonably expect to include it in a first paragraph and =
have it appear on the trail page. If that's possible. So it becomes a =
design decision on which *existing* mark-up the add-in will cope with. See =
paragraph above. Short answer: if the existing engine will correctly =
translate [[$LastModified]] when it comes from a stop page, great; if not, =
don't add new mark-up to create a special case.
----
> I can't help feeling that ideally, the chosen mark-up would ensure a=20
> trail knows its pages *and* a page knows its trail.

Well, the existing implementation has this, -except- that it's possible =
for
the trailpage to know about pages that don't have the trail markup, and it'=
s
possible for other pages to have the trail markup without being listed on
the trailpage.  I think that what you're really saying is that there needs
to be synchronization between the trailpage and the pages on the trail, =
and
I don't see a way of doing this without changing PmWiki's file structure,
directly modifying wiki page contents, and/or performing text searches=20
through multiple trail pages.

Having PmWiki automatically add trail links if the reader followed
a trail link to arrive at the current page might work, but it kinda bugs
me that someone arriving at the same page via a non-trail link doesn't see
that the page is part of a trail.  So I'm not entirely comfortable with=20
the auto-trail-generation approach, even though I have a few ideas about=20
how it might be implemented.  A few real-world examples of where it's =
really
needed or would be used would really help (see PmWikiPhilosophy #3:=20
implement features in response to specific needs).
----
I would add this question to a "Should PmWiki sit over a MySQL (or =
whatever) database" discussion (if one exists). If it did, then trail/stop =
pairs would get normalised out into a separate table and "trails knows =
their pages" and "pages know their trails" and the information is held =
once and there is no risk of inconsistency. In the mean time, I probably =
wouldn't try to build auto-generation features into a file-based system, '=
cos it will probably be fraught. (Don't get the wrong idea; I am not =
advocating that PmWiki go down a MySQL route.)

As it's not a relational system, the design work-around is to hold the =
data in 2 places -- the trail page and the stop page. Since wiki shows us =
where these are out of step and it's really easy to fix them up, I don't =
see it a big deal.
----
I'm planning to spend another day or so cleaning up my existing trail.php
add-on script a bit and then I'll release it for others to experiment with
in their own wiki sites.

Pm
----
I look forward to it. JR







More information about the pmwiki-users mailing list