Dela via

XAML-namnområden och namnområdesmappning

I det här avsnittet beskrivs XML/XAML-namnområdesmappningar (xmlns) som finns i rotelementet i de flesta XAML-filer. Den beskriver också hur du skapar liknande mappningar för anpassade typer och sammansättningar.

Så här relaterar XAML-namnområden till koddefinitioner och typbibliotek

Både i dess allmänna syfte och för programmet till Windows Runtime-appprogrammering används XAML för att deklarera objekt, egenskaper för dessa objekt och objektegenskapsrelationer uttryckta som hierarkier. Objekten som du deklarerar i XAML backas upp av typbibliotek eller andra representationer som definieras av andra programmeringstekniker och språk. Dessa bibliotek kan vara:

  • Den inbyggda uppsättningen objekt för Windows Runtime. Det här är en fast uppsättning objekt och vid åtkomst till dessa objekt från XAML används intern typmappning och aktiveringslogik.
  • Distribuerade bibliotek som tillhandahålls antingen av Microsoft eller av tredje part.
  • Bibliotek som definierar en tredjepartskontroll som din app integrerar och som ditt paket distribuerar.
  • Ditt eget bibliotek, som är en del av projektet och som innehåller några eller alla användarkoddefinitioner.

Information om bakgrundstyp är associerad med specifika XAML-namnområdesdefinitioner. XAML-ramverk som Windows Runtime kan aggregera flera sammansättningar och flera kodnamnområden för att mappa till ett enda XAML-namnområde. Detta möjliggör begreppet XAML-vokabulär som omfattar ett större programmeringsramverk eller en större teknik. Ett XAML-ordförråd kan vara ganska omfattande, till exempel utgör de flesta av de XAML-dokument som dokumenteras för Windows Runtime-appar i den här referensen en enda XAML-vokabulär. En XAML-vokabulär är också utökningsbar: du utökar den genom att lägga till typer i de bakomliggande koddefinitionerna och se till att inkludera typerna i kods namnrymder som redan används som mappade namnrymder för XAML-vokabulären.

En XAML-processor kan söka efter typer och medlemmar från de stödsammansättningar som är associerade med XAML-namnområdet när den skapar en körningsobjektrepresentation. Därför är XAML användbart som ett sätt att formalisera och utbyta definitioner av objektkonstruktionsbeteende och varför XAML används som en UI-definitionsteknik för en Windows Runtime-app.

XAML-namnområden i typisk XAML-markeringsanvändning

En XAML-fil deklarerar nästan alltid ett XAML-standardnamnområde i rotelementet. XAML-standardnamnområdet definierar vilka element du kan deklarera utan att kvalificera dem med ett prefix. Om du till exempel deklarerar ett element <Balloon />förväntar sig en XAML-parser att elementet Balloon finns och är giltigt i XAML-standardnamnområdet. Om Balloon däremot inte finns i det definierade XAML-standardnamnområdet måste du i stället kvalificera elementnamnet med ett prefix, till exempel <party:Balloon />. Prefixet anger att elementet finns i ett annat XAML-namnområde än standardnamnområdet, och du måste mappa ett XAML-namnområde till prefixparten innan du kan använda det här elementet. XAML-namnrymder gäller för det specifika element som de deklareras för, och även för alla element som ingår i elementet i XAML-strukturen. Därför deklareras XAML-namnområden nästan alltid på rotelement i en XAML-fil för att dra nytta av det här arvet.

Standard- och XAML-språks XAML-namnområdesdeklarationer

I rotelementet i de flesta XAML-filer finns det två xmlns-deklarationer . Den första deklarationen mappar ett XAML-namnområde som standard: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Det här är samma XAML-namnområdesidentifierare som används i flera föregående Microsoft-tekniker som också använder XAML som UI-definitionsmarkeringsformat. Användningen av samma identifierare är avsiktlig och är användbar när du migrerar tidigare definierat användargränssnitt till en Windows Runtime-app med C++, C#eller Visual Basic.

