doc/todo/Pagination_next_prev_links.mdwn

   1 I've observed people just seem to get into a dead end whilst reading my ikiwiki instances.
   2
   3 They don't want to back out of post to an index. They want an easy button to click next or previous post, like what you find on Wordpress sites.
   4
   5 <http://codex.wordpress.org/Next_and_Previous_Links>
   6
   7 [Jekyll](http://jekyllrb.com/)'s implementation looks rather neat:
   8
   9 * <https://github.com/mojombo/jekyll/wiki/template-data>
  10 * <https://github.com/mojombo/jekyll/blob/master/lib/jekyll/generators/pagination.rb>
  11
  12
  13
  14 > This is a perfect use for [[todo/wikitrails]], of which my
  15 > [[plugins/contrib/trail]] plugin is an implementation. Code review on that
  16 > plugin would be welcome; it might even get merged one day.
  17 >
  18 >> The trail plugin is very likely to be merged soon, and is already
  19 >> available. So, closing this bug report [[done]] --[[Joey]]
  20 >
  21 > Unfortunately, IkiWiki blogs use a [[ikiwiki/PageSpec]] to define the set of
  22 > "posts" in the blog (through which the next/prev trail should range), and
  23 > the current implementation of [[plugins/contrib/trail]] in terms of typed
  24 > links would have a circular dependency if used with a PageSpec: typed links
  25 > have to be added before PageSpecs are evaluated, because "A links to B" is
  26 > something that can be in a PageSpec; but if you want to add typed links
  27 > ("A is part of trail B" in this case) based on a PageSpec, then the PageSpec
  28 > must be evaluated before the typed links can be added. Chicken/egg.
  29 >
  30 > One solution would be to make the trail plugin use its own data
  31 > structure, like [[plugins/contrib/album]] used to do, instead of typed
  32 > links: at scan time, the trail plugin would just record what the PageSpec
  33 > was, and delay actually *evaluating* the PageSpec until the beginning
  34 > of the `render` stage (after all pages have been scanned). This
  35 > reduces the generic usefulness of typed links, though - in particular
  36 > you can no longer use "is part of trail A" in a PageSpec. --[[smcv]]
  37
  38 >> Version 3 of [[plugins/contrib/trail]] now does this. For `traillink`
  39 >> and `trailitem` it additionally adds a typed link, which it does not
  40 >> itself consume; for `trailinline` and `trail` it doesn't. --[[smcv]]
  41
  42 >>> Indeed, I know the problem; I ran into the same kind of thing with my [[plugins/contrib/report]] plugin and its `trail` concept.
  43 >>> I simply had to declare that one couldn't use "trail" and "maketrail" options within the same report. That way, "maketrail" will add links in the "scan" pass, and "trail" will test for links in the "build" pass.  That usually works. --[[KathrynAndersen]]
  44
  45 >>>> I'm not sure that even that is *quite* right: if your `trail` takes
  46 >>>> pagespecs as arguments, then it's potentially evaluating those pagespecs
  47 >>>> before all pages have been scanned, which could mean it lists pages
  48 >>>> which matched the spec before a recent change, or doesn't list pages
  49 >>>> which didn't previously match the spec but do now.
  50 >>>>
  51 >>>> In version 3 of [[plugins/contrib/trail]] I ended up storing
  52 >>>> uninterpreted pagespecs and links at scan time, and evaluating them the
  53 >>>> first time a page is built. I *think* that's sufficiently lazy to give
  54 >>>> the right answer... --[[smcv]]
  55
  56 >> Do you have an example? --[[hendry]]
  57
  58 >>> Now linked on the plugin's page - it doesn't pretend to be a blog, but
  59 >>> [the second demo](http://demo.hosted.pseudorandom.co.uk/trail2/)
  60 >>> is a `trailinline`, so you could do that with blog posts just as well.
  61 >>> Making [[plugins/contrib/album]] require `trail` v3, and trying it out
  62 >>> on my blog, are next on the list.
  63 >>> --[[smcv]]
  64
  65 >>>> Sorry thank link <http://demo.hosted.pseudorandom.co.uk/trail2/> doesn't work. I get a forbidden. --[[hendry]]
  66
  67
  68 [[wishlist]]