comment

[ikiwiki.git] / doc / forum / an_alternative_approach_to_structured_data.mdwn

diff --git a/doc/forum/an_alternative_approach_to_structured_data.mdwn b/doc/forum/an_alternative_approach_to_structured_data.mdwn
index fb007f7e96fd349cab2036f366814dacf56f967f..06c82337af142a321c4778e444c3d11a8135babd 100644 (file)
--- a/doc/forum/an_alternative_approach_to_structured_data.mdwn
+++ b/doc/forum/an_alternative_approach_to_structured_data.mdwn
@@ -1,3 +1,5 @@
+## First Pass
+
 Looking at the discussion about [[todo/structured_page_data]], it looks a bit like folks are bogged down in figuring out what *markup* to use for structured page data, something I doubt that people will really agree on.  And thus, little progress is made.
 
 I propose that, rather than worry about what the data looks like, that we take a similar approach
@@ -15,3 +17,45 @@ I think it could be really powerful and useful, especially if it becomes part of
 --[[KathrynAndersen]]
 
 > It looks like an interesting idea.  I don't have time right now to look at it in depth, but it looks interesting. -- [[Will]]
+
+> I agree such a separation makes some sense. But note that the discussion on [[todo/structured_page_data]]
+> talks about associating data types with fields for a good reason: It's hard to later develop a good UI for
+> querying or modifying a page's data if all the data has an implicit type "string". --[[Joey]] 
+
+## Second Pass
+
+I have written additional plugins which integrate with the [[plugins/contrib/field]] plugin to both set and get structured page data.
+
+* [[plugins/contrib/getfield]] - query field values inside a page using {{$*fieldname*}} markup
+* [[plugins/contrib/ftemplate]] - like [[plugins/template]] but uses "field" data as well as passed-in data
+* [[plugins/contrib/ymlfront]] - looks for YAML-format data at the front of a page; this is just one possible back-end for the structured data
+
+--[[KathrynAndersen]]
+
+> I'm not an IkiWiki committer ([[Joey]] is the only one I think)
+> but I really like the look of this scheme. In particular,
+> having `getfield` interop with `field` without being *part of*
+> `field` makes me happy, since I'm not very keen on `getfield`'s
+> syntax (i.e. "ugh, yet another mini-markup-language without a
+> proper escaping mechanism"), but this way people can experiment
+> with different syntaxes while keeping `field` for the
+> behind-the-scenes bits.
+>
+>> I've started using `field` on a private site and it's working
+>> well for me; I'll try to do some code review on its
+>> [[plugins/contrib/field/discussion]] page. --s
+>
+> My [[plugins/contrib/album]] plugin could benefit from
+> integration with `field` for photos' captions and so on,
+> probably... I'll try to work on that at some point.
+>
+> [[plugins/contrib/report]] may be doing too much, though:
+> it seems to be an variation on `\[[inline archive="yes"]]`,
+> with an enhanced version of sorting, a mini version of
+> [[todo/wikitrails]], and some other misc. I suspect it could
+> usefully be divided up into discrete features? One good way
+> to do that might be to shuffle bits of its functionality into
+> the IkiWiki distribution and/or separate plugins, until there's
+> nothing left in `report` itself and it can just go away.
+>
+> --[[smcv]]