Űrlapok: Általános irányelvek és bevált gyakorlatok

Közzétéve: 2016. július

Hatókör: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

A System Center 2012 – Service Manager funkcióit űrlapok hozzáadásával vagy módosításával bővítheti. Ez a témakör a Service Manager űrlapjainak létrehozásával és használatával kapcsolatos bevált gyakorlatokat ismerteti, különféle eszközök használata révén, illetve az űrlap-definíciók közvetlen megadásával.

Ez a témakör elsősorban azoknak a partnereinknek és ügyfeleinknek szól, akiknek vagy gyakorlatuk saját egyéni űrlapjaik létrehozásában a Windows megjelenítési alaprendszer (WPF), a Microsoft Visual Studio Team System vagy a Microsoft Expression Blend használatával.

Az új űrlapok létrehozásával kapcsolatos általános irányelvek az alábbiak.

• Használjon szabványos vezérlőket.

• Kövesse az általános űrlaptervezési irányelveket.

• Kerülje a háttérkód használatát.

• Használjon kivételkezelést.

• Vegye figyelembe az űrlapok testreszabási és frissítési lehetőségeit.

• Nevezze el az összes testreszabható vezérlőt.

• Kapcsolja az űrlapot adatforrásokhoz.

• Használja a Service Manager űrlap-infrastruktúrájának ellenőrzési szabályait, értékkonvertálóit és hibasablonjait.

• Használja az űrlap-infrastruktúra parancsait és eseményeit.

Az irányelvekkel kapcsolatos további információkért lásd a következő részeket.

Használjon szabványos vezérlőket

Az űrlapokon használt vezérlők a következő típusúak lehetnek:

• Szabványos vezérlők. Ilyenek a .NET könyvtár vezérlői, például a kombinált lista és a listamező.

• Egyéni vezérlők. Ilyenek azok a további vezérlők, amelyeket az űrlap készítője vagy harmadik fél hoz létre.

Tipp

Ha szabványos vezérlőket használ és lehetőség szerint kerüli az egyéni vezérlők létrehozását, az űrlapokkal kapcsolatos felhasználói élmény egységesebb lesz. Ha mindenképpen szükség van egyéni vezérlő létrehozására, annak vizuális megjelenését és viselkedését, valamint a logikai viselkedést különítse el úgy, hogy vezérlősablonok használatával definiálja a vezérlő megjelenését. Ideális esetben minden Windows-témához külön vezérlősablon tartozik.

Kövesse az általános űrlaptervezési irányelveket

Amikor űrlapot tervez, használja a nyilvános tervezési irányelveket annak érdekében, hogy az űrlap felhasználóbarát legyen és igazodjon a felhasználói igényekhez.

További információk a Windows általános tervezési irányelveiről: Windows User Experience Interaction Guidelines (Windows felhasználói élmény: interakciós irányelvek).

Továbbá:

• Az információkat ossza szét több lapra, hogy az űrlap egyszerűbb és könnyebben olvasható legyen. A leggyakrabban használt információkat az első lapra helyezze, a kevésbé fontosakat pedig a további lapokra.

• Használjon elrendezési paneleket az űrlap vezérlőinek elrendezéséhez. Ezzel biztosíthatja, hogy az űrlap átméretezéskor és honosítás esetén is megfelelően viselkedjen.

• Kerülje a vezérlők megjelenítési tulajdonságainak külön-külön történő beállítását, ehelyett használjon stílusokat. Így a stílus módosításával több űrlapon egyszerre módosíthatja a vezérlők küllemét, ami egységes megjelenést tesz lehetővé az egymáshoz kapcsolódó űrlapokon.

Kerülje a háttérkód használatát

A háttérkód olyan kód, amely jelölőnyelvvel definiált objektumokhoz kapcsolódik az XAML-oldal jelölőnyelvi fordításakor. Az űrlapon minél kevesebb háttérkódot használjon. Érdemes az űrlap kódját magába a vezérlőbe ágyazni, mert így később könnyebben módosítható. Az űrlap értékkonverzióinak és ellenőrzési szabályainak definiálásához használja inkább a Service Manager űrlap-infrastruktúra deklarációs módszereit.

