Comprendre les Forms
Un Form est un artefact marchand réutilisable qui décrit un schéma de collecte connu à la conception. Il possède une identité stable, des révisions immuables et des Releases indépendantes des processus qui l’utilisent.
Définition et schéma
La définition form porte l’identité durable du formulaire : identifiant frm_…, clé, nom, description, marchand et état d’activation. Le contenu exécutable est le schéma de sa révision Working : une liste ordonnée de champs. Chaque champ sépare son contrat de donnée value_type de son contrôle d’interface control, puis porte ses contraintes et sa politique de protection.
Le Form conserve une identité stable ; son Working évolue, une Release publie un snapshot et un processus sauvegardé pinne une révision exacte.
custom_form est l’action utilisateur qui présente ce schéma dans un processus et attend la réponse du participant.Champs et protection
Les types de champs supportés par le contrat courant sont :
text, textarea, email, phone, password, url, integer, number, rate, country, currency, amount, address, select, radio, checkbox, date, datetime, file
Les champs de choix portent leurs options, les champs fichier déclarent un purpose autorisé pour l’upload et les contraintes disponibles dépendent du type : longueurs, bornes numériques, pattern sûr ou nombre de fichiers. Les contrôles sémantiques produisent directement les valeurs Ormuz attendues : amount produit un common.amount en minor units avec une devise explicite, address produit un seul common.address, et les contrôles country, currency, url ou rate conservent leur subtype canonique. Les clés de champs sont uniques dans un schéma.
Un champ peut aussi déclarer une classe de protection : normal, sensitive, secret. Cette classification suit ensuite la valeur collectée dans le processus ; elle n’est pas un simple attribut visuel du Form Studio.
Working, révisions et Releases
Modifier le schéma crée une nouvelle Form revision immuable et déplace leworking_revision_id de la définition. Les écritures de schéma utilisent la révision et lecontent_hash attendus afin de refuser une sauvegarde basée sur un Working devenu obsolète.
Une Form Release publie une révision précise. Le statut active de la définition reste une dimension séparée : il ne remplace ni Working, ni révision, ni Release.
Lorsqu’un processus utilise un Form, son snapshot conserve la révision exacte du Form et son content hash. Une évolution ultérieure du Working du Form ne modifie donc pas rétroactivement les snapshots de processus déjà enregistrés. Voir Utiliser un Form dans un processus.
Form ou formulaire dynamique ?
| Besoin | Contrat | À utiliser |
|---|---|---|
| Réutiliser un schéma nommé, édité et versionné indépendamment du processus | Ressource form + révision fdr_… | custom_form |
| Construire les questions pendant l’exécution | common.form_spec produit au runtime, sans ressource Form persistante | dynamic_form |
Un formulaire dynamique est figé dans l’action utilisateur qui le présente, mais il ne devient pas un Form réutilisable. Utilisez un Form lorsque l’identité, l’édition indépendante et le versionnement du schéma font partie du besoin produit.