]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/plugins/contrib/report/discussion.mdwn
Merge branch 'master' of ssh://git.ikiwiki.info
[git.ikiwiki.info.git] / doc / plugins / contrib / report / discussion.mdwn
index a6cb6f8bda68e971e992197338c7328277a6c85f..419c4bca62898c3539f4a9a08e1a4dc006076c39 100644 (file)
@@ -27,6 +27,8 @@ lead to making inline too big, though.
 >> for inlining with archive=yes (for which I now realise "inline"
 >> is the wrong verb anyway :-) ) --s
 
 >> for inlining with archive=yes (for which I now realise "inline"
 >> is the wrong verb anyway :-) ) --s
 
+>>> I think *inline* would be a bit less unwieldy if there was some way of factoring out the feed stuff into a separate plugin, but I don't know if that's possible. --K.A.
+
 Is the intention that the `trail` part is a performance hack, or a way
 to select pages? How does it relate to [[todo/wikitrails]] or
 [[plugins/contrib/trail]]? --[[smcv]]
 Is the intention that the `trail` part is a performance hack, or a way
 to select pages? How does it relate to [[todo/wikitrails]] or
 [[plugins/contrib/trail]]? --[[smcv]]
@@ -54,3 +56,25 @@ to select pages? How does it relate to [[todo/wikitrails]] or
 >> does provide a neat way for it to work around having unwanted
 >> pages in the report, by limiting by a suitable tag or subdirectory
 >> or something. --s
 >> does provide a neat way for it to work around having unwanted
 >> pages in the report, by limiting by a suitable tag or subdirectory
 >> or something. --s
+
+>>> Either that, or somehow combine tagging with fields, such that one could declare a tag, and it would create both a link and a field with a given value.  (I've been working on something like that, but it still has bugs).
+>>> That way, the test for whether something is tagged would be something like "link(tag/foo) and field(tag foo)".
+>>> --K.A.
+
+>>>> I can see that this'd work well for 1:1 relationships like next
+>>>> and previous, but I don't think that'd work for pages with more than
+>>>> one tag - as far as I can see, `field`'s data model is that each
+>>>> page has no more than one value for each field?
+>>>> [[todo/Matching_different_kinds_of_links]] has some thoughts about
+>>>> how it could be implemented, though. --s
+
+>>>>> You have a point there.  I'm not sure what would be better: to add the concept of arrays/sets to `field`, or to think of tags as a special case.  Problem is, I find tags as they currently exist to be too limiting.  I prefer something that can be used for Faceted Tagging <http://en.wikipedia.org/wiki/Faceted_classification>; that is, things like Author:Fred Nurk, Genre:Historical, Rating:Good, and so on.  Of course, that doesn't mean that each tag is limited to only one value, either; just to take the above examples, something might have more than one author, or have multiple genres (such as Historical + Romance).
+
+>>>>> It might be that adding arrays to the `field` plugin is a good way to go: after all, even though field=value is the most common, with the flexibility of things like YAML, one could define all sorts of things.  What I'm not so sure about is how to return the values when queried, since some things would be expecting scalars all the time.  Ah, perhaps I could use wantarray?
+>>>>> Is there a way of checking a HTML::Template template to see if it expecting an array for a particular value?
+>>>>> --[[KathrynAndersen]]
+
+How about arrays?
+-----------------
+
+In [[plugins/contrib/getfield/discussion]], I outline how there's a problem in getfield displaying array refs when the data is a YAML array. I also propose a patch there so that arrays are join'd with a space separator, which is less than ideal, but at least works for getfield. However, for report, I am not sure it's as good. Should it make two rows for those? How should we parse this? Thanks. -- [[anarcat]]