La validation se réparti en trois parties principales :
Contient « ValidationFunctions » dans la « PartTypeInstance » « FormProPart ».
Ici sont définies les fonctions de validation qui seront affichées lors de la création des champs.
La balise XML « ValidationFunction » va contenir comme enfants les « ValidationFunction » dont voici un exemple :
<ValidationFunction ID="custom[dob]" Title="Date de naissance"
ErrorMessage="FormBuilder.Validator.FVValidationFunction.DOB"
FieldTypes="Date" />Nous voyons que cette balise contient quatre attributs :
- ID : Nom de la règle de validation.
Veillez à respecter la convention de nommage « custom[nomdelavalidation] » afin que le validation engine puisse récupérer la règle JS associée (voir la partie Javascript) ; - Title : Nom affiché dans le back-office pour désigner la validation ;
- ErrorMessage : Message d’erreur affiché lors de la validation C#.
Veillez à respecter la convention de nommage : « FormBuilder.Validator.FVValidationFunction.[nom dans custom de l’ID] ».
L’utilisation « {0} » permettra d’ajouter le titre du champ dans le message ; - FieldTypes : Attribut facultatif permettant de définir pour quels types de champ la validation peut être ajoutée.
L’attribut « FieldTypes » ne change pas le comportement par défaut, si l'attribut n'est pas ajouté, la validation est disponible pour tous les types de champs. Il est également à noter que si un type de champ n'existant pas est inscrit, aucune erreur n'est lancée. Le nom du type de champ n'est pas sensible à la case.
La classe « FieldValidator » contient la logique métier vérifiant les champs (le javascript n’étant pas une solution de validation viable).
Le constructeur statique est utilisé afin d’initialiser la liste des validateurs. Ceux-ci se voient directement attribuer un certain type de champ.
Si la validation est faite uniquement avec un REGEX, il n’est pas nécessaire d’ajouter quoi que ce soit au code C#.
Dans le cas contraire, la classe « FVAge » est un bon exemple concret de création d’une validation plus complexe. Ce type de validation n’est faite qu’en C# néanmoins il est toujours nécessaire d’ajouter un règle Javascript vide afin que la validation fonctionne.
Les validateurs héritent de plusieurs méthodes leur permettant d’effectuer la validation, de retourner un message d’erreur ou de retourner une classe CSS qui sera interprétée par le validation engine :
public override bool Validate(FormBuilderForm f, FormBuilderField field, FieldResponse value, FormProcessingContext ctx)
Cette méthode est la seule à devoir être surchargée. Elle contient la logique qui va permettre de définir si oui ou non le champ est valide.
public override string FormatMessage(FormBuilderField field, FormProcessingContext ctx)
Cette méthode n’est pas obligatoirement à surcharger, l’implémentation de base permet de retourner un message d’erreur unique, lié à un terme de traduction IC2 sous la forme « FormBuilder.Validator.[NomDeClasseValidateur] ».
public override string GetJSRule(FormBuilderField field)
Dans le cas où une validation javascript est nécessaire, il est possible de retourner un nom de classe pour le validator engine. Le nom ainsi retourné sera inclus dans les crochets de la classe « validate[…] ». Veillez à ne pas oublier de définir la règle du validator engine dans les fichiers nécessaires (voir Javascript – jQuery validation engine). Par défaut cette méthode retourne une chaîne de caractères vide.
La validation au niveau client se fait en javascript à l’aide du plugin jQuery « Inline Form Validation Engine 2.6.2 ».
Les règles sont définies dans les fichiers javascript « Scripts/javascript/lang/XX.js ». Cela permet de définir un message d’erreur propre à la langue utilisée sur le site.
Lors de l’ajout de règles dans Layout.config, veillez à ajouter la règle correspondante dans chaque fichier de langue. Le nom de la règle est dans le texte défini dans l’ID de Layout.config. Reprenons l’exemple précédent dont l’ID est « custom[dob] », le nom de la règle est « dob ».
Attention à ne pas mettre des guillemets autour de la REGEX