Formulaires : Directives et meilleures pratiques d'ordre général

Date de publication : juillet 2016

S’applique à : System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

Vous pouvez étendre les fonctionnalités de System Center 2012 - Service Manager en ajoutant ou en modifiant des formulaires. Cette rubrique décrit certaines recommandations concernant la création et l'utilisation de formulaires Service Manager , à l'aide de divers outils et de scripts de définitions de formulaire.

Cette rubrique est principalement destinée aux partenaires et aux clients possédant de solides connaissances de la création de formulaires personnalisés à l'aide de Windows Presentation Foundation (WPF) et Microsoft Visual Studio Team System ou Microsoft Expression Blend.

Les conseils d'ordre général concernant la création de nouveaux formulaires sont les suivants :

• Utilisez des contrôles standard.

• Suivez les instructions générales de conception de formulaires.

• Évitez le code-behind.

• Utilisez la gestion des exceptions.

• Envisagez la personnalisation et la mise à niveau des formulaires.

• Nommez tous les contrôles personnalisables.

• Liez le formulaire aux sources de données.

• Utilisez les règles de validation de l'infrastructure des formulaires Service Manager , les convertisseurs de valeurs et les modèles d'erreur.

• Utilisez les commandes et les événements d'infrastructure de formulaires.

Pour plus d'informations sur ces instructions, consultez les sections suivantes.

Utiliser des contrôles standard

Les contrôles utilisés dans les formulaires sont les suivants :

• Contrôles standard. Cela comprend les contrôles de bibliothèque .NET, tels que les zones de liste déroulante et les zones de liste.

• Contrôles personnalisés. Cela comprend les contrôles supplémentaires qui sont créés par l'auteur du formulaire ou par un tiers.

Astuce

En utilisant des contrôles standard et en évitant, dans la mesure du possible, de créer des contrôles personnalisés, vous garantissez la cohérence de l'expérience utilisateur. Si vous devez créer un contrôle personnalisé, séparez l'apparence et le comportement visuels du comportement logique à l'aide de modèles de contrôle permettant de définir l'apparence du contrôle. De préférence, chaque thème Windows doit posséder son propre modèle de contrôle.

Suivre les instructions générales de conception de formulaires

Lorsque vous créez un formulaire, suivez les recommandations en matière de conception afin de garantir un formulaire convivial et respectant les paradigmes courants d'interaction utilisateur.

Pour plus d'informations générales sur la conception dans Windows design, voir Windows User Experience Interaction Guidelines (Conseils en matière d'interaction et d'expérience utilisateur Windows).

En outre :

• Répartissez les informations sur plusieurs onglets pour rendre le formulaire plus simple et plus facile à lire. Placez les informations les plus couramment utilisées sous le premier onglet, et les informations moins importantes sous les onglets suivants.

• Utilisez les panneaux de disposition pour disposer les contrôles du formulaire. Cela permet de garantir le comportement correct du formulaire lorsqu'il est redimensionné et localisé.

• Évitez de définir des propriétés visuelles pour chacun des contrôles, et utilisez plutôt des styles. Cela vous permettra de modifier l'apparence des contrôles d'un ensemble de formulaires en modifiant uniquement le style, assurant ainsi la cohérence visuelle des formulaires.

Éviter le code-behind

Lecode-behind correspond au code joint à l'aide d'objets au balisage défini lors de la compilation du balisage d'une page XAML. Limitez autant que possible l'utilisation de code-behind dans un formulaire. Il est préférable d'incorporer le code d'un formulaire dans le contrôle, car cela facilite les modifications ultérieures du code. Utilisez plutôt les fonctionnalités déclaratives prises en charge par l'infrastructure des formulaires Service Manager afin de définir les conversions de valeurs et les règles de validation d'un formulaire.

Il est généralement conseillé de limiter l'utilisation de code-behind aux situations dans lesquelles les fonctionnalités déclaratives du XAML (classes définies dans WPF et dans la bibliothèque d'infrastructure des formulaires) ne suffisent pas. Même dans ce cas, envisagez de déplacer la fonctionnalité implémentée dans le code-behind vers une bibliothèque d'assistance, puis de la référencer depuis le XAML.

Utiliser la gestion des exceptions

Assurez-vous que le code du formulaire comprend la gestion des exceptions, afin que le formulaire puisse être chargé dans Outil de création au cours de la phase de conception, et dans la Console de Service Manager au moment de l'exécution.

Envisager la personnalisation et la mise à niveau des formulaires

