From a7ae9d0b7e16153c389360e8b8b67d3e70488bf4 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Tue, 16 Jun 2009 13:36:55 -0400 Subject: there's more than one way to do it --- doc/todo/wikitrails/discussion.mdwn | 61 +++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) (limited to 'doc') diff --git a/doc/todo/wikitrails/discussion.mdwn b/doc/todo/wikitrails/discussion.mdwn index 327e61491..3ef52c197 100644 --- a/doc/todo/wikitrails/discussion.mdwn +++ b/doc/todo/wikitrails/discussion.mdwn @@ -4,6 +4,8 @@ one-photo-per-page galleries, where each page has previous|up|next links (\[[!inline]] with a specially modified template perhaps). I'll watch this with interest! --[[smcv]] +---- + This is a nice idea, I do have my gripes about the imeplementation. Assuming that the index's list is in mdwn format is not ideal. I guess the @@ -22,3 +24,62 @@ breadcrums to be automatically inserted at the top of every page on the trail. (You'd have to use a directive to define the index for that to work.) --[[Joey]] + +---- + +Revisiting this, after effectively reimplementing a small version of it +in [[plugins/contrib/album]]: it occurs to me that might be a more +"ikiwiki-like" way we could get this functionality. + +In the index page, you either want an [[ikiwiki/directive/inline]], or +a list of links. In the former case, maybe we could extend inline like +this: + + \[[!inline ... blah blah ... trail=yes]] + +to make it remember the pages it inlined, in order, in the pagestate; +in the latter case, we could replace the wikilinks with a directive, +an operation something like this in diff notation: + + - [[one]] - the unit + - [[two]] - the base of binary + - [[three|3]] - is a crowd + + \[[!trailitem one]] - the unit + + \[[!trailitem two]] - the base of binary + + \[[!trailitem three|3]] - is a crowd + +and have that directive remember the pages in order. + +In both cases, a scan() hook could clear the list before starting to +scan, then the inline or trailitem preprocessor directive could run in +the scan stage as well as the render stage (in the case of inline, +there'd be a very early return if trail=yes was not given, and +an early return after collecting and sorting the pages if not +actually rendering). + +This would mean that the contents of the trail, and a list of +trails in which each page can be found, would already be in +the pagestate by the time any page was rendered, so we'd be able +to use them for output, either in a pagetemplate() hook or +a \[[!trail]] preprocessor directive. + +This way, my album plugin could be turned inside out: instead +of precomputing the pages to be inlined, then using +[[pagenames|todo/inline plugin: specifying ordered page names]] +to get them into the inline, it could just do the inline, then +incorporate the output of \[[!trail]] into the template rendered +for \[[!albumimage]] on each viewer page. (Also, the viewers +wouldn't necessarily need to reference the album, only the other +way round.) + +Using a pagetemplate() hook to stuff the next/previous links +into page.tmpl would actually be a bit unfortunate for \[[!album]], +because that plugin definitely wants to style the next/previous +links as a thumbnail, which means there'd have to be a way to +affect the style - perhaps by arranging for album's pagetemplate +hook to run *after* trail's, or perhaps by having trail's +pagetemplate hook disable itself for pages that contain +a \[[!trail]] directive. + +Does this sound viable? Should I think about implementing it? +--[[smcv]] -- cgit v1.2.3