Általános irányelvként elmondható, hogy tanácsos a háttérkód használatát olyan helyzetekre korlátozni, amikor a XAML deklarációs módszereivel, a WPF-ben definiált osztályokkal vagy az űrlap-infrastruktúra könyvtárával nem lehet biztosítani a kívánt működést. Még ilyen esetben is érdemes a háttérkóddal megvalósított funkciókat egy segédkódtárba helyezni, majd az XAML-ből hivatkozni rá.

Használjon kivételkezelést

Ügyeljen arra, hogy az űrlap kódja tartalmazzon kivételkezelést, hogy az űrlap betölthető legyen mind a tervezési fázisban az Authoring Tool eszközbe, mind a futtatáskor a Service Manager konzol eszközbe.

Vegye figyelembe az űrlapok testreszabási és frissítési lehetőségeit

Amikor új űrlapot tervez, gondoljon az űrlap jövőbeli testreszabási és frissítési lehetőségeire is. Ahhoz, hogy az űrlap testreszabható és frissíthető legyen, miközben megőrzi a korábbi testreszabásokat is, kövesse az ebben a részben korábban leírt irányelveket és tippeket, valamint a következő irányelveket:

• Az űrlap tervezésekor már jó előre vegye figyelembe a jövőbeli testreszabásokat és frissítéseket. Az űrlapok a későbbi verziókban valószínűleg fejlettebbé válnak, ezért fontos megtervezni, hogyan frissíthetik majd a felhasználók az űrlapot az új verziókra úgy, hogy közben az eredeti űrlapon végzett testreszabásokat se veszítsék el. Képzelje el például, hogy frissített űrlapot tesz elérhetővé azután, hogy a felhasználók már rengeteg energiát fordítottak az eredeti űrlap testreszabására. A felhasználók ilyenkor azt várják el, hogy a testreszabások a verziófrissítés során megőrződjenek.

• Adjon egyedi nevet az űrlap minden vezérlőjének, hogy a testreszabások a vezérlőkre is alkalmazhatók legyenek. Az űrlapok testreszabásai műveletekként tárolódnak, amelyek egy adott vezérlőt vagy vezérlőcsoportot céloznak meg. Az érintett vezérlőre történő hivatkozás a név alapján történik, ezért fontos, hogy a vezérlőnevek az űrlap különböző verzióiban ne változzanak. Ha egy vezérlő nem rendelkezik névvel, az Űrlaptestreszabás-szerkesztő létrehoz hozzá egy nevet, de az így létrehozott név nem lesz azonos az űrlap különböző verzióiban.

• Gondoskodjon arról, hogy a vezérlőnevek azonosak maradjanak az űrlap különböző verzióiban. Így az adott vezérlőn egy korábbi verzióban végzett testreszabás az űrlap új verziójában is alkalmazható lesz ugyanarra a vezérlőre.

• Ha lehetséges, az űrlap frissítésekor kerülje a vezérlők más helyre történő áthelyezését ugyanazon a lapon belül. A testreszabás során a felhasználók gyakran helyezik át az űrlap vezérlőit más helyre. Ha az űrlap új verziójában módosítja egy vezérlő helyét, fennáll a kockázata annak, hogy az új helyre került vezérlő átfedésben lesz egy olyan vezérlővel, amelyet a felhasználó helyezett át.

• Ha lehetséges, a meglévő űrlap frissítésének tervezésekor kerülje a vezérlők más lapra történő áthelyezését. A vezérlők azonosítása a nevük, valamint az őket tartalmazó lap alapján történik. Ha az űrlap új verziójában egy vezérlőt másik lapra helyez át, azzal érvénytelenné válhatnak a felhasználó által az adott vezérlőn végzett testreszabások, mert a vezérlőt nem lehet azonosítani.

• Ha egy űrlap frissítése új vezérlőket tartalmaz, érdemes azokat új laphoz adni. Ez a legbiztonságosabb eljárás, mivel így elkerülhető, hogy a frissítés ütközzön a meglévő lapokon és vezérlőkön végzett felhasználói testreszabásokkal.