Lorsque vous concevez un formulaire, vous devez prendre en compte ses futures personnalisations et mises à niveau. Pour garantir la capacité à personnaliser et mettre à niveau un formulaire tout en préservant les personnalisations apportées, suivez les conseils fournis précédemment dans cette section, ainsi que les conseils suivants :

• Envisagez les futures personnalisations et mises à niveau le plus tôt possible, lors de la conception du formulaire. Les formulaires sont susceptibles d'être modifiés d'une version à l'autre. Il est donc important de prendre en compte la capacité à mettre à niveau les formulaires tout en préservant les personnalisations déjà apportées au formulaire d'origine. Par exemple, vous pouvez mettre à jour un formulaire, même si celui-ci a déjà été personnalisé de façon importante par les utilisateurs. Les utilisateurs s'attendent à ce que leurs personnalisations soient conservées après la mise à niveau de la version.

• Fournissez un nom unique pour chaque contrôle du formulaire afin de permettre aux personnalisations d'être appliquées aux contrôles. Les personnalisations de formulaire sont stockées sous la forme d'un ensemble d'actions ciblant un contrôle spécifique ou un ensemble de contrôles. Le contrôle cible est référencé par son nom, c'est pourquoi il est important de conserver les noms de contrôle d'une version de formulaire à l'autre. Si un contrôle n'a pas de nom, l'éditeur de personnalisation de formulaire générera un nom. Toutefois, ce nom ne sera pas conservé dans la prochaine version du formulaire.

• Vous devez faire en sorte que les noms de contrôle soient conservés d'une version de formulaire à l'autre. Cela permet de conserver les personnalisations apportées à un contrôle dans la version suivante du formulaire.

• Si possible, évitez de déplacer les contrôles vers un autre emplacement du même onglet lors de la mise à niveau du formulaire. L'une des personnalisations fréquemment apportées par les utilisateurs est le déplacement des contrôles du formulaire vers un autre emplacement. Si vous modifiez l'emplacement d'un contrôle dans le cadre d'une nouvelle version du formulaire, le nouvel emplacement du contrôle risque de créer un conflit avec un contrôle déplacé par l'utilisateur.

• Dans la mesure du possible, évitez de déplacer les contrôles d'un onglet à l'autre lorsque vous mettez à jour un formulaire existant. Les contrôles sont identifiés à la fois par leur nom et par l'onglet sous lequel ils se trouvent. Le déplacement d'un contrôle d'un onglet à l'autre dans le cadre d'une nouvelle version peut annuler les personnalisations apportées par les utilisateurs au contrôle en question, car elles ne pourront pas identifier le contrôle cible.

• Lorsque la mise à jour d'un formulaire comprend de nouveaux contrôles, envisagez d'ajouter ces nouveaux contrôles à un nouvel onglet. Il s'agit du moyen le plus sûr d'éviter tout conflit avec les personnalisations apportées par les utilisateurs aux contrôles et onglets existants.

• N'oubliez pas la façon dont les contrôles doivent être liés. Les contrôles en lecture seule doivent utiliser uniquement des liaisons unidirectionnelles.

Nommer tous les contrôles personnalisables

Assurez-vous que le nom des contrôles reflète les données auxquelles ils sont liés, ou bien le rôle qu'ils jouent.

Lier le formulaire aux sources de données

Le principal objectif du formulaire est de visualiser un objet de la base de données Service Manager . Cet objet est une target instance, qui est toujours spécifiée par la propriété DataContext d'un formulaire (héritée de la classe FrameworkElement ).

Dans le modèle de données Service Manager , une instance cible est représentée sous la forme d'un objet BindableDataItem . Cette classe agrège l'objet de Kit de développement logiciel (SDK) sous-jacent, puis expose ses propriétés via un indexeur acceptant un nom de propriété en tant que paramètre.

La classe BindableDataItem implémente également ICustomTypeDescriptor, ce qui permet l'utilisation de la classe BindableDataItem en tant que source de données pour la liaison WPF. L'exemple suivant illustre la liaison d'une propriété d'instance cible à la propriété Text du contrôle TextBox :

  
<TextBox Name="textBoxDescription" Text="{Binding Path=Summary}"/>  
  

Il n'est pas nécessaire de spécifier la Source de la liaison, car les instances cibles sont définies en tant que DataContext du formulaire, servant ainsi de Source par défaut pour l'ensemble des contrôles du formulaire.

