Přehled přizpůsobení a vytváření formulářů pomocí nástroje pro tvorbu portálu Service Manager

Formulář je okno, které uživatelům umožňuje interakci s objekty z databáze. Uživatelé mohou pomocí formuláře zobrazit a upravit vlastnosti objektů. Každý formulář je svázán s určitou třídou a zobrazuje informace pouze pro instance cílové třídy. Formulář obsahuje pole. Každé pole je obvykle vázané na konkrétní vlastnost cílové třídy formuláře. Formulář incidentu je například svázaný s objektem incidentu. Formulář incidentu proto zobrazuje informace o objektech incidentů v databázi.

Formulář portálu Service Manager se skládá z implementace formuláře WINDOWS Presentation Foundation (WPF) v sestavení Rozhraní Microsoft .NET Framework a definice formuláře v sadě Management Pack portálu Service Manager. Definice formuláře určuje třídu, kterou formulář představuje, spolu s dalšími vlastnostmi formuláře.

Klíčové koncepty formulářů

Před přizpůsobením formulářů byste měli být obeznámeni s následujícími koncepty formulářů.

Použití formulářů

Pokud je sada Management Pack, která obsahuje definice formulářů, importována do portálu Service Manager, jsou definice formulářů uloženy v databázi. Když později uživatel zahájí úlohu konzoly portálu Service Manager, která vyžaduje zobrazení objektu, musí Service Manager najít formulář pro zobrazení požadovaného objektu. Service Manager přistupuje k databázi a vyhledá formulář definovaný pro daný objekt. Pokud pro objekt není definován žádný formulář, Service Manager vyhledá formulář, který je definován pro nadřazený objekt objektu. Service Manager bude dál prohledávat hierarchii dědičnosti celého objektu, dokud nenajde definovaný formulář.

Obecné formuláře

Pokud Service Manager nemůže najít žádný formulář pro objekt nebo pro žádný z jeho nadřazených objektů, Service Manager dynamicky vytvoří výchozí obecný formulář pro tento objekt. Obecný formulář je systémově vygenerovaný formulář, který stačí pro jednoduché použití formuláře. Obecný formulář představuje rychlý a snadný způsob, jak vytvořit formulář pro objekty bez definic formuláře.

Ve výchozím nastavení obecný formulář zobrazí všechny vlastnosti formuláře v jednoduchém rozložení, které nemůžete změnit. Obecný formulář zobrazí vlastnosti všech nadřazených objektů v hierarchii dědičnosti formuláře a toto chování nemůžete změnit. Vlastní nastavení obecného formuláře jsou omezená. Můžete například zadat vlastnosti, které má obecný formulář zobrazit; Obecný formulář však nelze použít jako základ pro přizpůsobení. Pokud později definujete vlastní formulář pro tento objekt, vlastní formulář přepíše obecný formulář objektu.

Informace o skrytí vlastností v obecném formuláři a dalších způsobech, jak můžete přizpůsobit obecný formulář, naleznete v blogovém příspěvku Přehled infrastruktury formulářů a obecného formuláře.

Kombinované třídy ve formulářích

Někdy potřebujete formulář pro zobrazení informací odvozených z více než jedné třídy. Uděláte to tak, že vytvoříte kombinační třídu a pak svážete pole ve formuláři s kombinační třídou. Další informace o třídách kombinací naleznete v tématu Změny společného schématu nástroje System Center.

Funkční aspekty formuláře

Formulář má následující funkční aspekty:

1. Inicializace

2. Velikost a umístění

3. Aktualizovat

4. Odeslat změny

Tyto aspekty jsou popsány v následujících částech.

Inicializace

Během inicializace se parsuje jazyk XAML (Extensible Application Markup Language) formuláře a všechny ovládací prvky ve formuláři se vytvoří a načtou. Událost Načtení formuláře označuje, kdy byl formulář a všechny obsažené prvky načteny. Operace načítání dat jsou asynchronní. Proto nemusí být cílová instance při vyvolání načtené události k dispozici. Místo toho musí být pro oznámení použita událost DataContextChanged, pokud je pro formulář nastavena cílová instance. Vlastnost PropertyChanged pro Vlastnost DataContext lze použít místo DataContextChanged události.

Doporučujeme použít načtenou událost pro vlastní inicializaci související s ovládacími prvky a pak použít DataContextChanged nebo PropertyChanged události u vlastnosti DataContext pro vlastní inicializaci související s cílovou instancí.

Velikost a umístění

