Introduce table schema validation plugin with Validata API

[pierrecamilleri]

This PR introduces validataion of data against a table schema via the Validata API.

Le plugin précédent est déplacé à l'url /datagouv, le plugin validata à l'url /validata. La racine présente sobrement deux boutons DataGouv et Validata pour charger l'un ou l'autre.

J'ai un peu soigné le front par rapport à la dernière démo.

Utilisation

J'ai écrit un petit guide d'utilisation "./docs/validata.md".

Comme c'était pénible et contre-intuitif de toujours devoir appuyer sur le bouton pour mettre à jour la validation, j'ai opté à nouveau pour la validation automatique (avec un délai d'une seconde redéclenché à chaque modif, qui fait office de rate limiter).

L'URL du schéma est stocké comme option, et donc conservé si on recharge le plugin. Il peut être "enregistré", ce qui fait que l'option est partagée avec toutes les personnes qui accèdent au document.

Déploiement

Je ne vois pas de procédure de déploiement dans ce repo, comment as-tu déployé la première fois ?

Détails techniques

Limitations

• Le plugin récupère les données CSV si les données sont publiques, auquel cas les données sont formattées comme dans la vue, notamment les dates. Si les données sont privées, alors le plugin se rabat sur l'api du plugin qui récupère les données brutes, à cause de ce bug. La validation des formats personnalisés (notamment des dates au format non iso) ne fonctionne alors pas.

• Un certain nombre d'exceptions ne sont pas encore élégamment interceptés, c'est par exemple le cas lorsqu'on ne donne pas assez de permissions au plugin, ou lorsque l'url donnée n'est pas valide.

• Une autre limitation est que la vue qui est validée dans le cas de l'export csv n'est pas forcément celle à côté du plugin, mais celle des données sources. Bizarrement, l'ordre des lignes est synchronisé mais pas l'ordre des colonnes. De ce fait, l'ordre des colonnes et les filtres appliqués dans la vue sont ignorés par Validata à ce stade.

Manipulation de données internes

En plus d'un mixte d'utilisation de l'API du plugin (dès que possible) et de l'API http (pour récupérer le CSV), il a fallu modifier des données internes à Grist.

La plupart des opérations nécessitent de lire et parfois d'écrire dans ces données internes. C'est le cas de tout ce qui a trait au formattage conditionnel par exemple. J'ai essayé de faire les choses proprement, mais j'ai tout de même mis un message d'avertissement dans le README, parce que ça m'est arrivé pendant le dev de littéralement casser le document Grist avec des données internes invalides.

Ces tables sont _grist_Tables (lecture seule) et _grist_Tables_column (lecture et écriture). Pour faire les choses proprement il faudrait sans doute utiliser deux autres tables que je mentionne ici pour m'en souvenir : _grist_Views et _grist_Views_sections.

Déploiement local

Pour le déploiement local, j'ai activé l'option "https" pour le serveur de dev, et j'ai dû utiliser mkcert pour contourner les attentes de firefox en matière de certificat.

[pierrecamilleri]

@geoffreyaldebert

On s'est dit ce matin (avec @Pierlou) que le plugin était en état de pouvoir être mis dans la main d'utilisateurs, malgré des limitations que j'ai listées pour l'essentiel dans la description de la PR (non triviales à corriger).

Je te laisse jeter un coup d'œil ? N'hésite pas si tu souhaites qu'on fasse un point démo.