Formulare: Allgemeine Richtlinien und bewährte Methoden

 

Veröffentlicht: Juli 2016

Gilt für: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

Funktionen von System Center 2012 – Service Manager können durch Hinzufügen oder Ändern von Formularen erweitert werden. In diesem Thema werden einige Empfehlungen für bewährte Methoden zum Erstellen und Verwenden von Service Manager -Formularen mithilfe von verschiedenen Tools und durch direktes Erstellen eines Skripts für Formulardefinitionen beschrieben.

Dieses Thema ist in erster Linie für Partner und Kunden bestimmt, die Erfahrung im Erstellen von eigenen benutzerdefinierten Formularen mithilfe von Windows Presentation Foundation (WPF) und Microsoft Visual Studio Team System oder Microsoft Expression Blend haben.

Die allgemeinen Richtlinien für das Erstellen eines neuen Formulars lauten wie folgt.

• Verwenden Sie Standardsteuerelemente.

• Befolgen Sie allgemeine Richtlinien für den Formularentwurf.

• Vermeiden Sie CodeBehind.

• Beziehen Sie Ausnahmebehandlung mit ein.

• Berücksichtigen Sie Formularanpassungen und Formularupgrades.

• Benennen Sie alle anpassbaren Steuerelemente.

• Binden Sie das Formular an Datenquellen.

• Verwenden Sie Gültigkeitsprüfungsregeln, Wertkonverter und Fehlervorlagen der Service Manager -Formularinfrastruktur.

• Verwenden Sie Befehle und Ereignisse der Formularinfrastruktur.

Informationen zu diesen Richtlinien finden Sie in folgenden Abschnitten.

Verwenden von Standardsteuerelementen

Folgende Steuerelemente können in einem Formular verwendet werden:

• Standardsteuerelemente. Hierzu gehören Steuerelemente der .NET-Bibliothek, z. B. Kombinationsfeld und Listenfeld.

• Benutzerdefinierte Steuerelemente. Hierzu zählen weitere Steuerelemente, die vom Formularautor oder einem Dritten erstellt werden.

Tipp

Wenn Sie möglichst immer Standardsteuerelemente verwenden und die Erstellung benutzerdefinierter Steuerelemente vermeiden, fördern Sie die Konsistenz im Hinblick auf die Benutzerfreundlichkeit von Formularen. Wenn Sie ein benutzerdefiniertes Steuerelement erstellen müssen, trennen Sie die visuelle Darstellung und das Verhalten vom logischen Verhalten, indem Sie zum Definieren der Darstellung des Steuerelements Steuerelementvorlagen verwenden. Vorzugsweise sollte für jedes Windows-Design eine separate Steuerelementvorlage vorhanden sein.

Befolgen allgemeiner Richtlinien für den Formularentwurf

Stellen Sie beim Entwurf eines Formulars mithilfe von öffentlichen Entwurfsrichtlinien sicher, dass das Formular benutzerfreundlich ist und allgemeinen Paradigmen für den Benutzereingriff entspricht.

Weitere Informationen zu allgemeinen Windows-Designs finden Sie unter Windows User Experience Interaction Guidelines (Richtlinien für den Eingriff durch Windows-Benutzer).

Beachten Sie auch Folgendes:

• Verteilen Sie Informationen auf mehrere Registerkarten, damit das Formular einfacher zu lesen ist. Fügen Sie die am häufigsten verwendeten Informationen auf der ersten Registerkarte und weniger wichtige Informationen auf nachfolgenden Registerkarten ein.

• Verwenden Sie Layoutbereiche, um Steuerelemente auf dem Formular anzuordnen. Dadurch wird sichergestellt, dass sich das Formular ordnungsgemäß verhält, wenn die Größe des Formulars angepasst und das Formular lokalisiert wird.

