128 lines
6.6 KiB
Markdown
128 lines
6.6 KiB
Markdown
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?
|
|
|
|
>>> Based on `field_get_value()`, yes. That would be my ideal. Do you think I should implement that as an ikiwiki branch? --[[KathrynAndersen]]
|
|
|
|
>> (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]]
|
|
|
|
> Can do for the field plugin (delete one line? Easy.) Will push when I get to a better connection. --[[KathrynAndersen]]
|
|
>> Done! -K.A.
|
|
|
|
----
|
|
|
|
Disclaimer: I've only looked at this plugin and ymlfront, not other related
|
|
stuff yet. (I quite like ymlfront, so I looked at this as its dependency. :)
|
|
I also don't want to annoy you with a lot of design discussion
|
|
if your main goal was to write a plugin that did exactly what you wanted.
|
|
|
|
My first question is: Why we need another plugin storing metadata
|
|
about the page, when we already have the meta plugin? Much of the
|
|
complication around the field plugin has to do with it accessing info
|
|
belonging to the meta plugin, and generalizing that to be able to access
|
|
info stored by other plugins too. (But I don't see any other plugins that
|
|
currently store such info). Then too, it raises points of confusion like
|
|
smcv's discuission of field author vs meta author above. --[[Joey]]
|
|
|
|
> The point is exactly in the generalization, to provide a uniform interface for accessing structured data, no matter what the source of it, whether that be the meta plugin or some other plugin.
|
|
|
|
> There were a few reasons for this:
|
|
|
|
>1. In converting my site over from PmWiki, I needed something that was equivalent to PmWiki's Page-Text-Variables (which is how PmWiki implements structured data).
|
|
>2. I also wanted an equivalent of PmWiki's Page-Variables, which, rather than being simple variables, are the return-value of a function. This gives one a lot of power, because one can do calculations, derive one thing from another. Heck, just being able to have a "basename" variable is useful.
|
|
>3. I noticed that in the discussion about structured data, it was mired down in disagreements about what form the structured data should take; I wanted to overcome that hurdle by decoupling the form from the content.
|
|
>4. I actually use this to solve (1), because, while I do use ymlfront, initially my pages were in PmWiki format (I wrote (another) unreleased plugin which parses PmWiki format) including PmWiki's Page-Text-Variables for structured data. So I needed something that could deal with multiple formats.
|
|
|
|
> So, yes, it does cater to mostly my personal needs, but I think it is more generally useful, also.
|
|
> --[[KathrynAndersen]]
|
|
|