Validation des données du champ personnalisé
Dernière modification : samedi 13 mars 2010
S’applique à : SharePoint Foundation 2010
Votre classe de champ personnalisé peut contenir la validation des données. Chaque type de champ personnalisé peut hériter la validation de sa classe de champ parent, substituer la validation de son parent ou même appeler la validation de son parent dans le cadre de sa propre logique de validation. Vous spécifiez la validation personnalisée des données et effectuez une mise à jour préalable de la logique de traitement pour votre classe de champ personnalisé dans la méthode GetValidatedString. (L’implémentation par défaut appelle simplement la méthode ToString de la classe de valeur ; pour cette raison, si votre classe de champ hérite directement de SPField, ou d’une classe dérivée qui ne substitue pas elle-même la méthode GetValidatedString, vous devez substituer GetValidatedString pour fournir la logique de validation, si elle est nécessaire.)
Exécution de la validation des données
Bien que vous puissiez effectuer la validation des données à plusieurs endroits de votre code, y compris dans les contrôles de formulaire, il est fortement recommandé d’ajouter toute logique de validation de données côté serveur nécessaire à la méthode GetValidatedString de votre classe de champ personnalisé. Cela permet de garantir que la validation des données nécessaire est appliquée à la fois aux données dans votre champ et aux données de la base de données de contenu.
Dans les cas où les données sont mises à jour via l’un ou l’autre des moyens suivants :
à l’aide d’un contrôle de formulaire
par le biais de l’interface utilisateur, ou
par programme par le biais du modèle objet,
SharePoint Foundation appelle la méthode GetValidatedString chaque fois que des données sont stockées dans un SPField ou une classe dérivée. Par exemple, SharePoint Foundation appelle la méthode GetValidatedString lorsqu’une valeur de champ dans un objet SPListItem est définie à l’aide de la méthode SPListItem.this["field name"].
Notes
Les utilisateurs peuvent mettre à jour les données dans un champ de différentes manières qui n’appellent pas la méthode GetValidatedString et, par conséquent, n’appellent pas la logique de validation de données contenue dans la méthode. Cela inclut l’utilisation de code non managé ou de méthodes de service Web qui n’appellent pas l’objet SPListItem pour mettre à jour les données de champ. Par exemple, lorsqu’un utilisateur met à jour les données de l’élément de liste en mode Feuille de données, les éléments de liste sont mis à jour sans que la méthode GetValidatedString soit appelée.
En outre, vous pouvez utiliser la méthode GetValidatedString pour retourner les messages d’erreur de chaîne à l’application ou au formulaire appelant, ce qui vous permet de proposer un affichage correct et une gestion appropriée des erreurs de validation de données pour votre classe de champ.
Pour retourner un message d’erreur, la méthode GetValidatedString doit lever une exception SPFieldValidationException en tant qu’erreur. Vous pouvez fournir le message d’erreur approprié en tant que paramètres de chaîne au constructeur SPFieldValidationException. Dans SharePoint Foundation, si l’utilisateur entre une valeur non valide et clique sur OK dans le formulaire, le texte du message apparaît en rouge en regard du champ dans les formulaires Création et Édition (élément de liste) standard.
L’exemple suivant montre une version substituée de GetValidatedString qui vérifie que le champ contient une valeur lorsqu’il est un champ obligatoire et que la version de chaîne de la valeur ne dépasse pas une limite spécifiée. (La propriété Required enregistre si le champ est obligatoire ou non.)
public override String GetValidatedString(Object value)
{
if ((this.Required == true) && (value.ToString() == ""))
{
throw new SPFieldValidationException(this.Title
+ " must have a value.");
}
else if (value.ToString().Length > MAXLENGTH)
{
throw new SPFieldValidationException(this.Title
+ " cannot be longer than " + MAXLENGTH.ToString());
}
return base.GetValidatedString(value);
}
Public Overrides Function GetValidatedString(ByVal value As Object) As String
If (Me.Required = True) AndAlso (value.ToString() = "") Then
Throw New SPFieldValidationException(Me.Title & " must have a value.")
ElseIf value.ToString().Length > MAXLENGTH Then
Throw New SPFieldValidationException(Me.Title & " cannot be longer than " & MAXLENGTH.ToString())
End If
Return MyBase.GetValidatedString(value)
End Function
Validation dans l’interface utilisateur
Si les utilisateurs peuvent définir la valeur du champ dans une interface utilisateur autre que les formulaires Création ou Édition (élément de liste) standard, vous devez alors valider également les données que les utilisateurs entrent dans le contrôle d’interface utilisateur du champ. Nous vous recommandons en particulier, dans le cas où le champ doit obligatoirement contenir une valeur, que cette exigence soit appliquée au niveau de l’interface utilisateur. Si vous utilisez l’une des classes SharePoint Foundation intégrées qui dérivent de BaseFieldControl pour restituer votre champ, vous pouvez alors compter sur sa validation interne pour mettre en œuvre Required. Si vous dérivez votre propre contrôle de BaseFieldControl ou de l’une de ses dérivations et que vous substituez la méthode Validate ou CreateChildControls, vous devrez assurer la mise en œuvre de Required ainsi que de toute autre validation au niveau de l’interface utilisateur que vous voulez.
Votre logique de validation d’interface utilisateur peut se trouver soit dans la méthode Validate soit dans la méthode CreateChildControls ou dans une combinaison des deux. L’une des faiblesses du placement de la logique de validation dans la méthode CreateChildControls est que la méthode n’est appelée que lorsque le champ est restitué sur un formulaire, de sorte que la validation ne se produit pas si vous mettez à jour la valeur dans le modèle objet.
Une substitution de la méthode Validate doit transmettre son résultat en définissant la propriété IsValid à l’aide de la valeur true ou false et, dans ce dernier cas, en définissant ErrorMessage sur un message approprié.
Voici un exemple de substitution de la méthode Validate . Elle vérifie d’abord si le mode de contrôle actuel est Display, auquel cas il importe peu que le champ ne soit pas valide puisqu’il ne pourra pas être modifié. La méthode vérifie également si la non-validité de la propriété Value est déjà connue en vérifiant la propriété IsValid. Si l’une ou l’autre de ces vérifications s’avère vraie, elle ne fait rien. Si aucune de ces vérifications ne s’avère vraie, la méthode appelle la méthode Validate de base qui définira IsValid comme false si elle trouve quoi que ce soit d’erroné avec la propriété Value et définit un ErrorMessage approprié. (La méthode BaseFieldControl.Validate ne fait rien, de sorte que si la classe dont la méthode Validate est en cours de substitution est dérivée directement de BaseFieldControl, l’appel à la méthode Validate de base peut être omise.) Enfin, la méthode vérifie la valeur de Required et applique cette valeur.
public override void Validate()
{
if (ControlMode == SPControlMode.Display || !IsValid)
{
return;
}
base.Validate();
if (Field.Required &&
(Value == null || Value.ToString().Length == 0))
{
this.ErrorMessage = Field.Title + " must have a value."
IsValid = false;
return;
}
}
Public Overrides Sub Validate()
If ControlMode = SPControlMode.Display OrElse (Not IsValid) Then
Return
End If
MyBase.Validate()
If Field.Required AndAlso (Value Is Nothing OrElse Value.ToString().Length = 0) Then
Me.ErrorMessage = Field.Title & " must have a value."
IsValid = False
Return
End If
End Sub
Notes
Utilisez la méthode RenderValidationMessage pour rendre le ErrorMessage.
Voir aussi
Tâches
Procédure pas à pas : création d'un type de champ personnalisé