Partager via


Mettre en œuvre la logique métier et la validation de données dans une application Windows Phone pour SharePoint

Implémenter la validation des données dans une application Windows Phone créée à l'aide du modèle d'application de liste SharePoint Windows Phone.

Dans une application Windows Phone destinée à être production utiliser, vous devrez probablement valider des données entrées par les utilisateurs pour, par exemple, appliquer la logique métier appropriée à votre situation particulière, ou pour vérifier la mise en forme appropriée de valeurs entrées ou simplement pour intercepter des erreurs avant d'enregistrer des valeurs dans une liste SharePoint. Projets basés sur le modèle d'Application de liste SharePoint Windows Phone incluent la logique de validation de données par défaut, mais ces projets fournissent également un mécanisme permettant aux développeurs d'implémenter une validation de données personnalisée.

Importante

Si vous développez une application pour Windows Phone 8, vous devez utiliser Visual Studio Express 2012 au lieu de Visual Studio 2010 Express. À l’exception de l’environnement de développement, toutes les informations contenues dans cet article s’appliquent à la création d’applications pour Windows Phone 8 et Windows Phone 7. > Pour plus d’informations, voir Guide pratique pour configurer un environnement pour le développement d’applications mobiles pour SharePoint.

Règles de validation de données par défaut

Certains types de données pour les champs dans les listes SharePoint sont associées par défaut la mise en forme simple ou de la validation des données. Si vous entrez une URL non valide pour un champ en fonction du champ lien hypertexte ou image tapez dans une liste SharePoint et essayez d'enregistrer vos modifications, vous voyez un message indiquant que l'adresse que vous avez entré n'est pas valide. Si vous entrez un nom de client comme une valeur de type de champ pour un champ en fonction de la Date et l'heure, vous recevez un message qui vous indiquera à entrer une date comprise dans une plage valide pour le champ.

Remarque

[!REMARQUE] Validation d'entrée de date est par rapport au format de date de SharePoint. Si le format de date des paramètres régionaux du téléphone est requis, personnaliser le champ et ajouter des validations en conséquence.

Certaines de ces règles de validation de base sont également appliqués par défaut dans une application Windows Phone créée à partir du modèle d'Application de liste SharePoint Windows Phone. Si vous entrez autre chose qu’une valeur de date dans un champ lié à un champ SharePoint de type Date et Heure sous la forme Modifier d’une application Windows Phone basée sur une liste SharePoint, un message d’erreur de validation s’affiche lorsque le focus se déplace du TextBox contrôle associé au champ. (Voir Figure 1.)

Figure 1. Repère d’erreur de validation dans une application Windows Phone

Repère d'erreur de validation dans une application Windows Phone

La zone de texte intitulée « Heure de début » dans le formulaire de modification est liée à un champ de Date et d'heure dans la liste SharePoint sur laquelle repose cet exemple d'application. L’indicateur d’erreur de validation (en texte rouge) affiché dans la figure 1 apparaît si une date non valide est entrée dans la zone de texte (et que la zone de texte perd par la suite le focus), car la ValidatesOnNotifyDataErrors propriété de l’objet Binding associé à la Text propriété du TextBox contrôle est définie True sur dans la déclaration XAML qui définit le TextBox dans le fichier EditForm.xaml .

<StackPanel Orientation="Vertical" Margin="0,5,0,5">
   <TextBlock TextWrapping="Wrap"
              HorizontalAlignment="Left"
              Style="{StaticResource PhoneTextNormalStyle}">Start Time*
   </TextBlock>
   <TextBox Height="Auto"
            Style="{StaticResource TextValidationTemplate}"
            FontSize="{StaticResource PhoneFontSizeNormal}"
            Width="470"
            HorizontalAlignment="Left"
            Name="txtEventDate"
            Text="{Binding [EventDate], Mode=TwoWay, ValidatesOnNotifyDataErrors=True,
                       NotifyOnValidationError=True}"
            TextWrapping="Wrap" />
   <TextBlock FontSize="16"
              TextWrapping="Wrap"
              HorizontalAlignment="Left"
              Style="{StaticResource PhoneTextSubtleStyle}"
              Text="{Binding DateTimeFormat}" />
</StackPanel>