Les contrôles du formulaire peuvent être liés à des sources de données autres que l'instance cible. La bibliothèque d'infrastructure des formulaires contient plusieurs contrôles qui permettent d'effectuer une liaison de manière implicite. Par exemple, le contrôle de sélecteur d'instance est lié à la source de données, qui fournit la collection d'instances à sélectionner. Il est également possible de définir de façon déclarative des sources de données supplémentaires à l'aide des classes ObjectDataProvider et XmlDataProvider .

L'infrastructure des formulaires considère l'instance cible comme la seule source de données en lecture-écriture du formulaire. Par conséquent, l'implémentation de la commande Submit stocke uniquement les modifications apportées à l'instance cible. Les autres sources de données du formulaire sont en lecture seule.

Utiliser les règles de validation de l'infrastructure des formulaires, les convertisseurs de valeurs et les modèles d'erreur

Il est recommandé d'utiliser des règles de validation de l'infrastructure dans les formulaires afin de désigner les entrées de données non valides. L'infrastructure de liaison WPF prend en charge la validation des propriétés de contrôle qui sont liées à une source de données par le biais de liaisons unidirectionnelles ou bidirectionnelles. L'objet de liaison est associé à une collection de ValidationRule pouvant contenir tout nombre d'objets ValidationRule . À chaque insertion des données du contrôle dans la source de données, les objets ValidationRule sont appelés pour valider la valeur.

La bibliothèque d'infrastructure des formulaires contient un certain nombre de règles de validation qui prennent en charge les scénarios les plus courants. L'infrastructure des formulaires s'appuie sur les règles de validation pour déterminer si le contenu du formulaire peut être envoyé en vue de son stockage. Par exemple, le bouton Envoyer d'un formulaire peut être désactivé en cas d'erreur de validation concernant un contrôle du formulaire.

Il est recommandé d'utiliser le modèle d'erreur personnalisé qui est fourni avec la bibliothèque d'infrastructure des formulaires. En cas d'erreur de validation d'un contrôle, celui-ci apparaît par défaut avec une bordure rouge. WPF permet de définir un indicateur d'erreur personnalisé par le biais de la propriété Validation.ErrorTemplate , qui peut être définie pour n'importe quel contrôle. La bibliothèque d'infrastructure des formulaires Service Manager contient un modèle de message d'erreur personnalisé qui comprend une icône d'erreur au lieu de la bordure rouge de WPF. En outre, lorsque l'utilisateur pointe sur l'icône d'erreur à l'aide de la souris, une info-bulle apparaît avec un message d'erreur. Le message d'erreur doit indiquer la raison de l'échec de la validation des données du contrôle.

L'exemple suivant indique comment référencer le modèle d'erreur dans le code XAML :

  
<TextBox Text="{Binding SomeProperty}"  
         scwpf:Validation.ValueRequired="True"   
         Validation.ErrorTemplate="{DynamicResource {ComponentResourceKey {x:Type scwpf:Validation}, InvalidDataErrorTemplate}}"/>  
  

Si les règles de validation prédéfinies ne fournissent pas la logique de validation requise, il est recommandé de créer des règles de validation personnalisées pour représenter cette logique. Cela permet la coexistence des logiques de validation standard et personnalisée au sein du mécanisme commun de gestion des validations.

Si le mécanisme des règles de validation ne convient pas à un scénario en particulier, gérez plutôt FormEvents.PreviewSubmitEvent , puis exécutez la validation à partir de là.

L'exemple de code suivant fournit un exemple du modèle que vous pouvez utiliser pour exécuter une validation personnalisée :

  
void MyForm_Loaded(object sender, RoutedEventArgs e)  
{  
    // hook to handle form events  
    this.AddHandler(  
        FormEvents.PreviewSubmitEvent,  
        new EventHandler<PreviewFormCommandEventArgs>(this.OnPreviewSubmit));  
}  
private void OnPreviewSubmit(object sender, PreviewFormCommandEventArgs e)  
{  
    string errorMessage;  
    bool result = this.DoVerify(out errorMessage);  
    if (!result)  
    {  
        // cancel Submit operation  
        e.Cancel = true;  
        // display error message  
        MessageBox.Show(errorMessage);  
    }  
}  
internal bool DoVerify(out string errorMessage)  
{  
    // Do custom verification and return true to indicate that  
    // validation check has passed; otherwise return false and  
    // populate errorMessage argument  
}  
  

Utiliser les commandes et les événements d'infrastructure de formulaires

