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 >>> I think *inline* would be a bit less unwieldy if there was some way of factoring out the feed stuff into a separate plugin, but I don't know if that's possible. --K.A.
  31
  32 Is the intention that the `trail` part is a performance hack, or a way
  33 to select pages? How does it relate to [[todo/wikitrails]] or
  34 [[plugins/contrib/trail]]? --[[smcv]]
  35
  36 > 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.
  37 > 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.
  38 > 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).
  39 > The idea is that, rather than having to add special "trail" links on PageA to indicate that a page is part of the trail,
  40 > 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.
  41 > 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.
  42 > And one can also sort it, if one so desires.
  43 > --[[KathrynAndersen]]
  44
  45 >> That's an interesting approach to trails; I'd missed the fact that
  46 >> links are already ordered.
  47 >>
  48 >> This does have the same problems as tags, though: see
  49 >> [[bugs/tagged()_matching_wikilinks]] and
  50 >> [[todo/matching_different_kinds_of_links]]. I suppose the question
  51 >> now is whether new code should be consistent with `tag` (and
  52 >> potentially be fixed at the same time as tag itself), or try to
  53 >> avoid those problems?
  54 >>
  55 >> The combination of `trail` with another pagespec in this plugin
  56 >> does provide a neat way for it to work around having unwanted
  57 >> pages in the report, by limiting by a suitable tag or subdirectory
  58 >> or something. --s
  59
  60 >>> Either that, or somehow combine tagging with fields, such that one could declare a tag, and it would create both a link and a field with a given value.  (I've been working on something like that, but it still has bugs).
  61 >>> That way, the test for whether something is tagged would be something like "link(tag/foo) and field(tag foo)".
  62 >>> --K.A.