doc/plugins/contrib/report/discussion.mdwn

   1 Wow, this plugin does a lot... it seems to be `inline` (but without the feeds
   2 or the ability to not have `archive="yes"`), plus part of
   3 [[plugins/contrib/trail]], plus some sorting, plus an ingenious workaround
   4 for template evaluation being relatively stateless.
   5
   6 A large part of this plugin would just fall off if one of the versions of
   7 "[[todo/allow_plugins_to_add_sorting_methods]]" was merged, which was a
   8 large part of the idea of that feature request :-) To make use of that
   9 you'd have to use `pagespec_match_list` in the trail case too, but that's
  10 easy enough - just add `list => [@the_trail_pages]` to the arguments.
  11
  12 Another large part would fall off if this plugin required, and internally
  13 invoked, `inline` (like my `comments` plugin does) - `inline` runs
  14 `pagetemplate` hooks, and in particular, it'll run the `field` hook.
  15 Alternatively, this plugin could invoke `pagetemplate` hooks itself,
  16 removing the special case for `field`.
  17
  18 Perhaps the `headers` thing could migrate into inline somehow? That might
  19 lead to making inline too big, though.
  20
  21 > I think inline is *already* too big, honestly. --[[KathrynAndersen]]
  22
  23 Is the intention that the `trail` part is a performance hack, or a way
  24 to select pages? How does it relate to [[todo/wikitrails]] or
  25 [[plugins/contrib/trail]]? --[[smcv]]
  26
  27 > The `trail` part is *both* a performance hack, and a way to select pages.  I have over 5000 pages on my site, I need all the performance hacks I can get.
  28 > For the performance hack, it is a way of reducing the need to iterate through every single page in the wiki in order to find matching pages.
  29 > For the way-to-select-pages, yes, it is intended to be similar to [[todo/wikitrails]] and [[plugins/contrib/trail]] (and will be more similar with the new release which will be happening soon; it will add prev_* and next_* variables).
  30 > The idea is that, rather than having to add special "trail" links on PageA to indicate that a page is part of the trail,
  31 > it takes advantage of the `%links` hash, which already contains, for each page, an array of the links from that page to other pages.  No need for special markup, just use what's there; a trail is defined as "all the pages linked to from page X", and since it's an array, it has an order already.
  32 > But to avoid that being too limiting, one can use a `pages=...` pagespec to filter that list to a subset; only the pages one is interested in.
  33 > And one can also sort it, if one so desires.
  34 > --[[KathrynAndersen]]