Při zobrazení formuláře v automaticky otevíraných otevíraných oknech se jeho počáteční velikost určuje na základě vlastností Width, Height, MinWidth a MinHeight formuláře. Pokud tyto vlastnosti nejsou pro formulář nastaveny, počáteční velikost formuláře se vypočítá na základě jeho obsahu.

Doporučujeme nastavit tyto vlastnosti následujícím způsobem:

• Nastavte vlastnosti Šířka a Výška formuláře tak, aby explicitně určily ideální velikost. Zvažte nastavení těchto vlastností na hodnotu Auto . Nastaví šířku a výšku formuláře na základě velikosti obsahu.

• Nastavte Vlastnosti MinWidth a MinHeight formuláře tak, aby bylo možné určit nejmenší okno přijatelné pro formulář. Pokud uživatel změní velikost okna na menší velikost, než je zadáno, zobrazí se posuvníky pro posouvání na skrytý obsah formuláře.

Pokud je formulář hostovaný v hostiteli formulářů portálu Service Manager, zachová se poslední použitá velikost a umístění pro následné zobrazení tohoto formuláře stejným uživatelem ve stejné relaci spuštění.

Aktualizovat

Cílová instance formuláře se může změnit v důsledku spuštění příkazu Refresh ve formuláři. Obslužná rutina tohoto příkazu načte nová data z databáze. Při příchodu dat je hodnota vlastnosti DataContext formuláře nastavena na novou cílovou instanci a dataContextChanged událost je vyvolána.

Chcete-li rozlišovat mezi událostí DataContextChanged , která byla vyvolána při prvním načtení formuláře, a událost, která byla vyvolána pro zpracování příkazu Refresh , zkontrolujte vlastnost OldValue argumentů události, které jsou předány s událostí. Tato vlastnost má hodnotu null, pokud byl formulář právě inicializován.

Odeslat změny

Automaticky otevírané okno hostitele formuláře v Service Manageru poskytuje tlačítka pro odesílání změn provedených ve formuláři a pro zavření automaticky otevíraného okna.

Když uživatel vybere tlačítko Použít pro formulář, odešle se cílová instance formuláře do úložiště. Tato operace je synchronní; uživatel proto nemůže formulář upravovat, dokud se operace odeslání nedokončí. Pokud během odesílání formuláře dojde k chybě, zobrazí se chybová zpráva. Formulář zůstane otevřený pro další změny. Doporučujeme, aby uživatelé použili své změny často, aby se zabránilo kolizím, pokud se současně upravuje jiná instance formuláře.

Pokud uživatel vybere tlačítko OK , chování se podobá použití, s tím rozdílem, že pokud je operace odeslání formuláře úspěšná, formulář a okno hostitele se zavře.

Pokud uživatel vybere tlačítko Storno , zobrazí se dialogové okno s dotazem uživatele, aby operaci potvrdil. Uživatel může vybrat Ano a ztratit změny, nebo vybrat Ne a vrátit se do formuláře.

Obecné pokyny a osvědčené postupy pro formuláře

Funkce portálu Service Manager můžete rozšířit přidáním nebo úpravou formulářů. Tato část popisuje několik doporučených postupů pro vytváření a používání formulářů Service Manageru s využitím různých nástrojů a definic formulářů skriptování přímo.

Tato část je primárně zaměřená na partnery a zákazníky, kteří mají zkušenosti s vytvářením vlastních formulářů pomocí Windows Presentation Foundation (WPF) a Microsoft Visual Studio Team System nebo Microsoft Expression Blend.

Obecné pokyny pro vytváření nového formuláře jsou následující.

• Použijte standardní ovládací prvky.
• Postupujte podle obecných pokynů k návrhu formulářů.
• Vyhněte se kódování.
• Zahrňte zpracování výjimek.
• Zvažte přizpůsobení a upgrady formulářů.
• Pojmenujte všechny přizpůsobitelné ovládací prvky.
• Vytvořte vazbu formuláře na zdroje dat.
• Použijte pravidla ověřování infrastruktury formulářů Service Manageru, převáděče hodnot a šablony chyb.
• Použijte příkazy a události infrastruktury formulářů.

Informace o těchto pokynech najdete v následujících částech.

Použití standardních ovládacích prvků

Ovládací prvky používané ve formuláři můžou být:

• Standardní ovládací prvky. To zahrnuje ovládací prvky knihovny .NET, například pole se seznamem a seznam.
• Vlastní ovládací prvky To zahrnuje další ovládací prvky vytvořené autorem formuláře nebo třetí stranou.