Den andra deklarationen mappar ett separat XAML-namnområde för de XAML-definierade språkelementen och mappar det (vanligtvis) till prefixet "x:": xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Det här xmlns-värdet , och prefixet "x:" som det mappas till, är också identiskt med de definitioner som används i flera föregående Microsoft-tekniker som använder XAML.

Relationen mellan dessa deklarationer är att XAML är en språkdefinition, och Windows Runtime är en implementering som använder XAML som språk och definierar ett specifikt ordförråd där dess typer refereras till i XAML.

XAML-språket anger vissa språkelement, och vart och ett av dessa bör vara tillgängligt via XAML-processorimplementeringar som arbetar mot XAML-namnområdet. Mappningskonventionen "x:" för XAML-språk-XAML-namnområdet följs av projektmallar, exempelkod och dokumentationen för språkfunktioner. XAML-språknamnområdet definierar flera vanliga funktioner som är nödvändiga även för grundläggande Windows Runtime-appar. Om du till exempel vill koppla kod bakom till en XAML-fil via en partiell klass måste du namnge den klassen som x:Class-attributet i rotelementet i den relevanta XAML-filen. Eller så måste alla element som definieras på en XAML-sida som en nyckelad resurs i en ResourceDictionary- och XAML-resursreferenser ha x:Key-attributet inställt på objektelementet i fråga.

Kodnamnområden som mappas till XAML-standardnamnområdet

Följande är en lista över kodnamnområden som för närvarande är mappade till XAML-standardnamnområdet.

  • Windows.UI
  • Windows.UI.Xaml
  • Windows.UI.Xaml.Automation
  • Windows.UI.Xaml.Automation.Peers
  • Windows.UI.Xaml.Automation.Provider
  • Windows.UI.Xaml.Automation.Text
  • Windows.UI.Xaml.Controls
  • Windows.UI.Xaml.Controls.Primitives
  • Windows.UI.Xaml.Data
  • Windows.UI.Xaml.Documents
  • Windows.UI.Xaml.Input
  • Windows.UI.Xaml.Interop
  • Windows.UI.Xaml.Markup
  • Windows.UI.Xaml.Media
  • Windows.UI.Xaml.Media.Animation
  • Windows.UI.Xaml.Media.Imaging
  • Windows.UI.Xaml.Media.Media3D
  • Windows.UI.Xaml.Navigation
  • Windows.UI.Xaml.Resources
  • Windows.UI.Xaml.Shapes
  • Windows.UI.Xaml.Threading
  • Windows.UI.Text

Andra XAML-namnområden

Förutom standardnamnområdet och XAML-språket XAML-namnområdet "x:" kan du även se andra mappade XAML-namnområden i den första standard-XAML för appar som genereras av Microsoft Visual Studio.