• Ügyeljen a vezérlők kötésére. Az írásvédett vezérlőknek csak egyirányú kötéseket szabad használniuk.

Nevezze el az összes testreszabható vezérlőt

Ügyeljen arra, hogy a vezérlőnevek írják le, milyen adatokhoz van kötve a vezérlő, illetve mi a funkciója.

Kapcsolja az űrlapot adatforrásokhoz

Az űrlap fő célja, hogy megjelenítsen egy objektumot a Service Manager adatbázisból. Ez az objektum a target instance, amelyet mindig az űrlap DataContext tulajdonsága ad meg (amely a FrameworkElement osztályból öröklődik).

Fontos!
Ne módosítsa az űrlap DataContext tulajdonságát. Az űrlap futtatókörnyezete ezt a tulajdonságot használja az űrlap célpéldányának azonosításához.

A Service Manager adatmodelljében a célpéldány BindableDataItem objektumként van leképezve. Ez az osztály összegzi az alapul szolgáló SDK-objektumot, és egy olyan indexelőn keresztül teszi elérhetővé annak tulajdonságait, amely tulajdonságnevet fogad paraméterként.

A BindableDataItem osztály emellett az ICustomTypeDescriptor elemet is implementálja, ami lehetővé teszi a BindableDataItem osztály WPF-kötési adatforrásként történő használatát. A következő példa egy célpéldány-tulajdonság kötését mutatja be a TextBox vezérlő Text tulajdonságához:

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

A kötés Source elemét nem kell megadni, mert a célpéldányok az űrlap DataContext elemeként vannak beállítva, amely az űrlap összes vezérlőjének alapértelmezett Source elemeként szolgál.

Az űrlap elemei a célpéldányon kívül más adatforrásokhoz is köthetők, és az űrlap-infrastruktúra könyvtára számos olyan vezérlőt tartalmaz, amely implicit módon végrehajtja a kötést. A példányválasztó vezérlő például az adatforráshoz van kötve, amely a választható példányok gyűjteményét biztosítja. Emellett további adatforrások is definiálhatók deklaratív módon az ObjectDataProvider és XmlDataProvider osztályok használatával.

Az űrlap-infrastruktúra a célpéldányt tekinti az egyetlen olvasható és írható adatforrásnak az űrlapon. Ezért a Submit parancs hatására csak azok a változások tárolódnak, amelyeket a célpéldányon végeznek. Az űrlap egyéb adatforrásait a rendszer írásvédettként kezeli.

Használja a Service Manager űrlap-infrastruktúrájának ellenőrzési szabályait, értékkonvertálóit és hibasablonjait

Az érvénytelen adatbevitel azonosításához javasolt az űrlap-infrastruktúra ellenőrzési szabályait használni. A WPF kötési infrastruktúra támogatja az olyan vezérlőtulajdonságok ellenőrzését, amelyek egy- vagy kétirányú kötéssel vannak az adatforráshoz kapcsolva. A kötési objektum rendelkezik egy ValidationRules gyűjteménnyel, amely tetszés szerinti számú ValidationRule objektumot tartalmazhat. Amikor az adatok a vezérlőről az adatforrásra kerülnek, a ValidationRule objektumok meghívásával sor kerül az érték ellenőrzésére.

Az űrlap-infrastruktúra kódtára számos ellenőrzési szabályt tartalmaz, amelyek a leggyakrabban előforduló eseteket kezelik. Az űrlap-infrastruktúra az ellenőrzési szabályok használatával határozza meg, hogy az űrlap tartalma benyújtható-e tárolásra. Az űrlap Küldés gombja például letiltható, ha az űrlapon ellenőrzési hibát tartalmazó vezérlő van.