(Si la propriété a la ValidatesOnNotifyDataErrors valeur False, l’utilisateur n’a aucune indication que les données entrées ne sont pas valides tant que le bouton Enregistrer n’est pas choisi. À ce stade, l’utilisateur voit un message d’erreur concernant les erreurs de validation, car la validation du format sur les valeurs de date entrées est toujours effectuée par la classe de base à partir de laquelle la EditItemViewModel classe est dérivée.)

Mais certains champs peut ne pas fournissent aucune notification pour les données non valides dans l'application Windows Phone. Et bien conçu Visual Studio les modèles de projet sont nécessairement généralisées pour être utilisé comme point de départ pour de nombreuses applications différentes. Le modèle d'Application de liste SharePoint Windows Phone ne peut pas inclure les règles de validation appropriées à des contextes spécifiques et encore conservera sa valeur comme modèle généralisé. En fonction de vos besoins et les circonstances dans lesquelles votre application Windows Phone particulier sera utilisée, vous probablement voudrez implémenter vos propres règles de validation de données personnalisée.

Implémentation des règles de validation des données personnalisées

You can validate data entered by users of your Windows Phone app in several ways. A project created by using the Windows Phone SharePoint List Application template includes classes that serve as intermediaries between the forms (that is, the views) of the data in the Windows Phone app (for example, the EditForm.xaml file) and the data itself in the SharePoint list on which the app is based. Ces classes peuvent être considérées comme des implémentations du composant ViewModel du modèle de conception Model-View-ViewModel (Figure 2). (For more information about how the Windows Phone SharePoint List Application template conforms to the MVVM software design pattern, see Architecture du modèle Application de liste SharePoint Windows Phone.)

Remarque

[!REMARQUE] Les modèles de liste SharePoint n'incluent pas les validations par défaut (par exemple, le pourcentage réalisé dans une liste de tâches SharePoint, à cocher post pour une liste de discussion d'équipe et validation du type de champ décimal SP), mais vous pouvez implémenter ces validations.

Figure 2. Fichiers de modèle dans le composant ViewModel

Fichiers de modèle dans le composant ViewModel

Dans les applications conçues selon le modèle MVVM, validation des données est souvent gérée dans la couche données (autrement dit, dans le composant de modèle). Dans les projets créés à partir du modèle d'Application de liste SharePoint Windows Phone, un mécanisme extensible pour la validation des données a été « remonter » un calque et implémenté dans le composant ViewModel, pour le rendre plus facile pour les développeurs gérer la validation des données. Dans les projets basés sur le modèle, par conséquent, la mieux adaptée du code personnalisé qui valide les entrées de l'utilisateur ou dans le cas contraire gère les données est dans ces classes ViewModel. En termes de validation des données, la EditItemViewModel classe et la NewItemViewModel classe (les classes associées aux formulaires les plus susceptibles d’impliquer la modification et la mise à jour des données de liste) fournissent toutes deux une implémentation ouverte d’une méthode de validation (nommée Validate()) qui remplace la méthode de validation de base dans la classe à partir de laquelle ces deux classes sont dérivées.

public override void Validate(string fieldName, object value)
{
  base.Validate(fieldName, value);
}

Cette méthode fournit un mécanisme pratique pour les développeurs à l'ajout d'une logique de validation personnalisée cibles des champs individuels. L’approche générale consiste à vérifier la valeur de l’argument fieldName passé à la Validate() méthode pour identifier le champ que vous souhaitez associer à votre code de validation personnalisé. Vous pouvez, par exemple, utiliser une switch instruction dans votre implémentation de cette méthode pour fournir une logique de validation spécifique à différents champs dans le formulaire De modification (EditForm.xaml) de votre application Windows.

L'exemple de code suivant, supposons qu'une installation de SharePoint Server possède une liste de commandes de produit à partir du modèle de liste personnalisée. La liste a été créée avec les colonnes et les types de champs affichés dans le tableau 1.

Tableau 1. Liste des commandes de produits

