Champs

Un formulaire est une liste ordonnée de champs, composée au glisser-déposer dans l'onglet Champs du constructeur. Les champs sont stockés en JSON avec le formulaire, il n'y a pas de table de champs.

Règle absolue : ce que valide le module côté serveur est plus étroit que ce que suggère le catalogue. Un champ number ou date n'est pas vérifié. Voir la fin de cette page avant de bâtir un traitement sur ces valeurs.

Catalogue

Les champs sont regroupés en quatre familles dans la palette.

Basique

Choix

Avancé

Mise en page

Ces deux derniers ne portent ni nom, ni obligation. Ils ne portent qu'un content, le texte rendu, et une largeur. Ils servent à structurer visuellement le formulaire et n'apparaissent ni dans les données, ni dans les courriels.

Propriétés communes

Un champ hidden n'étant pas affiché, l'inspecteur ne lui propose que son libellé, son nom et sa valeur par défaut.

Le nom d'un champ

Il est dérivé du libellé à la création : mise en minuscules, accents retirés, tout caractère hors alphanumérique remplacé par un souligné, tronqué à cinquante caractères. En cas de collision, un suffixe _2, _3 est ajouté.

Il est ensuite modifiable dans l'inspecteur, où la saisie est restreinte à [a-zA-Z0-9_] en direct.

Changer le nom d'un champ après réception de soumissions casse le lien avec les réponses existantes. Elles restent stockées sous l'ancienne clé, et n'apparaîtront plus en face du bon libellé. Renommer le libellé sans toucher au nom est sans risque.

Propriétés spécifiques

Champs à options

select, radio et checkboxes portent une liste { label, value }. Deux options sont créées par défaut.

La valeur de chaque option est assainie automatiquement à la saisie. C'est elle qui est stockée dans la soumission, pas le libellé.

checkbox

Une case unique, destinée au consentement. Son libellé vaut par défaut « J'accepte les conditions ». Marquée obligatoire, elle doit être cochée pour que le formulaire passe.

La valeur stockée est un booléen, et non la chaîne du navigateur.

file

Les familles disponibles sont DOCUMENTS, IMAGES, PDF_ONLY, ARCHIVES et ALL.

ALL lève la restriction de famille, pas les contrôles de contenu du core : le SVG reste refusé quel que soit le réglage, la signature binaire doit correspondre à l'extension déclarée quand cette extension est connue, et le contenu est inspecté à la recherche de balises exécutables. La taille maximale du champ s'applique toujours.

Le point de soumission traite tous les fichiers envoyés sous le nom du champ, chacun validé et téléversé séparément. Les deux composants livrés ne posent cependant ni multiple ni accept sur leur champ de fichier : avec eux, c'est un fichier par champ, sans filtrage à la sélection. Le pluriel demande une intégration maison. Voir Soumissions.

hidden

Porte une defaultValue, envoyée telle quelle si le formulaire ne la remplace pas. Sert à marquer l'origine d'une soumission, par exemple la campagne ou la page d'où elle provient.

Sa valeur n'est jamais validée et n'apparaît pas dans les courriels. Ne rien y mettre de sensible : elle est visible dans le code source de la page et modifiable par le visiteur.

Validation appliquée côté serveur

C'est la partie à lire avant de bâtir un traitement automatisé sur les réponses.

Ce qui n'est pas validé

• number n'est ni converti en nombre, ni borné. Une saisie non numérique est stockée telle quelle.
• date n'est pas vérifié comme date.
• tel n'est pas vérifié du tout.
• email n'est vérifié que par la présence d'un @. Ni format complet, ni domaine.
• Les valeurs de select, radio et checkboxes ne sont pas comparées aux options déclarées. Une requête forgée peut donc stocker une valeur qui n'a jamais été proposée.
• Aucune longueur maximale n'est imposée sur les champs texte.

Le navigateur ne valide rien non plus

Les champs portent bien leur type HTML et leur attribut required, mais les deux composants de rendu posent noValidate sur le formulaire. La validation native du navigateur ne s'exécute donc jamais, ni sur les champs obligatoires, ni sur le format d'un courriel.

Le serveur est le seul validateur, et sa réponse d'erreur est générique côté visiteur : « Veuillez corriger les champs en erreur », sans indication du champ fautif. Le détail par champ existe dans la réponse, il n'est simplement pas affiché. Voir Affichage.

Un formulaire qui demande un retour immédiat au visiteur passe par une intégration maison, qui retire noValidate ou exploite l'objet fieldErrors.

Conséquence pratique : traiter les valeurs reçues comme des chaînes non fiables. Convertir et valider dans le traitement en aval, pas dans le formulaire.

Notes

• Les champs sont stockés en JSON dans le formulaire. Il n'existe aucun schéma de base pour eux, et donc aucune contrainte d'intégrité.
• Le type checkbox porte une propriété consentText créée à l'ajout du champ. Elle n'est ni modifiable dans le constructeur, ni rendue nulle part. Ne pas compter dessus.
• L'ordre des champs dans le constructeur est l'ordre de rendu, l'ordre du tableau récapitulatif des courriels, et l'ordre de la fiche de soumission.