• Vermeiden Sie es, für visuelle Eigenschaften einzelne Steuerelemente festzulegen. Verwenden Sie stattdessen Formatvorlagen. Auf diese Weise können Sie die Darstellung aller Steuerelemente in mehreren Formularen ändern, indem Sie die Formatvorlage ändern. So fördern Sie eine konsistente Darstellung in allen verwandten Formularen.

Vermeiden von CodeBehind

CodeBehind ist ein Ausdruck, mit dem der Code beschrieben wird, der beim Ausführen der Markupkompilierung für eine XAML-Seite mit Markup-definierten Objekten verknüpft wird. Sie sollten die Verwendung von CodeBehind in Formularen so weit wie möglich beschränken. Besser ist es, den Code für ein Formular in das Steuerelement einzubetten, da es leichter ist, später diesen Code zu ändern. Verwenden Sie stattdessen die Deklarationsfunktionen, die von der Service Manager -Formularinfrastruktur unterstützt wird, um Wertkonvertierungen und Gültigkeitsprüfungsregeln im Formular zu definieren.

Generell sollten Sie die Verwendung von CodeBehind auf Situationen beschränken, in denen es nicht möglich ist, die erforderliche Funktionalität mithilfe der Deklarationsfunktionen von XAML mit in WPF definierten Klassen und der Bibliothek der Formularinfrastruktur bereitzustellen. Selbst dann sollten Sie die in CodeBehind implementierte Funktionalität in eine Hilfsbibliothek verschieben und dann im XAML-Code darauf verweisen.

Einbeziehen der Ausnahmebehandlung

Stellen Sie sicher, dass der Code im Formular eine Ausnahmebehandlung enthält, sodass das Formular während der Entwurfsphase im Authoring Tool sowie zur Laufzeit in die Service Manager-Konsole geladen werden kann.

Berücksichtigen von Formularanpassungen und Formularupgrades

Beim Entwerfen eines neuen Formulars sollten Sie künftige Anpassungen und Upgrades für dieses Formular berücksichtigen. Befolgen Sie die Richtlinien und Tipps weiter oben in diesem Abschnitt sowie folgende Richtlinien, um sicherzustellen, dass ein Formular angepasst und ein Upgrade unter Beibehaltung von Anpassungen ausgeführt werden kann:

• Berücksichtigen Sie zukünftige Anpassungen und Aktualisierungen frühzeitig beim Entwerfen des Formulars. Formulare werden in zukünftigen Versionen weiterentwickelt. Daher ist es wichtig zu berücksichtigen, dass Benutzer unter Beibehaltung ihrer Anpassungen des ursprünglichen Formulars ein Upgrade auf neuere Versionen des Formulars ausführen können. So kann es beispielsweise vorkommen, dass Sie ein aktualisiertes Formular bereitstellen, nachdem Benutzer das ursprüngliche Formular umfangreich angepasst haben. Benutzer erwarten, dass ihre Anpassungen beim Versionsupgrade beibehalten werden.

• Geben Sie für jedes Steuerelement im Formular einen eindeutigen Namen an, damit Anpassungen auf Steuerelemente angewendet werden können. Formularanpassungen werden in Form von Aktionen gespeichert, die von einem bestimmten Steuerelement oder von einem bestimmten Satz Steuerelemente als Ziel verwendet werden. Das Zielsteuerelement wird anhand des Namens referenziert. Daher ist es wichtig, dass die Namen von Steuerelementen in allen Versionen des Formulars erhalten bleiben. Wenn ein Steuerelement keinen Namen hat, wird vom Formularanpassungs-Editor ein Name generiert. Der generierte Name wird jedoch in den verschiedenen Versionen des Formulars nicht beibehalten.

• Stellen Sie sicher, dass Steuerelementnamen in verschiedenen Versionen des Formulars unveränderlich bleiben. Dadurch wird sichergestellt, dass Anpassungen für ein bestimmtes Steuerelement einer früheren Version auf dasselbe Steuerelement in einer neueren Version des Formulars angewendet werden können.

