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 >> A fair point; perhaps my complaint should be that *inline* does
  24 >> too many orthogonal things. I suppose the headers feature wouldn't
  25 >> really make sense in an inline that didn't have `archive="yes"`,
  26 >> so it'd make sense to recommend this plugin as a replacement
  27 >> for inlining with archive=yes (for which I now realise "inline"
  28 >> is the wrong verb anyway :-) ) --s
  29
  30 Is the intention that the `trail` part is a performance hack, or a way
  31 to select pages? How does it relate to [[todo/wikitrails]] or
  32 [[plugins/contrib/trail]]? --[[smcv]]
  33
  34 > 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.
  35 > 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.
  36 > 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).
  37 > The idea is that, rather than having to add special "trail" links on PageA to indicate that a page is part of the trail,
  38 > 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.
  39 > 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.
  40 > And one can also sort it, if one so desires.
  41 > --[[KathrynAndersen]]
  42
  43 >> That's an interesting approach to trails; I'd missed the fact that
  44 >> links are already ordered.
  45 >>
  46 >> This does have the same problems as tags, though: see
  47 >> [[bugs/tagged()_matching_wikilinks]] and
  48 >> [[todo/matching_different_kinds_of_links]]. I suppose the question
  49 >> now is whether new code should be consistent with `tag` (and
  50 >> potentially be fixed at the same time as tag itself), or try to
  51 >> avoid those problems?
  52 >>
  53 >> The combination of `trail` with another pagespec in this plugin
  54 >> does provide a neat way for it to work around having unwanted
  55 >> pages in the report, by limiting by a suitable tag or subdirectory
  56 >> or something. --s