Création de formulaires

[Isaytoo]

Je vous propose un widget qui permet de créer des formulaires personnalisables à volonté.
Grist ne propose pas de créer des sélecteurs en cascade.
J’ai donc rajouté cela dans Form Builder Pro.
Vous pouvez tester librement ici : Form Builder Pro - Grist

Le dépôt Github : GitHub - isaytoo/grist-form-builder-widget · GitHub

Guide d’utilisation

Apprenez à créer et partager des formulaires professionnels avec Form Builder Pro.

Présentation

Form Builder Pro permet de créer des formulaires professionnels sur page A4 avec drag & drop, puis de les partager avec vos utilisateurs. Les données sont enregistrées directement dans vos tables Grist.

Créer un formulaire

1. Sélectionnez la table source dans le menu déroulant
2. Glissez les champs de la table ou les éléments sur la page A4
3. Positionnez et redimensionnez les champs avec la souris
4. Cliquez sur un champ pour configurer ses propriétés
5. Cliquez sur Sauvegarder pour enregistrer

Partager le formulaire

1. Sauvegardez votre formulaire
2. Cliquez sur Partager
3. Copiez l’URL affichée dans la modale
4. Dans Grist, ajoutez un nouveau widget personnalisé
5. Collez l’URL et accordez l’accès complet

Astuce : Les utilisateurs ne verront que le mode saisie, sans accès à l’édition.

Plusieurs formulaires

Chaque formulaire est lié à une table. L’URL de partage contient le paramètre table=NomTable.

Exemple : ...?mode=form&table=Clients

Sélecteurs en cascade (options dynamiques)

Les champs Liste déroulante, Choix unique et Cases à cocher peuvent charger leurs options depuis une table Grist, et les filtrer en cascade selon la valeur d’un autre champ du formulaire (ex. choisir un département → ne voir que les villes de ce département).

Étape 1 — Préparer la table source dans Grist

Crée une table contenant tes options. Exemple Villes :

nom · code_dept
Lyon · 69
Bron · 69
Grenoble · 38
Paris 1er · 75

Étape 2 — Configurer le champ « parent »

1. Glisse une Liste déroulante sur le canvas
2. Clique dessus pour ouvrir les propriétés à droite
3. Donne-lui un libellé clair : ex. « Département »
4. Section Source des options → clique Depuis Grist
5. Choisis la table source (ex. Departements), la colonne libellé (nom) et la colonne valeur (code)
6. Pas de filtre nécessaire pour ce champ — il propose toutes les valeurs

Étape 3 — Configurer le champ « enfant » (cascade)

1. Glisse une autre Liste déroulante
2. Libellé : « Ville », source Depuis Grist
3. Table source : Villes, colonne libellé : nom
4. Section Filtres en cascade → clique + Ajouter un filtre
5. Champ parent : Département · Opérateur : = · Colonne source : code_dept

Quand l’utilisateur choisira un département, le select Ville rechargera automatiquement ses options en ne gardant que celles dont code_dept correspond.

Les 4 opérateurs disponibles

= (égal à) — la colonne source vaut exactement la valeur du parent.
Ex. ville.code_dept = 69 si Département = 69

≥ (supérieur ou égal) — la colonne source est ≥ valeur du parent.
Ex. produit.prix_min ≥ budget saisi

≤ (inférieur ou égal) — la colonne source est ≤ valeur du parent.
Ex. tarif.plafond ≤ revenu déclaré

entre deux colonnes — la valeur du parent est entre deux colonnes (min/max) de la table source.
Ex. produit.age_min ≤ âge_saisi ≤ produit.age_max

Plusieurs filtres combinés (ET)

Tu peux ajouter plusieurs filtres sur un même champ. Toutes les conditions doivent être vraies pour qu’une option soit affichée.

Exemple : select « Produits » filtré par Catégorie = catégorie ET Âge entre age_min et age_max → ne propose que les produits de la bonne catégorie ET adaptés à l’âge.

Comportement à la saisie

• Si le parent n’a pas encore de valeur, son filtre est ignoré (pas de blocage)
• Quand le parent change, l’enfant recharge ses options automatiquement
• Cascade transitive (A → B → C) gérée : changer A reconfigure B, qui reconfigure C
• Si la valeur sélectionnée d’un enfant n’est plus valide, elle est réinitialisée

