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.ymlCela 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#
| Page | Données | Layout ou moteur de rendu | Mise à jour |
|---|---|---|---|
| Emojis | data/series/ref/emojis.yml | layouts/references/emojis.html | npm run emoji |
| Blogroll | data/blogroll.yml, data/github-following.yml | layouts/blog/blogroll.html | npm run blogroll |
| Liens | data/links.yml | layouts/links/list.html, layouts/links/single.html | npm run links, npm run links:import-stars |
| Livres | data/books.yml | layouts/books/list.html, layouts/books/single.html, layouts/books/shelf.html | npm run books, npm run books:enrich |
| Projets | data/projects.yml | layouts/resources/projects.html | Manuel |
| Publications | data/publications.yml | layouts/publications/publications.html | Manuel |
| OPML | data/rss.opml.xml | layouts/blog/opml.html | Export manuel |
| Glossaire principal | data/series/ref/glossary.yml | layouts/references/glossary.html | Manuel |
| Glossaire de marque | data/brand/glossary.yml | layouts/shortcodes/glossary-table.html | Manuel |
| Citations | data/series/ref/quotes.yml | layouts/references/quotes.html | Manuel |
| Codes de pays | data/series/ref/country-codes.yml | layouts/references/country-codes.html | Manuel |
| Changelog du système de marque | data/brand/changelog.yml | layouts/shortcodes/brand-changelog.html | Manuel |
| Catégories de jetons | data/brand/tokens.yml | layouts/shortcodes/token-table.html | npm 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.