d: (http://schemas.microsoft.com/expression/blend/2008)

XAML-namnområdet "d:" är avsett för designerstöd, särskilt designerstöd i XAML-designytorna i Microsoft Visual Studio. XAML-namnområdet "d:" möjliggör design- eller designtidsattribut för XAML-element. Dessa designer-attribut påverkar bara designaspekterna av XAML:s beteende. Designerattributen ignoreras när samma XAML läses in av Windows Runtime XAML-parsern när en app körs. I allmänhet är designerattributen giltiga för alla XAML-element, men i praktiken finns det bara vissa scenarier där det är lämpligt att använda ett designerattribut själv. I synnerhet är många av designerattributen avsedda att ge en bättre upplevelse för att interagera med datakontexter och datakällor medan du utvecklar XAML och kod som använder databindning.

  • d:DesignHeight och d:DesignWidth-attribut: Dessa attribut tillämpas ibland på roten i en XAML-fil som Visual Studio eller en annan XAML-designeryta skapar åt dig. Dessa attribut anges till exempel på UserControl-roten för XAML som skapas om du lägger till en ny UserControl i ditt appprojekt. De här attributen gör det enklare att utforma sammansättningen av XAML-innehållet, så att du har viss förväntan på de layoutbegränsningar som kan finnas när XAML-innehållet används för en kontrollinstans eller någon annan del av en större UI-sida.

    Not Om du migrerar XAML från Microsoft Silverlight kan du ha dessa attribut på rotelement som representerar en hel användargränssnittssida. Du kanske vill ta bort attributen i det här fallet. Andra funktioner i XAML-designers, till exempel simulatorn, är förmodligen mer användbara för att utforma sidlayouter som hanterar skalnings- och visningstillstånd väl än en sidlayout med fast storlek med d:DesignHeight och d:DesignWidth.

  • d:DataContext-attribut: Du kan ange det här attributet på sidans rot eller en kontroll för att åsidosätta explicita eller ärvda DataContext som objektet annars har.

  • d:DesignSource-attributet: Anger en designtidsdatakälla för en CollectionViewSource, som överstyr Source.

  • d:DesignInstance och d:DesignData-markeringstillägg: Dessa tillägg används för att tillhandahålla dataresurser för design-tid för antingen d:DataContext eller d:DesignSource. Vi kommer inte att dokumentera i detalj hur du använder dataresurser för designtid här. För mer information, se Design-Time Attributes. Vissa användningsexempel finns i Exempeldata på designytan och för prototyper.

mc: (http://schemas.openxmlformats.org/markup-compatibility/2006)

"mc:" anger och stöder ett kompatibilitetsläge för att hantera markering vid läsning av XAML. Normalt associeras prefixet "d:" med attributet mc:Ignorable. Med den här tekniken kan XAML-parsare vid exekveringstid ignorera designattributen i "d:".

lokala: och vanliga:

"local:" är ett prefix som ofta mappas åt dig inom XAML-sidorna för ett mallat UWP-appprojekt. Den mappas för att referera till samma namnområde som har skapats för att innehålla attributet x:Class och koden för alla XAML-filer, inklusive app.xaml. Så länge du definierar anpassade klasser som du vill använda i XAML i samma namnområde kan du använda prefixet local: för att referera till dina anpassade typer i XAML. Ett relaterat prefix som kommer från ett mallat UWP-appprojekt är vanligt:. Det här prefixet refererar till ett kapslat "Gemensamt" namnområde som innehåller verktygsklasser som konverterare och kommandon, och du hittar definitionerna i mappen Common i Solution Explorer-vyn .

vsm:

Använd inte. "vsm:" är ett prefix som ibland visas i äldre XAML-mallar som importerats från andra Microsoft-tekniker. Namnrymden tog ursprungligen upp ett verktygsproblem med äldre namnrymder. Du bör ta bort XAML-namnområdesdefinitioner för "vsm:" i alla XAML som du använder för Windows Runtime och ändra eventuella prefixanvändningar för VisualState, VisualStateGroup och relaterade objekt så att XAML-standardnamnområdet används i stället. Mer information om XAML-migrering finns i Migrera Silverlight eller WPF XAML/kod till en Windows Runtime-app.

Mappa anpassade typer till XAML-namnområden och prefix

Du kan mappa ett XAML-namnområde så att du kan använda XAML för att komma åt dina egna anpassade typer. Med andra ord mappar du ett kodnamnområde eftersom det finns i en kodrepresentation som definierar den anpassade typen och tilldelar den ett XAML-namnområde tillsammans med ett prefix för användning. Anpassade typer för XAML kan definieras antingen i ett Microsoft .NET-språk (C# eller Microsoft Visual Basic) eller i C++. Mappningen görs genom att definiera ett xmlns-prefix . Definierar xmlns:myTypes till exempel ett nytt XAML-namnområde som används genom att prefixera alla användningar med token myTypes:.

En xmlns-definition innehåller ett värde samt prefixets namngivning. Värdet är en sträng som går inom citationstecken, efter ett likhetstecken. En vanlig XML-konvention är att associera XML-namnområdet med en URI (Uniform Resource Identifier), så att det finns en konvention för unikhet och identifiering. Du ser även den här konventionen för XAML-standardnamnområdet och XAML-språket XAML-namnområdet, samt för några mindre använda XAML-namnområden som används av Windows Runtime XAML. Men för ett XAML-namnområde som mappar anpassade typer, i stället för att ange en URI, börjar du prefixdefinitionen med token "using:". Efter token "using:" namnger du sedan kodnamnområdet.

Om du till exempel vill mappa ett "custom1"-prefix som gör att du kan referera till ett "CustomClasses"-namnområde och använda klasser från namnområdet eller sammansättningen som objektelement i XAML, bör XAML-sidan innehålla följande mappning för rotelementet: xmlns:custom1="using:CustomClasses"

Partiella klasser av samma sidomfång behöver inte mappas. Du behöver till exempel inte prefix för att referera till händelsehanterare som du har definierat för att hantera händelser från XAML-användargränssnittsdefinitionen för din sida. Dessutom mappar många av de startande XAML-sidorna från Visual Studio-genererade projekt för en Windows Runtime-app redan ett "local:"-prefix, som refererar till det projektdefinierade standardnamnområdet och namnområdet som används av partiella klassdefinitioner.

CLR-språkregler

Om du skriver din bakgrundskod på ett .NET-språk (C# eller Microsoft Visual Basic) kanske du använder konventioner som använder en punkt (".") som en del av namnområdesnamn för att skapa en koncepthierarki med kodnamnområden. Om namnområdesdefinitionen innehåller en punkt ska punkten vara en del av det värde som du anger efter token "using:".

Om din kod-bakom-fil eller koddefinitionsfil är en C++-fil finns det vissa konventioner som fortfarande följer CLR-språkformuläret (Common Language Runtime), så att det inte finns någon skillnad i XAML-syntaxen. Om du deklarerar kapslade namnområden i C++, bör avgränsaren mellan efterföljande kapslade namnområdessträngar vara "." i stället för "::" när du anger det värde som följer på token "using:".

Använd inte kapslade typer (till exempel kapsling av en uppräkning i en klass) när du definierar din kod för användning med XAML. Kapslade typer kan inte utvärderas. Det finns inget sätt för XAML-parsern att urskilja att en punkt är en del av det kapslade typnamnet i stället för en del av namnområdesnamnet.

Anpassade typer och sammansättningar

Namnet på sammansättningen som definierar bakgrundstyperna för ett XAML-namnområde anges inte i mappningen. Logiken för vilka sammansättningar är tillgängliga styrs på appdefinitionsnivå och är en del av grundläggande appdistribution och säkerhetsprinciper. Deklarera alla sammansättningar som du vill inkludera som en koddefinitionskälla för XAML som en beroende sammansättning i projektinställningarna. Mer information finns i Skapa Windows Runtime-komponenter i C# och Visual Basic.

Om du refererar till anpassade typer från den primära appens programdefinition eller siddefinitioner är dessa typer tillgängliga utan ytterligare beroende sammansättningskonfiguration, men du måste ändå mappa kodnamnområdet som innehåller dessa typer. En vanlig konvention är att mappa prefixet "local" för standardkodnamnområdet för en viss XAML-sida. Den här konventionen ingår ofta i startprojektmallar för XAML-projekt.

Anslutna egenskaper

Om du refererar till anslutna egenskaper måste ägartypsdelen av det bifogade egenskapsnamnet antingen finnas i XAML-standardnamnområdet eller vara prefix. Det är ovanligt att prefixattribut separeras från deras element, men det här är ett fall där det ibland krävs, särskilt för en anpassad bifogad egenskap. Mer information finns i Anpassade bifogade egenskaper.

  • Last updated on