]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blob - doc/todo/internal_definition_list_support.mdwn
fix picked
[git.ikiwiki.info.git] / doc / todo / internal_definition_list_support.mdwn
1 While ikiwiki can support definition lists (`dl/dt/dd`) through [[multimarkdown|mdwn]], it doesn't actually /do/ anything with those valuable definitions. It would be interesting for third party plugins to have access to this stuff as a proper data structure. This is what allows MoinMoin to have plugins that collect that data across multiple pages and tabulate it, for example.
3 What I am proposing here is that the [[variables exported to plugins|plugins/write/#index6h2]] be extended to include a `%dictionnaries` hash. For a markup like this:
5 [[!format txt """
6 Apple
7 : Apple is a fruit
8 : It's also a computer company
9 Orange
10 : Orange is a fruit
11 """]]
13 would result in a data structure like this:
15 [[!format txt """
16 %dicts = {
17   'Apple' => [ "Apple is a fruit", "It's also a computer company" ],
18   'Orange' => [ "Orange is a fruit" ],
19 }
20 """]]
22 Now, I know I can write myself a `format()` parser that would do this on all pages in my own plugin, but then it would need to be adapted to all markups, while markup formatters should be the ones implementing this directly, if possible.
24 My first use case for this would be to extend the [[plugins/contrib/osm]] plugin to tap into those lists, so that I could have this data in the page, visible to the user:
26 [[!format txt """
27 Longitude
28 : -45.30
29 Latitude
30 : 73.67
31 """]]
33 and then reuse that data in the plugin.
35 Then for us running the humongous [[koumbit wiki|https://wiki.koumbit.net/]], it is a necessary step to be able to migrate away from MoinMoin to Ikiwiki as we have a lot of pages that tabulate information like this. For example, see our [[ServerList|https://wiki.koumbit.net/ServerList]] ([[source|https://wiki.koumbit.net/ServerList?action=raw]]), being generated from pages like [[this one|https://wiki.koumbit.net/metis.koumbit.net]].
37 If there are no objections to that concept, I may try to start coding patches. Otherwise this is really just a [[wishlist]].
39 > Have you looked at the [[plugins/contrib/field]] plugin? This gives you the infrastructure, and all you need is to write a plugin that parses the definition list format.  Then you could use [[plugins/contrib/getfield]], [[plugins/contrib/ftemplate]] and/or [[plugins/contrib/report]] to do what you like with the data.
40 > --[[KathrynAndersen]]