1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
Having tried out `field`, some comments (from [[smcv]]):
The general concept looks great.
The `pagetemplate` hook seems quite namespace-polluting: on a site containing
a list of books, I'd like to have an `author` field, but that would collide
with IkiWiki's use of `<TMPL_VAR AUTHOR>` for the author of the *page*
(i.e. me). Perhaps it'd be better if the pagetemplate hook was only active for
`<TMPL_VAR FIELD_AUTHOR>` or something? (For those who want the current
behaviour, an auxiliary plugin would be easy.)
> 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.
>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).
>--[[KathrynAndersen]]
>> Hmm. I suppose if you put the title (or whatever) in the YAML, then
>> "almost" all the places in IkiWiki that respect titles will do the
>> right thing due to the pagetemplate hook, with the exception being
>> anything that has special side-effects inside `meta` (like `date`),
>> or anything that looks in `$pagestate{foo}{meta}` directly
>> (like `map`). Is your plan that `meta` should register itself by
>> default, and `map` and friends should be adapted to
>> work based on `getfield()` instead of `$pagestate{foo}{meta}`, then?
>>
>> (On the site I mentioned, I'm using an unmodified version of `field`,
>> and currently working around the collision by tagging books' pages
>> with `bookauthor` instead of `author` in the YAML.) --s
From a coding style point of view, the `$CamelCase` variable names aren't
IkiWiki style, and the `match_foo` functions look as though they could benefit
from being thin wrappers around a common `&IkiWiki::Plugin::field::match`
function (see `meta` for a similar approach).
I think the documentation would probably be clearer in a less manpage-like
and more ikiwiki-like style?
> 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]]
>> I keep getting distracted by the big shouty headings :-)
>> I suppose what I was really getting at was that when this plugin
>> is merged, its docs will end up split between its plugin
>> page, [[plugins/write]] and [[ikiwiki/PageSpec]]; on some of the
>> contrib plugins I've added I've tried to separate the docs
>> according to how they'll hopefully be laid out after merge. --s
If one of my branches from [[todo/allow_plugins_to_add_sorting_methods]] is
accepted, a `field()` cmp type would mean that [[plugins/contrib/report]] can
stop reimplementing sorting. Here's the implementation I'm using, with
your "sortspec" concept (a sort-hook would be very similar): if merged,
I think it should just be part of `field` rather than a separate plugin.
# Copyright © 2010 Simon McVittie, released under GNU GPL >= 2
package IkiWiki::Plugin::fieldsort;
use warnings;
use strict;
use IkiWiki 3.00;
use IkiWiki::Plugin::field;
sub import {
hook(type => "getsetup", id => "fieldsort", call => \&getsetup);
}
sub getsetup () {
return
plugin => {
safe => 1,
rebuild => undef,
},
}
package IkiWiki::SortSpec;
sub cmp_field {
if (!length $_[0]) {
error("sort=field requires a parameter");
}
my $left = IkiWiki::Plugin::field::field_get_value($_[2], $_[0]);
my $right = IkiWiki::Plugin::field::field_get_value($_[2], $_[1]);
$left = "" unless defined $left;
$right = "" unless defined $right;
return $left cmp $right;
}
1;
-------
Bug report: `field` has an unnecessary `use YAML::Any`, presumably from before
you separated out `ymlfront`. Trivial patch available from
field-etc branch in git://git.pseudorandom.co.uk/git/smcv/ikiwiki.git (gitweb:
<http://git.pseudorandom.co.uk/smcv/ikiwiki.git?a=shortlog;h=refs/heads/field-etc>)
--[[smcv]]
|