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 Thank you
   8
   9 > This is a perfect use for [[todo/wikitrails]], of which my
  10 > [[plugins/contrib/trail]] plugin is an implementation. Code review on that
  11 > plugin would be welcome; it might even get merged one day.
  12 >
  13 > Unfortunately, IkiWiki blogs use a [[ikiwiki/PageSpec]] to define the set of
  14 > "posts" in the blog (through which the next/prev trail should range), and
  15 > the current implementation of [[plugins/contrib/trail]] in terms of typed
  16 > links would have a circular dependency if used with a PageSpec: typed links
  17 > have to be added before PageSpecs are evaluated, because "A links to B" is
  18 > something that can be in a PageSpec; but if you want to add typed links
  19 > ("A is part of trail B" in this case) based on a PageSpec, then the PageSpec
  20 > must be evaluated before the typed links can be added. Chicken/egg.
  21 >
  22 > One solution would be to make the trail plugin use its own data
  23 > structure, like [[plugins/contrib/album]] used to do, instead of typed
  24 > links: at scan time, the trail plugin would just record what the PageSpec
  25 > was, and delay actually *evaluating* the PageSpec until the beginning
  26 > of the `render` stage (after all pages have been scanned). This
  27 > reduces the generic usefulness of typed links, though - in particular
  28 > you can no longer use "is part of trail A" in a PageSpec. --[[smcv]]