Pages pilotées par les données

Pour les pages de référence répétables, utilisez le patron piloté par les données : placer les faits structurés dans data/, écrire un layout ou un shortcode qui sait les rendre, et garder la page Markdown centrée sur le contexte.

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

Cela rend le site plus facile à maintenir. Le fichier de données peut être trié, relu, généré ou partiellement rafraîchi par un script. Le layout peut améliorer la présentation visuelle sans toucher chaque item. Le contenu Markdown peut expliquer pourquoi la page existe sans devenir un énorme tableau maintenu à la main.

Frontière#

La frontière utile est simple :

  • Les fichiers de données gardent les faits stables et les champs éditoriaux.
  • Les layouts et shortcodes gardent les règles de présentation.
  • Les scripts mettent à jour seulement les champs qui ont une source amont fiable.
  • Les pages Markdown portent le titre, la description, la date, les liens connexes et le contexte éditorial.

Valeurs d’affichage#

Conservez les données sources sous forme de données. Lorsqu’une valeur a besoin d’un format d’affichage, utilisez le plus petit formateur partagé qui porte la règle : un shortcode, un partial ou une fonction de gabarit. Ne codez pas en dur dans Markdown un décompte, une date, un libellé ou toute autre valeur d’affichage dérivée.

Par exemple, content-count calcule et formate à l’exécution un décompte provenant des pages Hugo ou d’un fichier de données. La page Markdown indique quoi compter; le shortcode possède le format d’affichage.

Utilisez ce patron lorsque la page elle-même est l’artefact. Une page de glossaire, une liste de publications, un changelog, un tableau de catégories de jetons ou un tableau de référence peut être piloté par les données sans avoir besoin d’une URL distincte pour chaque item.

Inventaire actuel#

PageDonnéesLayout ou moteur de renduMise à jour
Emojisdata/series/ref/emojis.ymllayouts/references/emojis.htmlnpm run emoji
Blogrolldata/blogroll.yml, data/github-following.ymllayouts/blog/blogroll.htmlnpm run blogroll
Liensdata/links.ymllayouts/links/list.html, layouts/links/single.htmlnpm run links, npm run links:import-stars
Livresdata/books.ymllayouts/books/list.html, layouts/books/single.html, layouts/books/shelf.htmlnpm run books, npm run books:enrich
Projetsdata/projects.ymllayouts/resources/projects.htmlManuel
Publicationsdata/publications.ymllayouts/publications/publications.htmlManuel
OPMLdata/rss.opml.xmllayouts/blog/opml.htmlExport manuel
Glossaire principaldata/series/ref/glossary.ymllayouts/references/glossary.htmlManuel
Glossaire de marquedata/brand/glossary.ymllayouts/shortcodes/glossary-table.htmlManuel
Citationsdata/series/ref/quotes.ymllayouts/references/quotes.htmlManuel
Codes de paysdata/series/ref/country-codes.ymllayouts/references/country-codes.htmlManuel
Changelog du système de marquedata/brand/changelog.ymllayouts/shortcodes/brand-changelog.htmlManuel
Catégories de jetonsdata/brand/tokens.ymllayouts/shortcodes/token-table.htmlnpm run tokens:update

Certains jeux de données portent leurs propres règles de mise à jour : les données emoji ne sont rafraîchies qu’à partir de fichiers amont considérés fiables, chaque page de lien est appariée à une URL courte dicai.re, et le blogroll inclut un instantané de la liste GitHub Following.

Les fichiers de données doivent rester lisibles à la main. Si la sortie générée devient impossible à relire, l’automatisation aide davantage la machine que le site.