Exemple complet — Recommander des produits selon l’âge

Démontre l’opérateur entre deux colonnes avec un cas pratique : l’utilisateur saisit son âge et le formulaire propose uniquement les produits adaptés à sa tranche.

Table Produits dans Grist

nom · categorie · age_min · age_max · prix
Hochet musical · Bébé · 0 · 2 · 15
Tricycle · Enfant · 3 · 7 · 80
Trottinette · Enfant · 6 · 12 · 90
Skateboard · Ado · 10 · 16 · 120
Tablette · Tous · 10 · 99 · 300
Vélo VTT adulte · Adulte · 16 · 75 · 600
Carte senior SNCF · Senior · 60 · 120 · 75

Champ 1 — Âge (saisie utilisateur)

• Glisse un élément Nombre sur le canvas
• Libellé : « Quel est votre âge ? »
• Pas de source Grist nécessaire (l’utilisateur tape)

Champ 2 — Produits recommandés (cascade)

1. Glisse une Liste déroulante, libellé : « Produits recommandés »
2. Source des options → Depuis Grist
3. Table source : Produits
4. Colonne libellé : nom
5. Colonne valeur : nom (ou laisse vide)
6. Section Filtres en cascade → + Ajouter un filtre
7. Champ parent : Quel est votre âge ?
8. Opérateur : entre deux colonnes
9. Colonne minimum : age_min
10. Colonne maximum : age_max

Résultat à la saisie

• Saisir 5 → propose : Tricycle, Trottinette
• Saisir 12 → propose : Trottinette, Skateboard, Tablette
• Saisir 30 → propose : Tablette, Vélo VTT adulte
• Saisir 65 → propose : Tablette, Vélo VTT adulte, Carte senior SNCF

Pour aller plus loin : ajoute un second filtre sur ce même champ avec un autre champ parent Catégorie (sélecteur statique avec Bébé/Enfant/Ado/Adulte/Senior) et opérateur = sur la colonne categorie. Tu obtiens un filtrage croisé âge ET catégorie.

Permission requise : le widget doit avoir « Accès complet au document » pour lister les tables et lire les données. Configure-le dans le panneau du widget Grist (à droite de l’écran).

Données prêtes à l’emploi : les CSV d’exemple (Departements, Villes, Produits) sont disponibles dans le dossier /exemples/ du dépôt GitHub du widget.

Fonctionnalités

Multi-pages A4

Champs conditionnels

Sélecteurs en cascade

Champs calculés

Lookup / Autocomplétion

Signature

Validation avancée

Templates

Historique des versions

Export PDF

QR Code

Exemple de sélections en cascade :

Bon test !

[AnthonyR]

Bonjour Saïd et merci pour la mise à disposition de tous ces outils ! J’aurais une remarque générale sur ceux-ci qui concerne l’utilisation du mode sombre dans Grist : lorsqu’on passe en mode sombre, certains textes s’affichent en blanc sur fond blanc et ne sont donc pas lisibles dans les menus. Vous serait-il possible de corriger ce comportement ?

[Isaytoo]

Bonjour @AnthonyR ,

Le widget Form Builder Pro que je présente sur ce sujet n’a pas de mode sombre, du moins pas pour l’instant.
Vous parlez de quels widgets du coup car j’en ai réalisé pas mal ?

[AnthonyR]

Pour être plus précis, je ne parle pas d’un mode sombre intégré au widget mais du comportement de ce widget lorsque le mode sombre est activé dans les options de Grist. C’est à ce moment-là que certains champs s’affichent en blanc sur blanc. Souhaitez-vous que je vous envoie des captures d’écran ? J’ai repéré le problème sur ce widget de formulaire mais également sur d’autres il me semble (il faudrait que je les passe à nouveau en revue pour vous les mentionner, j’essaierai de prendre un peu de temps pour le faire mais je pense que vous devriez également pouvoir vous rendre compte des problèmes si vous activez le mode sombre dans l’instance de Grist que vous utilisez).

[Isaytoo]