Tip

Pokud používáte standardní ovládací prvky všude, kde je to možné, a vyhněte se vytváření vlastních ovládacích prvků, zvýšíte konzistenci s ohledem na uživatelské prostředí formulářů. Pokud musíte vytvořit vlastní ovládací prvek, oddělte vzhled a chování vizuálu a logické chování pomocí šablon ovládacích prvků k definování vzhledu ovládacího prvku. Pokud možno, pro každý motiv Windows by měla existovat samostatná šablona ovládacího prvku.

Postupujte podle obecných pokynů k návrhu formulářů.

Při návrhu formuláře použijte pokyny k veřejnému návrhu, abyste zajistili, že formulář bude uživatelsky přívětivý a že dodržuje běžná paradigmata interakce uživatelů.

Další informace o obecném návrhu Systému Windows naleznete v tématu Pokyny k interakci uživatelského prostředí systému Windows.

Kromě toho:

• Rozdělte informace na více kartách, aby byl formulář jednodušší a čitelnější. Na následujících kartách uveďte nejčastěji používané informace na první kartě a informace o menší důležitosti.
• K rozložení ovládacích prvků ve formuláři použijte panely rozložení. Tím se zajistí správné chování formuláře při změně velikosti a lokalizaci.
• Vyhněte se nastavování vlastností vizuálu jednotlivých ovládacích prvků a místo toho používejte styly. Díky tomu můžete změnit vzhled všech ovládacích prvků v řadě formulářů úpravou stylu a zvýšíte tak konzistentní vzhled napříč souvisejícími formuláři.

Vyhněte se kódování.

Kód za kódem je termín, který popisuje kód, který je spojený s objekty definovanými značkami při kompilaci stránky XAML. Omezte co nejvíce použití kódu ve formuláři. Je vhodnější vložit kód formuláře do samotného ovládacího prvku, protože později je jednodušší tento kód změnit. Místo toho použijte deklarativní funkce, které podporuje infrastruktura formulářů Service Manageru k definování převodů hodnot a ověřovacích pravidel ve formuláři.

Obecně platí, že byste měli omezit použití kódu na situace, kdy není možné poskytovat požadované funkce pomocí deklarativních funkcí XAML s třídami definovanými ve WPF a knihovně infrastruktury formulářů. I potom zvažte přesunutí funkcí implementovaných v kódu do pomocné knihovny a následné odkazování z XAML.

Zahrnutí zpracování výjimek

Ujistěte se, že kód ve formuláři obsahuje zpracování výjimek, aby se formulář mohl načíst jak během fáze návrhu v nástroji pro vytváření, tak v konzole portálu Service Manager za běhu.

Zvažte přizpůsobení a upgrady formulářů.

Při návrhu nového formuláře byste měli zvážit budoucí přizpůsobení a upgrady na tento formulář. Pokud chcete zajistit, aby bylo možné přizpůsobit a upgradovat formulář při zachování přizpůsobení, postupujte podle pokynů a tipů, které jsou uvedené výše v této části, a s následujícími pokyny:

• Při navrhování formuláře zvažte budoucí přizpůsobení a upgrady. Formuláře se budou pravděpodobně vyvíjet v budoucích verzích a je důležité zvážit, jak budou uživatelé moct upgradovat na nové verze formuláře a zároveň zachovat vlastní nastavení původního formuláře. Můžete například poskytnout aktualizovaný formulář, jakmile už uživatelé výrazně investovali do přizpůsobení původního formuláře. Uživatelé očekávají, že jejich přizpůsobení přežije upgrade verze.

• Zadejte jedinečný název každého ovládacího prvku ve formuláři, aby bylo možné použít vlastní nastavení u ovládacích prvků. Přizpůsobení formuláře se ukládá jako sada akcí, které jsou cílem určitého ovládacího prvku nebo sady ovládacích prvků. Na cílový ovládací prvek se odkazuje podle názvu, což je důvod, proč je důležité zachovat názvy ovládacích prvků v různých verzích formuláře. Pokud ovládací prvek nemá název, editor přizpůsobení formuláře vygeneruje název, ale vygenerovaný název se v různých verzích formuláře nezachová.

• Ujistěte se, že názvy ovládacích prvků zůstanou neměnné v různých verzích formuláře. Tím se zajistí, že přizpůsobení daného ovládacího prvku v předchozí verzi lze použít na stejný ovládací prvek v nové verzi formuláře.

