Cinq widgets à ajouter dans un document Grist (vue « widget personnalisé ») pour construire et gérer un formulaire d’enquête.
Crée et modifie le formulaire avec l’éditeur visuel SurveyJS, puis vérifie et répare la correspondance avec la table de réponses Grist. Le cadre liste les modifications qui seront appliquées (colonnes à créer, types à changer) et le bouton qui les applique est juste en dessous.
Importer depuis un lien recopie le questionnaire d’un autre formulaire, même dans un autre document. Collez l’URL publique du formulaire source — celle que donne son widget « Lien formulaire public », de la forme https://serveur/instance/document/numéro — et non le lien du document Grist. Ni les réponses ni les colonnes ne sont copiées : les colonnes restent à créer ensuite.
Génère l’URL publique du formulaire à partir de la table de réponses : un lien pré-rempli pour la ligne sélectionnée (paramètre ?cle=), ou un lien « nouvelle réponse ». À copier et envoyer aux répondants.
Affiche la réponse sélectionnée en lecture seule, mise en forme comme le formulaire (pièces jointes comprises). Pour relire ou contrôler une réponse sans risque de la modifier.
Comme le widget « Lien public », il suit la ligne que vous cliquez seulement si « SÉLECTIONNER PAR » est réglé sur la table des réponses, dans « Données sources » (panneau de droite). Sans ce réglage, Grist ne lui transmet aucune ligne.
Publie une table en JSON via un lien public, en ne diffusant que les colonnes choisies. Pour la réutilisation externe des résultats (open data). Une même table peut porter plusieurs flux, chacun avec ses colonnes et ses métadonnées.
Rapatrie un flux open data (créé à l’étape 4, éventuellement dans un autre document) vers la table liée, dans un seul sens. Vérifie au chargement si la table est à jour ; sinon affiche les différences et propose une mise à jour. Les lignes ajoutées à la main sont préservées.
Ce widget n’efface jamais rien. Une ligne qui quitte le flux est conservée : sa case « Dans le flux » est simplement décochée. Vous voyez donc ce qui appartient encore au flux et ce qui en est sorti, et vous décidez quoi en faire. Supprimer d’un coup reste possible à la main : filtrez sur cette case, sélectionnez, supprimez. L’inverse ne le serait pas — et effacer casserait au passage les références des autres tables vers ces lignes. Si une ligne revient plus tard, elle est simplement recochée, sans changer d’identifiant.
Deux types de questions sont disponibles dans la boîte à outils de l’éditeur, en plus des types SurveyJS habituels. Ils fonctionnent comme une liste déroulante, mais les propositions viennent d’une base de référence pendant la frappe (à partir de 3 caractères).
…_identifiant_national reçoit son identifiant stable. Les propositions affichent « nom · commune · structure gestionnaire » pour distinguer les homonymes, fréquents.Sur ces deux champs, vous pouvez cocher « Autre » dans les propriétés de la question : le répondant peut alors saisir librement une adresse ou un lieu absent de la base. Sa saisie va dans une colonne …_autre.
Le nom d’une question devient le nom d’une colonne. Deux règles :
_autre est réservé. Il sert aux saisies libres de l’option « Autre ». N’appelez donc pas une question type_autre si une question type existe : les deux viseraient la même colonne et une réponse serait perdue. L’éditeur vous prévient si le cas se présente.…_ville, …_insee, …_identifiant_national…) : ne créez pas de question portant ces noms.Vous pouvez regrouper des questions dans un panneau : chaque question du panneau a sa propre colonne, le panneau lui-même n’en crée pas.
Une table de réponses peut porter plusieurs formulaires. Le bouton « + Nouveau formulaire » de l’éditeur en crée un de plus (il ne remplace jamais l’existant) ; un sélecteur apparaît alors pour passer de l’un à l’autre. Le Visualiseur et le widget « Lien formulaire public » ont le même sélecteur.
Chaque formulaire a son numéro (affiché « Formulaire #2 ») et donc sa propre URL publique : pensez à copier le lien du bon formulaire.
Un seul réglage, dans l’éditeur (« Configuration & actions »). Il répond à deux questions à la fois : comment le répondant est reconnu, et ce qu’il a le droit de faire — créer une ligne, en modifier une, ou les deux.
UUID. C’est elle que le serveur compare pour savoir quelle réponse pré-remplir et
quelle ligne mettre à jour. Elle se choisit dans l’éditeur, dans une liste des colonnes de la
table : l’éditeur vérifie au passage qu’elle identifie bien chaque réponse, c’est-à-dire
sans doublon ni case vide — sinon le formulaire ouvrirait la mauvaise ligne,
ou aucune.
?cle=) ; il ne rouvre jamais une ligne
existante. Présenter la clé d’une réponse déjà là ne l’ouvre pas.Clé ou lien signé ? Avec une clé, qui a le lien a la
ligne : à réserver aux clés non devinables, et à ne jamais publier. Avec un lien
signé, l’identifiant n’est plus un secret — il est infalsifiable parce que signé — ce qui
permet de publier cette colonne en open data. Un lien ?cle= est alors refusé par le
serveur, et le widget « Lien formulaire public » n’en propose pas.
Si vous choisissez un mode « avec clé » alors qu’un flux open data publie justement la colonne clé, l’éditeur vous avertit : les identifiants seraient lisibles dans le jeu de données, et chacun pourrait ouvrir la réponse de n’importe qui.
Cela dépend du mode, et la différence est voulue :
Si des colonnes manquent dans la table, le formulaire est bloqué et affiche les colonnes à créer, plutôt que de perdre des réponses. Le bouton « Créer / compléter la table » de l’éditeur les ajoute.
Comme pour les formulaires, une table peut porter plusieurs flux open data. Le bouton « + Nouveau flux » en crée un de plus ; un sélecteur apparaît alors pour passer de l’un à l’autre. Chaque flux a son numéro, donc son propre lien public, ses colonnes, ses métadonnées et sa case « actif ».
Utile pour diffuser deux extraits différents des mêmes données : par exemple un annuaire grand public réduit à quelques colonnes, et un extrait complet destiné à un partenaire.
$region == "La Réunion" : Grist la recalcule tout seul quand la donnée change, et
vous voyez dans votre table exactement ce qui est publié. Le widget affiche en permanence
« N ligne(s) publiée(s) sur M » — le chiffre à regarder avant de diffuser.
La colonne qui identifie une réponse n’est retirée d’office du flux
que lorsqu’elle sert de laissez-passer, c’est-à-dire avec un
lien à clé : là, la publier permettrait à n’importe qui d’ouvrir et de modifier
toutes les réponses. Une case permet malgré tout de l’autoriser, et l’éditeur du formulaire
signale la contradiction.
Avec un lien signé ou un formulaire public, c’est l’inverse :
le serveur refuse (ou ignore) toute clé passée dans l’URL, l’identifiant n’ouvre donc rien. Il est
publié comme n’importe quelle autre colonne — et c’est souhaitable, car c’est lui qui permet de
rapprocher votre jeu de données d’autres sources. Sans identifiant stable, un jeu
open data ne se joint à rien.
La section « Métadonnées du jeu de données » du widget reprend les métadonnées de
data.gouv.fr. Elles sont publiées à part, sur le lien du flux suivi de
/metadata, et servent à ceux qui réutilisent les données.
Licence, fréquence et granularité sont enregistrées avec les identifiants de
data.gouv.fr (lov2, annual, fr:commune…) : le flux
reste directement réutilisable par une plateforme open data. Dans le widget, vous ne voyez que les
libellés en français.