oui, c’est tout à fait normal.
Quand tu définis tes propres couleurs CSS dans le widget (comme background: #0f0f10), tu écrases les variables CSS de Grist, donc le thème clair/sombre de Grist n’a plus aucun effet sur ton widget.

Pour que le thème Grist fonctionne, il faut utiliser les variables CSS natives de Grist au lieu de couleurs fixes. Grist injecte automatiquement ces variables dans le widget selon le thème choisi par l’utilisateur.

Grist ne documente pas de variables CSS officielles pour les widgets custom.
La meilleure approche est d’utiliser prefers-color-scheme , une media query CSS native du navigateur qui détecte automatiquement si l’utilisateur est en mode clair ou sombre au niveau système, ce qui coïncide généralement avec le choix Grist.

Je viens de tester sur un widget simple et ça fonctionne avec ce que je viens d’expliquer ci-dessus :

Les modifications sur les autres widgets prochainement…

[AnthonyR]

Bonjour Saïd,

Merci pour les précisions ! Je comprends donc que cette approche d’utilisation de prefer-colors-scheme (qui effectivement règlerait le problème dans la plupart des cas je pense) n’a pas encore été appliquée sur tous les widgets personnalisés que vous avez créés, et notamment pas sur le widget de formulaire faisant l’objet de ce message de forum. Peut-être qu’une autre approche serait de laisser l’utilisateur choisir d’utiliser un mode clair ou sombre au sein même de chaque widget, à condition qu’il soit possible de mémoriser ce choix pour sa session de navigation sans que cela n’affecte le comportement pour les autres utilisateurs ? Je ne sais pas si c’est possible techniquement cela dit

À tout hasard je vous montre le comportement du widget de formulaire lorsqu’il est inséré dans un document Grist en mode sombre :

Comme vous le voyez, tous les boutons ne sont pas affectés et je me disais donc qu’il serait peut-être possible de modifier les couleurs utilisées dans les boutons “invisibles” pour leur faire avoir le même comportement que les boutons “visibles” de la page.

Merci en tout cas pour vos nombreuses réalisations gristiennes !

[Isaytoo]

Bonjour @AnthonyR

Ces boutons « invisibles » sont des contrôles natifs (boutons de barre d’outils, zoom, navigation…) qui n’avaient pas de couleur de texte explicite. Quand votre navigateur/OS est en mode sombre, et faute pour le widget d’avoir déclaré son schéma de couleurs, le navigateur leur applique automatiquement un texte clair → texte blanc sur fond blanc = invisible. Les boutons « visibles » (Édition, Partager…) avaient, eux, une couleur définie, d’où la différence.

Correctif appliqué au widget de formulaire : j’ai forcé le schéma clair (color-scheme: light) sur tout le widget. Concrètement, il s’affiche désormais toujours en clair et lisible, quel que soit le mode sombre de votre navigateur , tous les boutons/menus/champs réapparaissent. C’est l’approche la plus simple et fiable pour régler ce cas immédiatement (et au passage tous les select/input qui auraient eu le même souci).

Sur vos deux suggestions :

• prefers-color-scheme (vrai thème sombre adaptatif) : c’est faisable mais plus lourd (il faut redéfinir toute une palette sombre) ; je le réserve pour une évolution ultérieure.

• un sélecteur clair/sombre mémorisé par utilisateur : oui, techniquement possible , la préférence serait stockée dans le navigateur (localStorage), donc propre à votre session et sans impact sur les autres utilisateurs. Si le besoin se confirme, je pourrai l’ajouter ; mais le passage en clair forcé résout déjà l’illisibilité signalée.

  

[AnthonyR]

J’ai pu tester et le correctif appliqué fonctionne bien de mon côté, merci beaucoup ! Dans un premier temps ce correctif peut largement suffire, et concernant l’idée du choix entre mode clair et sombre je pense que ça pourrait être un bonus appréciable mais pas une priorité (du moment que tous les boutons du widget deviennent lisibles quel que soit le thème de couleurs du navigateur, ce qui semble désormais être le cas). J’essaierai de vous signaler des problèmes similaires sur d’autres widgets que vous avez conçus si j’en viens à les tester. Bonne journée à vous !

[BorisL]

Bonjour,
J’ai un probleme avec Form Builder pro.
Un fois mon formulaire créé et sauvegardé, j’ai copié le lien affiché dans « partager » pour l’utiliser en interne.
Je crée alors un page ou une vue en donnant accés complet.
Cependant, le widget m’affiche « Aucun formulaire configuré., Veuillez contacter l’administrateur »
Auriez vous une piste pour résoudre mon pb ?
Cordialement,