HTML-encode meta title, description, guid on output, but not in the pagestate

[git.ikiwiki.info.git] / doc / plugins / contrib / field / discussion.mdwn

diff --git a/doc/plugins/contrib/field/discussion.mdwn b/doc/plugins/contrib/field/discussion.mdwn
index fc1759fab5560995b7b0acfb2864b5d01907feb7..c2b75a76d96a5a2141079b440db0c22e72f8b3de 100644 (file)
--- a/doc/plugins/contrib/field/discussion.mdwn
+++ b/doc/plugins/contrib/field/discussion.mdwn
@@ -9,6 +9,23 @@ with IkiWiki's use of `<TMPL_VAR AUTHOR>` for the author of the *page*
 `<TMPL_VAR FIELD_AUTHOR>` or something? (For those who want the current
 behaviour, an auxiliary plugin would be easy.)
 
 `<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`
 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`


@@ -17,13 +34,22 @@ 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 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.
 
 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 LGPL >= 2.1
+       # Copyright © 2010 Simon McVittie, released under GNU GPL >= 2

        package IkiWiki::Plugin::fieldsort;
        use warnings;
        use strict;
        package IkiWiki::Plugin::fieldsort;
        use warnings;
        use strict;


@@ -42,15 +68,13 @@ I think it should just be part of `field` rather than a separate plugin.
                        },
        }
 
                        },
        }
 

-       package IkiWiki::PageSpec;
+       package IkiWiki::SortSpec;

 
 

-       sub check_cmp_field {
+       sub cmp_field {

                if (!length $_[0]) {
                        error("sort=field requires a parameter");
                }
                if (!length $_[0]) {
                        error("sort=field requires a parameter");
                }

-       }

 
 

-       sub cmp_field {

                my $left = IkiWiki::Plugin::field::field_get_value($_[2], $_[0]);
                my $right = IkiWiki::Plugin::field::field_get_value($_[2], $_[1]);
 
                my $left = IkiWiki::Plugin::field::field_get_value($_[2], $_[0]);
                my $right = IkiWiki::Plugin::field::field_get_value($_[2], $_[1]);
 


@@ -60,3 +84,11 @@ I think it should just be part of `field` rather than a separate plugin.
        }
 
        1;
        }
 
        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]]