• Wenn möglich, sollten Sie beim Ausführen eines Upgrade für ein Formular vermeiden, Steuerelemente auf einer Registerkarte an eine andere Position zu verschieben. Benutzer nehmen häufig die Anpassung vor, dass sie Steuerelemente auf dem Formular an eine andere Position verschieben. Wenn Sie die Position eines Steuerelements in einer neuen Version des Formulars ändern, besteht die Gefahr, dass sich die neue Position des Steuerelements mit einem Steuerelement überschneidet, dem vom Benutzer eine neue Position zugewiesen wurde.

• Wenn möglich, sollten Sie beim Entwerfen eines Updates für ein vorhandenes Formular vermeiden, Steuerelemente zwischen Registerkarten zu verschieben. Steuerelemente werden anhand des Namens und anhand der Registerkarte, auf der sie sich befinden, identifiziert. Wenn ein Steuerelement von einer Registerkarte auf eine andere Registerkarte in der neuen Version des Formulars verschoben wird, können die vom Benutzer an diesem Steuerelement vorgenommenen Anpassungen unterbrochen werden, da das Zielsteuerelement von den Anpassungen nicht identifiziert werden kann.

• Wenn das Update für ein Formular neue Steuerelemente enthält, sollten Sie die neuen Steuerelemente einer neuen Registerkarte hinzufügen. Auf diese Weise können Sie am sichersten vermeiden, mit Benutzeranpassungen für vorhandene Registerkarten und Steuerelemente in Konflikt zu geraten.

• Berücksichtigen Sie wie die Steuerelemente gebunden werden. Für schreibgeschützte Steuerelemente sollten nur unidirektionale Bindungen verwendet werden.

Benennen aller anpassbaren Steuerelemente

Stellen Sie sicher, dass mit den Steuerelementnamen beschrieben wird, an welche Daten das Steuerelement gebunden wurde oder was das Steuerelement bewirkt.

Binden des Formulars an Datenquellen

Die Hauptaufgabe eines Formulars besteht in der Visualisierung eines Objekts aus der Service Manager -Datenbank. Dieses Objekt wird als target instancebezeichnet, die immer von der Eigenschaft DataContext eines Formulars angegeben wird (die von der Klasse FrameworkElement vererbt wird).

Wichtig
Ändern Sie die Eigenschaft DataContext des Formulars nicht. In der Formularhostumgebung wird diese Eigenschaft zum Identifizieren der Formularzielinstanz verwendet.

Im Service Manager -Datenmodell wird eine Zielinstanz in Form eines Objekts vom Typ BindableDataItem dargestellt. Von dieser Klasse wird das zugrunde liegende SDK-Objekt (Software Development Kit) aggregiert. Zudem macht sie ihre Eigenschaften über einen Indexer verfügbar, von dem ein Eigenschaftsname als Parameter angenommen wird.

Von der Klasse BindableDataItem wird auch ICustomTypeDescriptorimplementiert. Dadurch kann die Klasse BindableDataItem als Datenquelle für die WPF-Bindung verwendet werden. Im folgenden Beispiel ist die Bindung einer Zielinstanzeigenschaft an die Eigenschaft Text eines Steuerelements vom Typ TextBox dargestellt:

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

Die Source der Bindung muss nicht angegeben werden, da die Zielinstanzen als DataContext des Formulars festgelegt werden, der als Standard- Source für alle Steuerelemente im Formular dient.

Steuerelemente im Formular können an andere Datenquellen als an die Zielinstanz gebunden werden, und die Bibliothek der Formularinfrastruktur enthält Steuerelemente, von denen die Bindung implizit ausgeführt wird. Das Steuerelement zur Auswahl einer Instanz ist beispielsweise an die Datenquelle gebunden, von der die Sammlung mit Instanzen zur Auswahl bereitgestellt wird. Darüber hinaus ist es möglich, mithilfe der Klassen ObjectDataProvider und XmlDataProvider weitere Daten deklarativ zu definieren.

