Data-driven pages

For repeatable reference pages, use the data-driven pattern: put structured facts in data/, write one layout or shortcode that knows how to render them, and keep the Markdown page focused on context.

data/
├── contact.yml
├── publications.yml
└── talks.yml

That keeps the site easier to maintain. The data file can be sorted, reviewed, generated, or partially refreshed by a script. The layout can improve the visual presentation without touching every item. The Markdown content can explain why the page exists without becoming a giant hand-maintained table.

Boundary#

The useful boundary is simple:

• Data files hold stable facts and curated fields.
• Layouts and shortcodes hold presentation rules.
• Scripts update only fields that have a trustworthy upstream source.
• Markdown pages own title, description, date, related links, and surrounding editorial context.

Display values#

Keep source data as data. When a value needs display formatting, use the smallest shared formatter that owns the rule: a shortcode, partial or template helper. Do not hard-code a rendered count, date, label or other derived display value in Markdown.

For example, content-count calculates and formats a Hugo or data-file count at render time. The Markdown page states what to count; the shortcode owns the display format.

Use this pattern when the page itself is the artifact. A glossary page, publication list, changelog, token category table, or reference table can be data-driven without needing a separate URL for every item.

Current inventory#

Some datasets carry update rules of their own: emoji data is refreshed only from trusted upstream files, each link page pairs with a dicai.re short URL, and the blogroll includes a snapshot of the GitHub following list.

Data files must stay readable by hand. If the generated output becomes impossible to review, the automation is helping the machine more than the site.