Javasoljuk, hogy használja az űrlap-infrastruktúra kódtárához tartozó egyéni hibasablont. Ha egy vezérlő ellenőrzési hibát tartalmaz, alapértelmezés szerint piros szegéllyel jelenik meg. A WPF lehetővé teszi, hogy a Validation.ErrorTemplate tulajdonsággal egyéni hibajelzőt hozzon létre, amely bármelyik vezérlőre alkalmazható. A Service Manager űrlap-infrastruktúrájának kódtára tartalmaz egy egyéni hibasablont, amely a WPF piros szegélye helyett hibaikont jelenít meg. Emellett ha az egérrel a hibaikonra mutatnak, elemleírás jelenik meg a hibaüzenettel. A hibaüzenetnek meg kell határoznia, miért nem felelt meg a vezérlőben megadott adat az ellenőrzésnek.

A következő példa azt mutatja be, hogyan hivatkozható a hibasablon az XAML-ben:

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

Ha a beépített ellenőrzési szabályok nem biztosítják a szükséges ellenőrzési logikát, javasolt a kívánt logikát megvalósító egyéni ellenőrzési szabályokat létrehozni. Ez lehetővé teszi a normál és egyéni ellenőrzési logika párhuzamos működését a közös ellenőrzési mechanizmusban.

Ha az ellenőrzési szabályok mechanizmusa nem felel meg az adott célra, használja helyette a FormEvents.PreviewSubmitEvent eseményt, és onnan futtassa az ellenőrzést.

A következő példakód az egyéni ellenőrzés futtatását mutatja be:

  
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  
}  
  

Használja az űrlap-infrastruktúra parancsait és eseményeit

Az űrlap-infrastruktúra számos, az űrlapon futtatható parancsot tesz elérhetővé. Ezek a parancsok a következők:

• FormsCommand.Submit – menti az űrlap célpéldányát.

• FormsCommand.SubmitAndClose – menti az űrlap célpéldányát és bezárja az űrlapot.

• FormsCommand.Refresh – megismétli a lekérdezést az űrlap célpéldányához.

• FormCommands.Cancel – elveti az összes változást és bezárja az űrlapot.

A parancsok mindegyike eseményekbe van ágyazva, amelyek a parancs futása előtt és után aktiválódnak.

A parancs előtt a következő események aktiválódnak:

• A FormEvents.PreviewSubmit esemény a FormCommand.Submit parancs előtt aktiválódik, a FormEvents.Submitted esemény pedig a FormCommand.Submit parancs után.

• A FormEvents.PreviewRefresh esemény a FormCommands.Refresh parancs előtt aktiválódik, a FormCommand.Refreshed pedig a FormCommand.Submit parancs után.

• A FormEvents.PreviewCancel esemény a FormCommands.Cancel parancs előtt aktiválódik, a FormCommand.Canceled esemény pedig a FormCommand.Cancel parancs után.

Az előnézeti események egy PreviewFormCommandEventArgs objektumot adnak át. Ez az objektum tartalmaz egy módosítható Cancel tulajdonságot, amely megakadályozza a megfelelő parancs futtatását, ha a tulajdonság true értékre van állítva.

A parancsot követő események egy FormCommandExecutedEventArgs objektumot adnak át. Ez az objektum tartalmaz egy Result tulajdonságot, amely jelzi a parancs futtatásának eredményét (sikeres, megszakítva vagy hiba). Hiba esetén a FormCommandExecutedEventArgs objektum Error tulajdonsága arra a kivételre hivatkozik, amely információt nyújt a hibáról.

Az űrlapparancsok programozott és deklaratív módon is engedélyezhetők, letilthatók és futtathatók.

Az űrlapparancsok programozott módon történő engedélyezéséhez hozzon létre CommandBinding kapcsolatot az űrlap és a kérdéses parancs között.

A következő példa parancskötést hoz létre az űrlap és egy Refresh parancs között, majd két kezelőt definiál a parancshoz. Az első kezelő azt határozza meg, hogy a Refresh parancs futhat-e, a második pedig a Refresh parancs implementációját tartalmazza:

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

Az űrlapparancsok kezelőit deklaratív módon is definiálhatja. Ezt egy Rule objektum segítségével teheti meg, amely RoutedCommandTrigger eseményindítót használ. A következő példakód a kezelők deklaratív definiálását mutatja be:

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

Windows Presentation Foundation (WPF) webhely (WindowsClient.NET)
Űrlapok: Testreszabás és szerzői műveletek