Self-organising documents

The flagship idea behind Wit: model your structure as data, once, then render many synchronized views from it. A table of contents, a figure list, and a summary can all read the same collection — so reordering one record re-renders every view, and nothing drifts out of sync.

The pattern

Declare the structure as a collection of records, then iterate it into whatever shape a given view needs. Here one #chapters collection drives a table of contents:

#chapters: [
  { number - I, title - The Lamp },
  { number - II, title - The Watch }
]

#tocrow ||number, title||
@li ::number::. ::title:: li@
tocrow#

@ul
(each @chapters as ch) @tocrow |number @ch.number| |title @ch.title| tocrow@ (end)
ul@

That renders a real list — I. The Lamp, II. The Watch. Add a chapter or reorder the collection and the list follows.

The techniques it stands on

Everything here is a construct you already know, combined:

• Data as the source of truth — a #chapters: [ … ] collection (see Data).
• Iteration — (each … as …) over it (see Iteration).
• Definitions with captures — a row template filled per item (see Defining nodes).
• Additive partials — for structure that grows across files (see Additive partials).

Note the two ways data reaches a template: inside a loop, read a field with data access — @ch.title — and to feed a definition's capture, pass it by pipes — @tocrow |title @ch.title| — then read it as ::title:: inside the template.

What needs a renderer or a script

Automatic numbering and back-references — "Figure 3", "as shown above" — are not core language features. Supply the numbers in the data, or compute them in a <% %> script (see Derived content). A custom node type like a numbered figure box is a renderer extension, not core behaviour.

Common mistakes

• Writing ::loopvar.field:: in prose — use data access @loopvar.field; the ::…:: hole lives only in a definition body.
• Assuming a custom @node(type figure) has built-in behaviour — that is a renderer concern, not the core language.

See also

· Data · Additive partials · Multi-file references · Glossary & cross-references · Derived content