• Pokud je to možné, vyhněte se přesunutí ovládacích prvků na jiné místo na stejné kartě při upgradu formuláře. Běžným uživatelským přizpůsobením je přesunutí ovládacích prvků ve formuláři do jiného umístění. Pokud změníte umístění ovládacího prvku v nové verzi formuláře, může se nové umístění ovládacího prvku překrývat s ovládacím prvek, který uživatel přemístil.

• Pokud je to možné, vyhněte se přesouvání ovládacích prvků mezi kartami při navrhování aktualizace existujícího formuláře. Ovládací prvky se identifikují podle názvu i karty, na které jsou umístěné. Přesunutí ovládacího prvku z jedné karty na jinou v nové verzi formuláře může narušit přizpůsobení, která uživatel pro tento ovládací prvek provede, protože přizpůsobení se nepodaří identifikovat cílový ovládací prvek.

• Když aktualizace formuláře obsahuje nové ovládací prvky, zvažte přidání nových ovládacích prvků na novou kartu. To je nejbezpečnější způsob, jak se vyhnout narušení uživatelských přizpůsobení stávajících karet a ovládacích prvků.

• Mějte na paměti, jak jsou ovládací prvky vázány. Ovládací prvky jen pro čtení by měly používat pouze jednosměrné vazby.

Pojmenování všech přizpůsobitelných ovládacích prvků

Ujistěte se, že názvy ovládacích prvků popisují, k jakým datům je ovládací prvek vázán, nebo popište, co ovládací prvek dělá.

Vytvoření vazby formuláře ke zdrojům dat

Hlavním účelem formuláře je vizualizovat jeden objekt z databáze portálu Service Manager. Tento objekt se nazývá cílová instance, která je vždy určena DataContext vlastnost formuláře (který je zděděný z FrameworkElement třídy).

Důležité

Neupravujte vlastnost DataContext formuláře. Hostitelské prostředí formulářů používá tuto vlastnost k identifikaci cílové instance formuláře.

V datovém modelu Service Manageru je cílová instance reprezentována jako BindableDataItem objekt. Tato třída agreguje základní objekt sady SDK (Software Development Kit) a zveřejňuje své vlastnosti prostřednictvím indexeru, který přebírá název vlastnosti jako parametr.

BindableDataItem třída také implementuje ICustomTypeDescriptor, což umožňuje použít BindableDataItem třídy jako zdroj dat pro vazbu WPF. Následuje příklad vazby vlastnosti cílové instance na text vlastnost Text ovládacího prvku TextBox :

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

Není nutné zadat zdroj vazby, protože cílové instance jsou nastaveny jako DataContext formuláře, který slouží jako výchozí Zdroj pro všechny ovládací prvky ve formuláři.

Ovládací prvky ve formuláři mohou být vázány na jiné zdroje dat než cílová instance a knihovna infrastruktury formulářů obsahuje mnoho ovládacích prvků, které provádějí vazbu implicitně. Například ovládací prvek pro výběr instance je vázán na zdroj dat, který poskytuje kolekci instancí, které si můžete vybrat. Je také možné definovat další zdroje dat deklarativní pomocí ObjectDataProvider a XmlDataProvider třídy.

Infrastruktura formulářů považuje cílovou instanci za jediný zdroj dat pro čtení a zápis ve formuláři. Proto implementace příkazu Submit uloží pouze změny provedené v cílové instanci. Ostatní zdroje dat pro formulář jsou považovány za jen pro čtení.

Použití pravidel ověřování infrastruktury formulářů Service Manageru, převodů hodnot a šablon chyb

Doporučujeme použít ověřovací pravidla infrastruktury formulářů ve formulářích k určení vstupu dat, který není platný. Infrastruktura vazeb WPF podporuje ověřování vlastností ovládacích prvků, které jsou vázané na zdroj dat s jednosměrnými nebo obousměrnými vazbami. Objekt vazby má kolekci ValidationRules , která může obsahovat libovolný počet ValidationRule objekty. Při každém nasdílení dat z ovládacího prvku do zdroje dat jsou volány objekty ValidationRule k ověření hodnoty.

Knihovna infrastruktury formulářů obsahuje mnoho ověřovacích pravidel, která zpracovávají nejběžnější případy. Infrastruktura formulářů využívá ověřovací pravidla k určení, zda lze obsah formuláře odeslat k uložení. Tlačítko Odeslat formuláře může být například zakázané, pokud je ve formuláři ovládací prvek s chybou ověření.

