doc/plugins/contrib/field/discussion.mdwn

   1 Having tried out `field`, some comments (from [[smcv]]):
   2
   3 The general concept looks great.
   4
   5 The `pagetemplate` hook seems quite namespace-polluting: on a site containing
   6 a list of books, I'd like to have an `author` field, but that would collide
   7 with IkiWiki's use of `<TMPL_VAR AUTHOR>` for the author of the *page*
   8 (i.e. me). Perhaps it'd be better if the pagetemplate hook was only active for
   9 `<TMPL_VAR FIELD_AUTHOR>` or something? (For those who want the current
  10 behaviour, an auxiliary plugin would be easy.)
  11
  12 > No, please.  The idea is to be *able* to override field names if one wishes to, and choose, for yourself, non-colliding field names if one wishes not to.  I don't wish to lose the power of being able to, say, define a page title with YAML format if I want to, or to write a site-specific plugin which calculates a page title, or other nifty things.
  13 >It's not like one is going to lose the fields defined by the meta plugin; if "author" is defined by \[[!meta author=...]] then that's what will be found by "field" (provided the "meta" plugin is registered; that's what the "field_register" option is for).
  14 >--[[KathrynAndersen]]
  15
  16 From a coding style point of view, the `$CamelCase` variable names aren't
  17 IkiWiki style, and the `match_foo` functions look as though they could benefit
  18 from being thin wrappers around a common `&IkiWiki::Plugin::field::match`
  19 function (see `meta` for a similar approach).
  20
  21 I think the documentation would probably be clearer in a less manpage-like
  22 and more ikiwiki-like style?
  23
  24 > I don't think ikiwiki *has* a "style" for docs, does it?  So I followed the Perl Module style. And I'm rather baffled as to why having the docs laid out in clear sections... make them less clear. --[[KathrynAndersen]]
  25
  26 If one of my branches from [[todo/allow_plugins_to_add_sorting_methods]] is
  27 accepted, a `field()` cmp type would mean that [[plugins/contrib/report]] can
  28 stop reimplementing sorting. Here's the implementation I'm using, with
  29 your "sortspec" concept (a sort-hook would be very similar): if merged,
  30 I think it should just be part of `field` rather than a separate plugin.
  31
  32         # Copyright © 2010 Simon McVittie, released under GNU LGPL >= 2.1
  33         package IkiWiki::Plugin::fieldsort;
  34         use warnings;
  35         use strict;
  36         use IkiWiki 3.00;
  37         use IkiWiki::Plugin::field;
  38
  39         sub import {
  40                 hook(type => "getsetup", id => "fieldsort",  call => \&getsetup);
  41         }
  42
  43         sub getsetup () {
  44                 return
  45                         plugin => {
  46                                 safe => 1,
  47                                 rebuild => undef,
  48                         },
  49         }
  50
  51         package IkiWiki::PageSpec;
  52
  53         sub check_cmp_field {
  54                 if (!length $_[0]) {
  55                         error("sort=field requires a parameter");
  56                 }
  57         }
  58
  59         sub cmp_field {
  60                 my $left = IkiWiki::Plugin::field::field_get_value($_[2], $_[0]);
  61                 my $right = IkiWiki::Plugin::field::field_get_value($_[2], $_[1]);
  62
  63                 $left = "" unless defined $left;
  64                 $right = "" unless defined $right;
  65                 return $left cmp $right;
  66         }
  67
  68         1;