git.oblomov.eu Git - ikiwiki/blob - doc/todo/structured_page_data.mdwn

   1 This is an idea from [[JoshTriplett]].  --[[Joey]]
   2
   3 Some uses of ikiwiki, such as for a BTS, move a bit away from the wiki end
   4 of the spectrum, and toward storing structured data about a page or instead
   5 of a page.
   6
   7 For example, in a bug report you might want to choose a severity from a
   8 list, enter a version number, and have a bug submitter or owner recorded,
   9 etc. When editing online, it would be nice if these were separate fields on
  10 the form, rather than the data being edited in the big edit form.
  11
  12 There's a tension here between remaining a wiki with human-editable source
  13 files, containing freeform markup, and more structured data storage. I
  14 think that it would be best to include the structured data in the page,
  15 using a directive. Something like:
  16
  17         part of page content
  18         \[[data yaml="<arbitrary yaml here>"]]
  19         rest of page content
  20
  21 As long as the position of the directive is not significant, it could be
  22 stripped out when web editing, the yaml used to generate/populate form fields,
  23 and then on save, the directive regenerated and inserted at top/bottom of
  24 the page.
  25
  26 Josh thinks that yaml is probably a good choice, but the source could be a
  27 `.yaml` file that contains no directives, and just yaml. An addition
  28 complication in this scenario is, if the yaml included wiki page formatted content,
  29 ikiwiki would have to guess or be told what markup language it used.
  30
  31 Either way, the yaml on the page would encode fields and their current content.
  32 Information about data types would be encoded elsewhere, probably on a
  33 parent page (using a separate directive). That way, all child pages could
  34 be forced to have the same fields.
  35
  36 There would be some simple types like select, boolean, multiselect, string, wiki markup.
  37 Probably lists of these (ie, list of strings). Possibly more complex data
  38 structures.
  39
  40 It should also be possible for plugins to define new types, and the type
  41 definitions should include validation of entered data, and how to prompt
  42 the user for the data.
  43
  44 This seems conceptually straightforward, if possibly quite internally
  45 complex to handle the more complicated types and validation.
  46
  47 One implementation wrinkle is how to build the html form. The editpage.tmpl
  48 currently overrides the standard [[cpan CGI::FormBuilder]] generated form,
  49 which was done to make the edit page be laid out in a nice way. This,
  50 however, means that new fields cannot be easily added to it using
  51 [[cpan CGI::FormBuilder]]. The attachment plugin uses the hack of bouilding
  52 up html by hand and dumping it into the form via a template variable.
  53
  54 It would be nice if the type implementation code could just use
  55 FormBuilder, since its automatic form generation, and nice field validation
  56 model is a perfect match for structured data. But this problem with
  57 editpage.tmpl would have to be sorted out to allow that.