Doporučujeme použít vlastní šablonu chyby, která je součástí knihovny infrastruktury formulářů. Pokud má ovládací prvek chybu ověření, zobrazí se ve výchozím nastavení červené ohraničení kolem něj. WPF umožňuje definovat vlastní indikátor chyby prostřednictvím Validation.ErrorTemplate vlastnost, kterou lze nastavit na libovolném ovládacím prvku. Knihovna infrastruktury formulářů Service Manageru obsahuje vlastní šablonu chyb, která místo červeného ohraničení WPF zobrazuje ikonu chyby. Kromě toho, když myš odkazuje na ikonu chyby, zobrazí se popis s chybovou zprávou. Chybová zpráva by měla znamenat důvod selhání ověření dat v ovládacím prvku.

Následující příklad ukazuje, jak odkazovat na šablonu chyby v XAML:

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

Pokud předdefinovaná ověřovací pravidla neposkytují požadovanou ověřovací logiku, doporučujeme vytvořit vlastní ověřovací pravidla, která budou představovat tuto logiku. To umožní, aby standardní a vlastní logika ověřování spoluexistovat v rámci společného mechanismu ověřování.

Pokud mechanismus ověřovacích pravidel není vhodný pro konkrétní scénář, měli byste místo toho zpracovat FormEvents.PreviewSubmitEvent a spustit ověření odsud.

Následující příklad kódu obsahuje příklad vzoru, který můžete použít ke spuštění vlastního ověření:

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
}

Použití příkazů a událostí infrastruktury formulářů

Infrastruktura formulářů zveřejňuje mnoho příkazů, které lze spustit ve formuláři. Mezi tyto příkazy patří:

• FormsCommand.Submit, která uloží cílovou instanci formuláře.

• FormsCommand.SubmitAndClose, která uloží cílovou instanci formuláře a zavře formulář.

• FormsCommand.Refresh, který opakuje dotaz pro cílovou instanci formuláře.

• FormCommands.Cancel, která zahodí všechny změny a zavře formulář.

Každý z těchto příkazů je závorkami událostmi, které jsou vyvolány před a po spuštění příkazu.

Před příkazem jsou vyvolány následující události:

• Událost FormEvents.PreviewSubmit je vyvolána před příkazem FormCommand.Submit a událost FormEvents.Submit je vyvolána po příkazu FormCommand.Submit.

• Událost FormEvents.PreviewRefresh je vyvolána před příkazem FormCommands.Refresh a příkaz FormCommand.Refreshed je vyvolán po příkazu FormCommand.Submit .

• Událost FormEvents.PreviewCancel je vyvolána před příkazem FormCommands.Cancel a událost FormCommand.Canceled je vyvolána po příkazu FormCommand.Cancel .

Události náhledu předávají objekt PreviewFormCommandEventArgs . Tento objekt obsahuje proměnlivou vlastnost Cancel , která zabrání spuštění odpovídajícího příkazu, pokud je vlastnost nastavena na hodnotu true.

Události po příkazu předávají FormCommandExecutedEventArgs objektu. Tento objekt obsahuje vlastnost Result , která označuje, zda spuštění příkazu bylo úspěšné, bylo zrušeno nebo způsobilo chybu. V případě chyby, Error vlastnost FormCommandExecutedEventArgs objekt odkazuje na výjimku, která poskytuje informace o chybě.

Příkazy formuláře je možné povolit, zakázat a spouštět programově i deklarativním způsobem.

Pokud chcete příkazy formuláře povolit programově, nastavte vazbu commandBinding mezi formulářem a souvisejícím příkazem.

V následujícím příkladu je vazba příkazu vytvořena mezi formulářem a příkazem Refresh a pro tento příkaz jsou definovány dva obslužné rutiny. První obslužná rutina vrátí, jestli se příkaz Refresh může spustit nebo ne, a druhá obslužná rutina ve skutečnosti obsahuje implementaci příkazu 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
        }
    }

Obslužné rutiny pro příkazy formulářů můžete definovat také deklarativním způsobem. Můžete to provést pomocí objektu Rule , který používá RoutedCommandTrigger. Následující příklad kódu ukazuje, jak deklarativně definovat obslužné rutiny:

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

Další kroky

• Přizpůsobte a vytvořte formuláře pomocí nástroje pro tvorbu portálu Service Manager.
• Přizpůsobte výchozí formulář incidentu pro ukázkový scénář nástroje pro tvorbu.