Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Ett XAML-namnområde är ett begrepp som utökar definitionen av ett XML-namnområde. På samma sätt som i ett XML-namnområde kan du definiera ett XAML-namnområde med hjälp av ett xmlns-attribut i markering. XAML-namnområden representeras också i XAML-nodströmmen och andra XAML Services-API:er. Det här avsnittet definierar begreppet XAML-namnområde och beskriver hur XAML-namnområden kan definieras och används av XAML-schemakontexter och andra aspekter av .NET XAML Services.
XML-namnområde och XAML-namnområde
Ett XAML-namnområde är ett specialiserat XML-namnområde, precis som XAML är en specialiserad form av XML och använder det grundläggande XML-formuläret för dess markering. I markering deklarerar du ett XAML-namnområde och dess mappning via ett xmlns attribut som tillämpas på ett element.
xmlns-deklarationen kan göras till samma element som XAML-namnområdet deklareras i. En XAML-namnområdesdeklaration som gjorts till ett element är giltig för det elementet, alla attribut för det elementet och alla underordnade elementet. Attribut kan använda ett XAML-namnområde som inte är samma som elementet som innehåller attributet, så länge själva attributnamnet refererar till prefixet som en del av dess attributnamn i markering.
Skillnaden mellan ett XAML-namnområde och ett XML-namnområde är att ett XML-namnområde kan användas för att referera till ett schema eller helt enkelt för att särskilja entiteter. För XAML måste de typer och medlemmar som används i XAML i slutändan matchas mot bakgrundstyper, och XML-schemabegrepp gäller inte bra för den här funktionen. XAML-namnområdet innehåller information som XAML-schemakontexten måste ha tillgänglig för att kunna utföra den här typen av mappning.
XAML-namnområdeskomponenter
XAML-namnområdesdefinitionen har två komponenter: ett prefix och en identifierare. Var och en av dessa komponenter finns när ett XAML-namnområde deklareras i markering eller definieras i XAML-typsystemet.
Prefixet kan vara valfri sträng som tillåts av W3C-namnområden i XML 1.0-specifikationen. Enligt konventionen är prefixen vanligtvis korta strängar, eftersom prefixet upprepas många gånger i en typisk markeringsfil. Vissa XAML-namnområden som är avsedda att användas i flera XAML-implementeringar använder särskilda konventionella prefix. XAML-språk-XAML-namnområdet mappas till exempel vanligtvis med prefixet x. Du kan definiera ett XAML-standardnamnområde, där prefixet inte anges i definitionen men representeras som en tom sträng om det definieras eller efterfrågas by.NET XAML Services API. Vanligtvis väljs XAML-standardnamnområdet avsiktligt för att främja en maximerad mängd prefix-utelämnande markering av en XAML-implementeringsteknik och dess scenarier och vokabulärer.
Identifieraren kan vara vilken sträng som helst som tillåts av W3C-namnområden i XML 1.0-specifikationen. Enligt konventionen anges identifierare för xml-namnområden eller XAML-namnområden ofta i URI-form, vanligtvis som en protokollkvalificerad absolut URI. Ofta är versionsinformation som definierar ett visst XAML-ordförråd underförstått som en del av sökvägssträngen. XAML-namnområden lägger till ytterligare en ID-konvention utöver XML-URI-konventionen. För XAML-namnområden kommunicerar identifieraren information som behövs av en XAML-schemakontext för att matcha de typer som anges som element under XAML-namnområdet eller för att matcha attribut till medlemmar.
I syfte att kommunicera information till en XAML-schemakontext kan identifieraren för ett XAML-namnområde fortfarande vara i URI-form. Men i det här fallet deklareras URI:n också som en matchande identifierare i en viss sammansättning eller lista över sammansättningar. Detta görs i sammansättningar genom att tilldela sammansättningen med XmlnsDefinitionAttribute. Den här metoden för att identifiera XAML-namnområdet och stödja ett CLR-baserat typmatchningsbeteende i den tilldelade sammansättningen stöds av standard-XAML-schemakontexten i .NET XAML Services. Mer allmänt kan den här konventionen användas för fall där XAML-schemakontexten innehåller CLR eller baseras på standardkontexten för XAML-schema, vilket är nödvändigt för att läsa CLR-attribut från CLR-sammansättningar.
XAML-namnområden kan också identifieras av en konvention som kommunicerar ett CLR-namnområde och en typdefinierande sammansättning. Den här konventionen används i fall där det inte finns någon XmlnsDefinitionAttribute attribution i de sammansättningar som innehåller typer. Den här konventionen är potentiellt mer komplex än URI-konventionen och har också potential för tvetydighet och duplicering, eftersom det finns flera sätt att referera till en sammansättning.
Den mest grundläggande formen av en identifierare som använder CLR-namnområdet och sammansättningskonventionen är följande:
clr-namespace:clrnsName; assembly=assemblyShortName
clr-namespace: och ; assembly= är literalkomponenter i syntaxen.
clrnsName är strängnamnet som identifierar ett CLR-namnområde. Det här strängnamnet innehåller alla interna punkttecken (.) som ger tips om CLR-namnområdet och dess relation till andra CLR-namnområden.
assemblyShortName är strängnamnet för en sammansättning som definierar typer som är användbara i XAML. De typer som ska nås via det deklarerade XAML-namnområdet förväntas definieras av sammansättningen och deklareras inom CLR-namnområdet som anges av clrnsName. Det här strängnamnet parallellar vanligtvis informationen enligt AssemblyName.Name.
En mer fullständig definition av CLR-namnområdet och sammansättningskonventionen är följande:
clr-namespace:clrnsName; assembly=assemblyName
assemblyName representerar alla strängar som är lagliga som en Assembly.Load(String) indata. Den här strängen kan innehålla information om kultur, offentlig nyckel eller version (definitioner av dessa begrepp definieras i referensavsnittet för Assembly). COFF-format och -bevis (som används av andra överlagringar av Load) är inte relevanta för XAML-monteringsinläsning. all inläsningsinformation måste visas som en sträng.
Att ange en offentlig nyckel för sammansättningen är en användbar teknik för XAML-säkerhet, eller för att ta bort eventuell tvetydighet som kan finnas om sammansättningar läses in med enkelt namn eller redan finns i en cache- eller programdomän. Mer information finns i XAML-säkerhetsöverväganden.
XAML-namnområdesdeklarationer i XAML Services-API:et
I XAML Services-API:et representeras en XAML-namnområdesdeklaration av ett NamespaceDeclaration-objekt. Om du deklarerar ett XAML-namnområde i kod anropar du NamespaceDeclaration(String, String) konstruktorn. Parametrarna ns och prefix anges som strängar, och indata för dessa parametrar motsvarar definitionen av XAML-namnområdesidentifierare och XAML-namnområdesprefix som angavs tidigare i det här avsnittet.
Om du undersöker XAML-namnområdesinformation som en del av en XAML-nodström eller via annan åtkomst till XAML-typsystemet rapporterar NamespaceDeclaration.Namespace XAML-namnområdesidentifieraren och NamespaceDeclaration.Prefix rapporterar XAML-namnområdesprefixet.
I en XAML-nodström kan XAML-namnområdesinformationen visas som en XAML-nod som föregår den entitet som den gäller för. Detta inkluderar fall där XAML-namnområdesinformationen föregår StartObject för XAML-rotelementet. Mer information finns i Understanding XAML Node Stream Structures and Concepts.
I många scenarier som använder .NET XAML Services API förväntas minst en XAML-namnområdesdeklaration finnas, och deklarationen måste antingen innehålla eller referera till information som krävs av en XAML-schemakontext. XAML-namnrymderna måste antingen ange sammansättningar som ska läsas in eller hjälpa till att matcha specifika typer inom namnområden och sammansättningar som redan har lästs in eller som är kända av XAML-schemakontexten.
För att kunna generera en XAML-nodström måste XAML-typinformation vara tillgänglig via XAML-schemakontexten. Det går inte att fastställa XAML-typinformationen utan att först fastställa det relevanta XAML-namnområdet för varje nod som ska skapas. I det här läget har inga instanser av typer skapats ännu, men XAML-schemakontexten kan behöva söka efter information från den definierande sammansättnings- och bakgrundstypen. Om du till exempel vill bearbeta markeringskontexten <Party><PartyFavor/></Party>måste XAML-schemakontexten kunna fastställa namnet och typen av ContentProperty för Partyoch därför också känna till XAML-namnområdesinformationen för Party och PartyFavor. När det gäller XAML-standardschemakontexten rapporterar statisk reflektion mycket av systeminformationen av XAML-typ som behövs för att generera XAML-typnoder i nodströmmen.
För att generera ett objektdiagram från en XAML-nodström måste XAML-namnområdesdeklarationer finnas för varje XAML-prefix som används i den ursprungliga markeringen och registreras i XAML-nodströmmen. I det här läget skapas instanser och sant beteende för typmappning inträffar.
Om du behöver fylla i XAML-namnområdesinformation i förväg, i de fall där XAML-namnområdet som du tänker använda XAML-schemakontexten inte har definierats i pålägget, är en teknik som du kan använda för att deklarera XML-namnområdesdeklarationer i XmlParserContext för en XmlReader. Använd sedan den XmlReader som indata för en XAML-läsarkonstruktor eller XamlServices.Load(XmlReader).
Två andra API:er som är relevanta för XAML-namnområdeshantering i .NET XAML Services är attributen XmlnsDefinitionAttribute och XmlnsPrefixAttribute. Dessa attribut gäller för sammansättningar. XmlnsDefinitionAttribute används av en XAML-schemakontext för att tolka alla XAML-namnområdesdeklarationer som innehåller en URI. XmlnsPrefixAttribute används av verktyg som genererar XAML så att ett visst XAML-namnområde kan serialiseras med ett förutsägbart prefix. Mer information finns i XAML-Related CLR-attribut för anpassade typer och bibliotek.
Se även
.NET Desktop feedback