doc/forum/an_alternative_approach_to_structured_data.mdwn

   1 ## First Pass
   2
   3 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.
   4
   5 I propose that, rather than worry about what the data looks like, that we take a similar approach
   6 to the way Revision Control Systems are used in ikiwiki: a front-end + back-end approach.
   7 The front-end would be a common interface, where queries are made about the structured data,
   8 and there would be any number of back-ends, which could use whatever markup or format that they desired.
   9
  10 To that purpose, I've written the [[plugins/contrib/field]] plugin for a possible front-end.
  11 I called it "field" because each page could be considered a "record" where one could request the values of "fields" of that record.
  12 The idea is that back-end plugins would register functions which can be called when the value of a field is desired.
  13
  14 This is gone into in more depth on the plugin page itself, but I would appreciate feedback and improvements on the approach.
  15 I think it could be really powerful and useful, especially if it becomes part of ikiwiki proper.
  16
  17 --[[KathrynAndersen]]
  18
  19 > It looks like an interesting idea.  I don't have time right now to look at it in depth, but it looks interesting. -- [[Will]]
  20
  21 > I agree such a separation makes some sense. But note that the discussion on [[todo/structured_page_data]]
  22 > talks about associating data types with fields for a good reason: It's hard to later develop a good UI for
  23 > querying or modifying a page's data if all the data has an implicit type "string". --[[Joey]]
  24
  25 ## Second Pass
  26
  27 I have written additional plugins which integrate with the [[plugins/contrib/field]] plugin to both set and get structured page data.
  28
  29 * [[plugins/contrib/getfield]] - query field values inside a page using {{$*fieldname*}} markup
  30 * [[plugins/contrib/ftemplate]] - like [[plugins/template]] but uses "field" data as well as passed-in data
  31 * [[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
  32
  33 --[[KathrynAndersen]]
  34
  35 > I'm not an IkiWiki committer ([[Joey]] is the only one I think)
  36 > but I really like the look of this scheme. In particular,
  37 > having `getfield` interop with `field` without being *part of*
  38 > `field` makes me happy, since I'm not very keen on `getfield`'s
  39 > syntax (i.e. "ugh, yet another mini-markup-language without a
  40 > proper escaping mechanism"), but this way people can experiment
  41 > with different syntaxes while keeping `field` for the
  42 > behind-the-scenes bits.
  43 >
  44 >> I've started using `field` on a private site and it's working
  45 >> well for me; I'll try to do some code review on its
  46 >> [[plugins/contrib/field/discussion]] page. --s
  47 >
  48 > My [[plugins/contrib/album]] plugin could benefit from
  49 > integration with `field` for photos' captions and so on,
  50 > probably... I'll try to work on that at some point.
  51 >
  52 > [[plugins/contrib/report]] may be doing too much, though:
  53 > it seems to be an variation on `\[[inline archive="yes"]]`,
  54 > with an enhanced version of sorting, a mini version of
  55 > [[todo/wikitrails]], and some other misc. I suspect it could
  56 > usefully be divided up into discrete features? One good way
  57 > to do that might be to shuffle bits of its functionality into
  58 > the IkiWiki distribution and/or separate plugins, until there's
  59 > nothing left in `report` itself and it can just go away.
  60 >
  61 > --[[smcv]]