Multiple values arrays

This breaks if there are multiple values for a single key. It works fine in the report plugin, but inline display shows the ARRAY reference, e.g.

IPv6:
- fd64:2c08:9fa7:4::1
- 2001:470:1d:4a6::1

and:

{{$IPv6}}

yields:

ARRAY(0x266db10)

Seems to me this could be checked and join(" ")'d. :) -- anarcat

I wrote a stupid fix for this, which works for getfield, but isn't as good for report. It simply does that join(). Here's the patch:

--- a/IkiWiki/Plugin/field.pm
+++ b/IkiWiki/Plugin/field.pm
@@ -322,6 +322,9 @@ sub field_get_value ($$;@) {
     {
        $basevalue = calculated_values($lc_field_name, $page);
     }
+    if (ref($basevalue) eq "ARRAY") {
+        $basevalue = join(" ", @{$basevalue}); # hack
+    }
     if (defined $basevalue)
     {
        $Cache{$page}{$basename} = $basevalue;
@@ -360,6 +363,9 @@ sub field_get_value ($$;@) {
     {
        $value = $basevalue;
     }
+    if (ref($value) eq "ARRAY") {
+        $value = join(" ", @{$value}); # hack
+    }
     if (defined $value)
     {
        $Cache{$page}{$lc_field_name} = $value;

Seems to me this should be the default, at the very least in getfield. But at least, with the above patch we don't see expanded Perl ref's. --anarcat

Templating, and other uses

Like you mentioned in ftemplate IIRC, it'll only work on the same page. If it can be made to work anywhere, or from a specific place in the wiki - configurable, possibly - you'll have something very similar to mediawiki's templates. I can already think of a few uses for this combined with template . --SR

Yes, I mentioned "only current page" in the "LIMITATIONS" section.

What do you think would be a good syntax for querying other pages? It needs to resolve to a single page, though I guess using "bestlink" to find the closest page would mean that one didn't have to spell out the whole page.

I don't know the internals very well, I think that's how other plugins do it. goes to check Usually it's a foreach loop, and use a pagestate{foo} to check the page's status/state. There's also some stuff like 'pagespec_match_list($params{page}` ... they do slightly different thing depending on need. --SR

No, I meant what markup I should use; the actual implementation probably wouldn't be too difficult.

The current markup is {{$fieldname}}; what you're wanting, perhaps it should be represented like {{$pagename:fieldname}}, or {{$pagename::fieldname}} or something else... -- KathrynAndersen

Oh. Hmm. I like your idea actually, or alternately, in keeping more with other plugins, doing it like {{pagename/fieldname}}. The meaning of the separator is less clear with /, but avoids potential issues with filename clashes that have a colon in them. It also keeps a certain logic - at least to me. Either way, I think both are good choices. SR

What about using {{pagename#fieldname}}? The meaning of the hash in URLs sort of fits with what is needed here (reference to a 'named' thing within the page) and it won't conflict with actual hash usages (unless we expect different named parts of pages to define different values for the same field ...) -- Oblomov

That's a good one too. --simonraven

Done! I used {{$pagename#fieldname}} for the format. -- KathrynAndersen

I'm also working on a "report" plugin, which will basically apply a template like ftemplate does, but to a list of pages given from a pagespec, rather than the current page.

-- KathrynAndersen

Ooh, sounds nice . --SR

I've now released the report plugin. I've been using it on my site; the holdup on releasing was because I hadn't yet written the docs for it. I hope you find it useful. -- KathrynAndersen