aboutsummaryrefslogtreecommitdiff
path: root/doc/todo/wikitrails
diff options
context:
space:
mode:
authorhttp://smcv.pseudorandom.co.uk/ <http://smcv.pseudorandom.co.uk/@web>2009-06-16 13:36:55 -0400
committerJoey Hess <joey@kitenet.net>2009-06-16 13:36:55 -0400
commita7ae9d0b7e16153c389360e8b8b67d3e70488bf4 (patch)
tree12f0546aac98ef049acf84ad56118f6d8cab70de /doc/todo/wikitrails
parent37617af685aaf2d0d47dd86e6a45e48570bc9ca9 (diff)
downloadikiwiki-a7ae9d0b7e16153c389360e8b8b67d3e70488bf4.tar
ikiwiki-a7ae9d0b7e16153c389360e8b8b67d3e70488bf4.tar.gz
there's more than one way to do it
Diffstat (limited to 'doc/todo/wikitrails')
-rw-r--r--doc/todo/wikitrails/discussion.mdwn61
1 files changed, 61 insertions, 0 deletions
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]]