Column Type Requis
Produit (c'est-à-dire, titre) Ligne unique de texte (texte) Oui
Description Ligne unique de texte (texte) Non
Quantité Numérique Oui
Date de la commande Date et heure (DateTime) Non
Date d'exécution Date et heure (DateTime) Non
Numéro de contact Ligne unique de texte (texte) Non

Là encore, pour les besoins de cet exemple, supposons que les règles de validation simples suivantes sont soit appliquée, en fonction de la logique métier employée au niveau de la société fictive Contoso, Ltd., pour un produit donné système de commande :

  • Dates d'exécution des commandes doivent être postérieures à la date à laquelle la commande a été passée.
  • Si un client souhaite passer une commande pour un produit nommé dés approximative, dés doivent être classées par paires. En fonction des règles propres au niveau de Contoso, Ltd., il n'existe tout simplement pas comme une matrice approximative.
  • Dans la liste des commandes de produit, le type de champ pour les numéros de téléphone est « Seule ligne de texte » (autrement dit, du texte), qui peut être n'importe quel texte (jusqu'à 255 caractères par défaut). Pour cet exemple, une règle de validation de la mise en forme sera appliquée qui requiert des données saisies dans un des formats de numéro téléphonique communs ; par exemple, « (555) 555-5555 ».

Pour implémenter les règles de validation personnalisées

  1. En supposant que vous avez créé une liste SharePoint basée sur le modèle Liste personnalisée qui inclut les colonnes et les types spécifiés dans le tableau 1, créez une application Windows Phone à l’aide du modèle Windows Phone Application de liste SharePoint dans Visual Studio en suivant les étapes décrites dans Procédure : créer une application de liste Windows Phone SharePoint.

  2. Dans Explorateur de solutions, dans le dossier ViewModels du projet, double-cliquez sur le fichier EditItemViewModel.cs (ou choisissez le fichier et appuyez sur F7) pour ouvrir le fichier à modifier.

  3. Ajoutez les directives suivantes using à la liste des directives en haut du fichier.

    using System.Globalization;
    using System.Text.RegularExpressions;
    
  4. Remplacez l’implémentation par défaut de la Validate() méthode dans le fichier par le code suivant.

    public override void Validate(string fieldName, object value)
    {
        string fieldValue = value.ToString();
        if (!string.IsNullOrEmpty(fieldValue)) //Allowing for blank fields.
        {
            bool isProperValue = false;
    
            switch (fieldName)
            {
                case "Quantity":
                    // Enforce ordering Fuzzy Dice in pairs only.
                    int quantityOrdered;
                    isProperValue = Int32.TryParse(fieldValue, out quantityOrdered);
                    if (isProperValue)
                    {
                        if ((quantityOrdered % 2) != 0) // Odd number of product items ordered.
                        {
                            if ((string)this["Title"] == "Fuzzy Dice")
                            {
                                AddError("Item[Quantity]", "Fuzzy Dice must be ordered in pairs.
                                                                       No such thing as a Fuzzy Die!");
                            }
                            else
                            {
                                // Restriction on ordering in pairs doesn't apply to other products.
                                RemoveAllErrors("Item[Quantity]");
                            }
                        }
                        else
                        {
                            RemoveAllErrors("Item[Quantity]");
                        }
                    }
                    break;
                case "Fulfillment_x0020_Date":
                    // Determine whether fulfillment date is later than order date.
                    DateTime fulfillmentDate;
                    isProperValue = DateTime.TryParse(fieldValue, CultureInfo.CurrentCulture,
                                  DateTimeStyles.AssumeLocal, out fulfillmentDate);
                    if (isProperValue)
                    {
                        DateTime orderDate;
                        isProperValue = DateTime.TryParse((string)this["Order_x0020_Date"],
                                   CultureInfo.CurrentCulture, DateTimeStyles.AssumeLocal, out orderDate);
    
                        if (fulfillmentDate.CompareTo(orderDate) > 0)
                        {
                            RemoveAllErrors("Item[Fulfillment_x0020_Date]");
                        }
                        else
                        {
                            AddError("Item[Fulfillment_x0020_Date]",
                                    "Fulfillment Date must be later than Order Date.");
                        }
                    }
                    break;
                case "Contact_x0020_Number":
                    // Check that contact number is in an appropriate format.
                    Regex rx = new Regex(@"^\\(?([0-9]{3})\\)?[-. ]?([0-9]{3})[-. ]?([0-9]{4})$");
                    if (rx.IsMatch(fieldValue))
                    {
                        RemoveAllErrors("Item[Contact_x0020_Number]");
                    }
                    else
                    {
                        //Specified Contact Number is not a valid phone number.
                        AddError("Item[Contact_x0020_Number]", "Specified Contact Number is invalid.");
                    }
                    break;
                default:
                    // Not adding custom validation for other fields.
                    break;
            }
        }
    
        //And then proceed with default validation from base class.
        base.Validate(fieldName, value);
    }
    

    N'oubliez pas que les noms des champs spécifiés dans cet exemple de code sont basées sur les propriétés de l'exemple de liste d'ordres du produit spécifié dans le tableau 1. (Notez que dans le schéma XML des champs de liste dans SharePoint Server, les espaces dans les noms des champs sont remplacés par la chaîne « x0020 » pour l’attribut Name de l’élément Field qui définit un champ donné. Le modèle utilise l’attribut Name pour un élément Field tel qu’il est défini dans le schéma XML sur le serveur, et non l’attribut DisplayName .) Vous pouvez identifier les noms des champs pour lesquels vous souhaitez implémenter la logique de validation en examinant les déclarations binding des propriétés Text pour les objets TextBox définis dans EditForm.xaml ou en examinant la chaîne ViewFields de la classe CamlQueryBuilder dans le fichier ListProvider.cs.

  5. Enregistrez le fichier.

Le code de validation personnalisée dans cet exemple est exécuté uniquement si l'argument value passé à la méthode Validate n'est pas une chaîne nulle ou vide. Comme indiqué dans le tableau 1, les champs Date de traitement et le numéro de Contact ne sont pas tenus de contiennent des données (telle que la liste est définie pour les besoins de cet exemple dans SharePoint Server ), c'est pourquoi nous voulons permettre à ces champs vides. Une vérification simple pour déterminer si l'argument value est null n'est pas suffisante, étant donné que la valeur transmise peut être une chaîne de longueur nulle (qui ne correspondent pas à une valeur null), et pour cet exemple, nous ne souhaitons invalider les chaînes de longueur nulle pour les champs qui peuvent être vides. La logique de validation pour les champs de la quantité et la Date de l'exécution des commandes inclut des contrôles supplémentaires de valeurs transmises pour s'assurer qu'ils sont du type approprié. Si la vérification initiale ici (avant l’instruction switch ) confirmait uniquement que la valeur passée n’était pas null (au lieu de vérifier par rapport à la condition plus étroite d’être une chaîne de longueur nulle), ces validations ne s’exécuteraient toujours pas si la valeur était une chaîne de longueur nulle, mais la logique de validation des données pour le champ Numéro de contacts’exécuterait toujours si la valeur passée était une chaîne de longueur nulle. Et, dans cet exemple, nous voulons à autoriser pour le champ de numéro de Contact être vide (une chaîne de longueur nulle), en particulier lorsqu'un utilisateur démarre la modification d'un élément de liste en ouvrant le formulaire de modification.

Si vous générez le projet et le déployez sur Windows Phone Emulator pour l’exécuter, vous pouvez tester votre logique de validation en entrant des données qui enfreignent vos règles d’entreprise dans les champs de la liste dans le formulaire De modification de l’application. (Voir la figure 3.)

Figure 3. Repères d’erreur de validation personnalisés

Repères d'erreur de validation personnalisés

Le code dans cet exemple, si elle est incluse dans le fichier EditItemViewModel.cs et applique ces règles de validation des données entrées par les utilisateurs uniquement sur le formulaire de modification. Si vous souhaitez appliquer les règles de validation lorsque les utilisateurs ajoutent de nouveaux éléments et lorsqu’ils les modifient, vous devez inclure la même logique de validation dans la Validate() méthode dans le fichier NewItemViewModel.cs (ou, de préférence, créer un fichier de classe distinct avec une fonction qui inclut cette logique de validation et appeler cette même fonction à partir des Validate() méthodes du fichier EditItemViewModel.cs et du fichier NewItemViewModel.cs).

The validation logic in this sample enforces given business rules by indicating to the user that entered data is not in a format permitted by the rules, but the entered data is not intercepted and changed by this code. To intercept and, for example, format phone numbers in a consistent way before saving the data to the SharePoint list, you can implement custom data conversion for entered phone numbers. Pour obtenir une explication de la conversion de données personnalisées pour les champs d’élément de liste, voir Guide pratique pour prendre en charge et convertir des types de champs SharePoint pour Windows Phone applications.

Voir aussi