[pmwiki-users] Cross-group wiki trails

[Joachim Durchholz]

Patrick R. Michaud wrote:
> Joachim Durchholz wrote:
> 
>>Patrick R. Michaud wrote:
>>
>>> Joachim Durchholz wrote:
>>>
>>>
>>>>I have been unable to produce an example from scratch. However, one of 
>>>>the three wikis I'm administering indeed exhibits the problem. 
>>>
>>>Yes, it's a bug.  I'm working on it now.
>>
>>Is it already fixed in beta27?
> 
> No, it's a significant bug without an easy fix.  It may be a while.

Thanks. I'll advise the author to use full group/page names for the time 
being.

>>> (The ability to create rings is by design.)
>> 
>> Hmm... I understand that having a ring is a Good Thing, but this 
>> particular way of specifying ring-ness doesn't feel right to me. I
>> might want to have the trail just in a single place on the page,
>> and make it a ring.
> 
> The thing that makes a trail into a ring is having a single page
> listed twice in the trail -- not that the trail itself duplicated on
> the page.

Ah, I misunderstood that.

 > Thus:
> 
>     * PageThree
>     * PageFour
>     * PageFive
>     * PageThree
> 
> defines a ring.

Ah, OK.

 > An author can even define a ring in the middle of a
> trail:
> 
>     * PageOne
>     * PageTwo
>     * PageThree
>     * PageFour
>     * PageFive
>     * PageThree

Doesn't sound very useful (*lot*s of potential for confusing readers), 
but it's cute anyway :-)

>> There's one other thing: I'd like to have a way to include the
>> trail index page in the trail itself. I know that this can already
>> can be done by including a self-referential link in the bullet
>> list, but it's quite dumb if a page says "List of Features", and
>> the very first entry on it says "* [[List of Features]]". It would
>> look stupid, and I don't like writing pages that look stupid ;-)
> 
> This is a fairly rare request, but 
> 
>     * [[List of Features]] %item display=none%
>     * [[Another list]] %item comment%
> 
> work just fine -- these place the pages in the trail but don't display
> them on output.

Ah, I didn't know about that.
Scrap the (:trail:) markup idea then. It may be useful, but not for the 
thing I'm thinking about right now.

>> Maybe a trail index page should (optionally) include a directive to
>> control the appearance and general gestalt of trail markups.
>> Something like
>> 
>>  (:trail <options>:)
 >>
>> where each <option> could set up the trail sequence (and, maybe,
>> set other things as well).
> 
> Maybe, but given that I'm a fan of simple implementations, it's not
> likely to happen soon.  I like that a trail is just a simple list of
> pages without having to load lots of other semantics or interpretations
> on top of it.

I agree with the simplicity argument.

I *do* have a nagging feeling that, in the long run, this stance might 
not be a viable one. Trails refer to a central page, and any options 
that affect the trail as a whole should be placed on that page, too.

For now I don't know of any concrete options though, so the simple way 
PmWiki is doing things now suits me fine. Maybe, if no trail extensions 
are ever called for, this might even hold :-)

 > But, trails are already being discussed at
> http://www.pmwiki.org/wiki/PITS/00398 -- you might add this comment
> there.

Done.

I also did a rewrite of http://www.pmwiki.org/wiki/PmWiki/WikiTrails, 
adding examples and restructuring a bit.

Plus there's a set of test pages at pmwiki.org/wiki/Test/TrailIndex, 
with associated TrailPage1, ..., TrailPage4, NonTrailPage1, NonTrailPage2.

HTH.


One aside note: My misdesign indicator twitched slightly when I saw that 
the number of brackets to display is tied to the display of angle 
brackets for the first/last page in the trail. I.e. I have the choice to 
do either

   | TrailIndex | Page2 >

or

   << | TrailIndex | Page2 >>

but I can't have

   < | TrailIndex | Page2 >

or

   | TrailIndex | Page2 >>

I'm not sure what to do about the issue though, or whether it's serious 
enough to be considered at all.

Regards,
Jo