Von der Formularinfrastruktur wird die Zielinstanz als die einzige Lese-/Schreib-Datenquelle im Formular erkannt. Daher werden bei der Implementierung des Befehls Submit nur die an der Zielinstanz vorgenommenen Änderungen gespeichert. Andere Datenquellen des Formulars werden wie schreibgeschützte Datenquellen behandelt.

Verwenden von Gültigkeitsprüfungsregeln, Wertkonverter und Fehlervorlagen der Service Manager-Formularinfrastruktur

Es wird empfohlen, in Formularen Gültigkeitsprüfungsregeln der Formularinfrastruktur zu verwenden, um ungültige Dateneingaben zu bestimmen. Von der WPF-Bindungsinfrastruktur wird die Gültigkeitsprüfung für Steuerelementeigenschaften unterstützt, die über eine unidirektionale oder bidirektionale Bindung an eine Datenquelle gebunden sind. Das Bindungsobjekt verfügt über eine Sammlung vom Typ ValidationRules , die eine beliebige Anzahl von Objekten vom Typ ValidationRule enthalten kann. Wenn Daten mithilfe von Push vom Steuerelement an die Datenquelle übertragen werden, werden die Objekte vom Typ ValidationRule zur Gültigkeitsprüfung des Werts aufgerufen.

Die Bibliothek der Formularinfrastruktur enthält mehrere Gültigkeitsprüfungsregeln für die meisten gängigen Fälle. Von der Formularinfrastruktur werden die Gültigkeitsprüfungsregeln verwendet, um zu ermitteln, ob die Formularinhalte zum Speichern übermittelt werden können. Die Schaltfläche Übermitteln eines Formulars kann beispielsweise deaktiviert werden, wenn ein Steuerelement mit einem Überprüfungsfehler im Formular vorhanden ist.

Es wird empfohlen, die mit der Bibliothek der Formularinfrastruktur bereitgestellte benutzerdefinierte Fehlervorlage zu verwenden. Wenn ein Steuerelement einen Überprüfungsfehler aufweist, wird es standardmäßig mit einem roten Rahmen angezeigt. Mithilfe von WPF kann über die Eigenschaft Validation.ErrorTemplate ein benutzerdefinierter Fehlerindikator definiert werden, der für jedes Steuerelement festgelegt werden kann. Die Bibliothek der Service Manager -Formularinfrastruktur enthält eine benutzerdefinierte Fehlervorlage, mit deren Hilfe anstelle des roten WPF-Rahmens ein Fehlersymbol angezeigt wird. Zudem wird eine QuickInfo mit einer Fehlermeldung angezeigt, wenn der Benutzer mit der Maus auf das Fehlersymbol zeigt. In der Fehlermeldung sollte der Grund dafür angegeben werden, warum bei der Gültigkeitsprüfung der Daten im Steuerelement ein Fehler aufgetreten ist.

Mit dem folgenden Beispiel wird gezeigt, wie die Fehlervorlage in XAML referenziert wird:

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

Wenn von den integrierten Gültigkeitsprüfungsregeln nicht die erforderliche Gültigkeitsprüfungslogik bereitgestellt wird, wird empfohlen, benutzerdefinierte Gültigkeitsprüfungsregeln zur Darstellung dieser Logik zu erstellen. So können im allgemeinen Mechanismus zur Behandlung von Gültigkeitsprüfungen gleichzeitig eine Standardgültigkeitsprüfungslogik und eine benutzerdefinierte Gültigkeitsprüfungslogik vorhanden sein.

Wenn der Mechanismus mit den Gültigkeitsprüfungsregeln für ein bestimmtes Szenario nicht geeignet ist, sollten Sie stattdessen FormEvents.PreviewSubmitEvent behandeln und die Gültigkeitsprüfung von dort ausführen.

