Sur un champ j’ai renseigné un type de validation avec une expression régulière.
Dans mon formulaire de modification, à l’enregistrement si la valeur de mon champ ne respecte pas le format, je vois brièvement le message s’afficher puis le formulaire s’enregistre quand même.
Je pensais que renseigner un type de validation bloquerai l’enregistrement de mon formulaire hors ce n’est pas le cas.
Un expression invalide est bien bloquante.
Votre cas tel que décrit est non reproduit sur les champs ayant des expressions, le message ERR_REGEXP est bien bloquant sur le champ. Essayez de modifier le login d’un par exemple, ou sur d’autres champs contraints de simplicité, vous devriez avoir ça :
Les toasts sont des messages d’information non bloquants pour l’utilisateur (comme “enregistrement ok” pour éviter un click), je ne vois pas le rapport avec votre regexp, que contient le toast ?
quelle est votre expression ? avez vous vérifié sa syntaxe ? y a-t-il un trace dans les logs front/back ?
avez-vous du code dans les hooks (pre/postValidate save update…) ? etc.
ayant le même cas, je me permet d’intervenir.
J’ai un champ de type “Entier” avec la regex de validation suivante : ^[0-9]$|^[0-9][0-9]$|100 (il s’agit d’un pourcentage).
Lorsque je renseigne -1, un message d’erreur s’affiche (il reste présent).
Je clique sur le bouton “Sauvegarder”. Le formulaire est sauvegardé, la page se recharge. La valeur -1 est toujours présente et le message d’erreur n’est plus affiché (ce qui est normal car il s’affiche à la saisie).
Résultat : j’ai un formulaire incorrect.
Informations sur le produit :
[Platform]
Status=OK
Version=4.0.P23
BuiltOn=2019-10-16 15:49 (revision c593f0a150e20cf2852acf4105f7e5272bb9ed26)
Bonjour,
De ce que j’ai compris de la réponse de François c’est que ce type de message d’erreur est plus une aide à la saisie (affiché quand la saisie est incorrecte) mais cela ne remplace pas le contrôle notamment dans le pre/postvalidate pour bloquer l’enregistrement.
A voir si j’ai bien compris.
La regexp est évaluée sur le front et dans le validate de Simplicité.
Donc c’est un contrôle bloquant dès lors que votre expression peut s’interpréter en java.
Il n’y a rien à coder de plus dans le preValidate.
Essayez de saisir un accent dans un nom logique d’objet, vous aurez une erreur front et back.
Le champ est contraint par une expression CONFIG = ^[a-zA-Z]{1}[a-zA-Z0-9_]*$
commence forcement par une lettre, puis des lettres ou chiffres ou underscore.
Quelle est la définition complète de votre champ pourcentage ?
A mon avis ce n’est pas un champ texte, donc il n’y a pas d’expression régulière en back pour un nombre, il faut alors coder dans le preValidate que getField(“myField”).getFloat() est compris entre 0 et 100.
Bonjour
en effet, il s’agit d’un entier.
D’après vos réponses le champ “Type validation” n’est “efficace” que pour des champs texte ? Pour tous les autres types, il faudra impérativement re-développer le contrôle dans le pré-validate ou existe t-il une façon d’imposer une contrainte back sans avoir à développer du code dans le pré-validate ?
Il n’y en a pas, car ça reviendrait à écrire du code de validation sur le champ d’une manière ou d’une autre sur le “type de champ” (en javascripté rhino mais performant qu’un code java compilé).
Par contre effectivement Simplicité pourrait appliquer les REGEXP côté back même si ce n’est pas un texte. Ce n’est jamais paramétré comme ça donc le cas ne s’est jamais présenté.
Mais comme le front fait le controle (l’input est par construction du texte), ça serait plus homogène.
Je passe votre demande en feature request pour appliquer la REGEXP sur les nombres.
Merci. Autre alternative, il faudrait que le bouton “Save” se désactive si une erreur est détectée sur le formulaire. Cela évite à l’utilisateur de pouvoir sauver un formulaire qui est déjà détecté comme incorrect.