L'infrastructure des formulaires contient un certain nombre de commandes pouvant être exécutées dans un formulaire. Ces commandes sont les suivantes :

• FormsCommand.Submit, qui enregistre l'instance cible du formulaire.

• FormsCommand.SubmitAndClose, qui enregistre l'instance cible du formulaire, puis ferme le formulaire.

• FormsCommand.Refresh, qui répète la requête pour l'instance cible du formulaire.

• FormCommands.Cancel, qui ignore toutes les modifications, puis ferme le formulaire.

Chacune de ces commandes est encadrée par des événements, qui sont déclenchés avant et après l'exécution de la commande.

Les événements suivants sont déclenchés avant la commande :

• L'événement FormEvents.PreviewSubmit est déclenché avant la commande FormCommand.Submit , et l'événement FormEvents.Submitted est déclenché après la commande FormCommand.Submit .

• L'événement FormEvents.PreviewRefresh est déclenché avant la commande FormCommands.Refresh , et la commande FormCommand.Refreshed est déclenchée après la commande FormCommand.Submit .

• L'événement FormEvents.PreviewCancel est déclenché avant la commande FormCommands.Cancel , et l'événement FormCommand.Canceled est déclenché après la commande FormCommand.Cancel .

Les événements d'aperçu passent un objet PreviewFormCommandEventArgs . Cet objet contient une propriété Cancel mutable qui empêchera l'exécution de la commande correspondante lorsque la propriété est définie sur true.

Les événements post-commande passent un objet FormCommandExecutedEventArgs . Cet objet contient une propriété Result qui indique si l'exécution de la commande a réussi, a été annulée ou a provoqué une erreur. En cas d'erreur, la propriété Error de l'objet FormCommandExecutedEventArgs référence l'exception qui fournit les informations relatives à l'erreur.

Il est possible d'activer, de désactiver et d'exécuter des commandes de formulaire par programme et de manière déclarative.

Pour activer les commandes de formulaire par programme, établissez une liaison CommandBinding entre le formulaire et la commande.

Dans l'exemple suivant, une liaison de commande est établie entre le formulaire et une commande Refresh , et deux gestionnaires sont définis pour cette commande. Le premier gestionnaire indique si une commande Refresh peut être exécutée. Le second gestionnaire contient l'implémentation de la commande Refresh :

  
    public class MyForm : UserControl  
    {  
        public MyForm()  
        {  
            // do standard initialization  
            // establish CommandBinding for Refresh command  
            this.CommandBindings.Add(  
                new CommandBinding(FormCommands.Refresh, this.ExecuteRefresh, this.CanExecuteRefresh));  
        }  
        private void CanExecuteRefresh(  
              object sender,  
              CanExecuteRoutedEventArgs e)  
        {  
            // put your logic that determines whether Refresh   
// can be executed here  
            bool canExecute = true;  
            BindableDataItem dataItem = this.DataContext as BindableDataItem;  
            if (dataItem)  
            {  
                canExecute = dataItem["Status"] != "New";  
            }  
            e.CanExecute = canExecute;  
        }  
        private void ExecuteRefresh(  
            object sender,  
            ExecutedRoutedEventArgs e)  
        {  
            // here is placeholder for the code that has do be   
// executed upon running Refresh command  
        }  
    }  
  

Vous pouvez également définir des gestionnaires pour les commandes de formulaire de manière déclarative. Pour cela, utilisez un objet Rule qui utilise un RoutedCommandTrigger. L'exemple de code suivant montre comment définir des gestionnaires de façon déclarative :

  
    <scwpf:BusinessLogic.Rules>  
        <scwpf:RuleCollection>  
            <scwpf:Rule>  
                <scwpf:Rule.Triggers>  
                    <scwpf:RoutedCommandTrigger   
RoutedCommand="{x:Static scwpf:FormCommands.Refresh}"/>  
                </scwpf:Rule.Triggers>  
                <scwpf:Rule.Conditions>  
                    <scwpf:PropertyMatchCondition   
                        Binding="{Binding Status}"   
                        Value="New"   
                        Operation="NotEquals" />  
                </scwpf:Rule.Conditions>  
                <!-- Use RuleAction objects to define the logic that executed   
                upon running Refresh command; this can be left empty -->  
            </scwpf:Rule>  
        </scwpf:RuleCollection>  
    </scwpf:BusinessLogic.Rules>  
  

Site web de Windows Presentation Foundation (WPF) (WindowsClient.NET)
Formulaires : Personnalisation et création