Der folgende Code ist ein Beispiel für das Muster, das Sie verwenden können, um eine benutzerdefinierte Gültigkeitsprüfung auszuführen:

  
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  
}  
  

Verwenden von Befehlen und Ereignissen der Formularinfrastruktur

Von der Formularinfrastruktur werden Befehle angezeigt, die in einem Formular ausgeführt werden können. Folgende Befehle sind verfügbar:

• FormsCommand.Submit: Mit diesem Befehl wird die Zielinstanz des Formulars gespeichert.

• FormsCommand.SubmitAndClose: Mit diesem Befehl wird die Zielinstanz des Formulars gespeichert und das Formular geschlossen.

• FormsCommand.Refresh: Mit diesem Befehl wird die Abfrage für die Zielinstanz des Formulars wiederholt.

• FormCommands.Cancel: Mit diesem Befehl werden alle Änderungen verworfen und das Formular geschlossen.

Jeder dieser Befehle wird von Ereignissen umschlossen, die vor und nach der Ausführung des Befehls ausgelöst werden.

Vor dem Befehl werden folgende Ereignisse ausgelöst:

• Das Ereignis FormEvents.PreviewSubmit wird vor dem Befehl FormCommand.Submit ausgelöst, während das Ereignis FormEvents.Submitted nach dem Befehl FormCommand.Submit ausgelöst wird.

• Das Ereignis FormEvents.PreviewRefresh wird vor dem Befehl FormCommands.Refresh ausgelöst, während der Befehl FormCommand.Refreshed nach dem Befehl FormCommand.Submit ausgelöst wird.

• Das Ereignis FormEvents.PreviewCancel wird vor dem Befehl FormCommands.Cancel ausgelöst, während das Ereignis FormCommand.Canceled nach dem Befehl FormCommand.Cancel ausgelöst wird.

Mit den Ereignissen vom Typ „preview“ wird ein Objekt vom Typ PreviewFormCommandEventArgs übergeben. Dieses Objekt enthält eine änderbare Eigenschaft vom Typ Cancel , mit der verhindert wird, dass der entsprechende Befehl ausgeführt wird, wenn die Eigenschaft auf truefestgelegt ist.

Mit den nach dem Befehl ausgeführten Ereignissen wird ein Objekt vom Typ FormCommandExecutedEventArgs übergeben. Dieses Objekt enthält eine Eigenschaft vom Typ Result , mit der angegeben wird, ob der Befehl erfolgreich ausgeführt, ob er abgebrochen, oder ob durch ihn ein Fehler verursacht wurde. Wenn durch ihn ein Fehler verursacht wurde, wird von der Eigenschaft Error des Objekts FormCommandExecutedEventArgs auf die Ausnahme mit Informationen zum Fehler verwiesen.

Formularbefehle können sowohl programmgesteuert als auch deklarativ aktiviert, deaktiviert und ausgeführt werden.

Richten Sie zum programmgesteuerten Aktivieren von Formularbefehlen eine CommandBinding zwischen dem Formular und dem entsprechenden Befehl ein.

Im folgenden Beispiel wird eine Befehlsbindung zwischen dem Formular und einem Befehl vom Typ Refresh eingerichtet. Zudem werden zwei Handler für diesen Befehl definiert. Mit dem ersten Handler werden Informationen dazu zurückgegeben, ob der Befehl Refresh ausgeführt werden kann. Der zweite Handler enthält die Implementierung des Befehls 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  
        }  
    }  
  

Handler für Formularbefehle können auch deklarativ definiert werden. Verwenden Sie hierzu ein Objekt vom Typ Rule , von dem ein RoutedCommandTriggerverwendet wird. Mit dem folgenden Codebeispiel wird gezeigt, wie Handler deklarativ definiert werden:

  
    <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>  
  

Siehe auch

WPF-Website (Windows Presentation Foundation) (WindowsClient.NET)
Formulare: Anpassen und Erstellen