Dela via

XAML-nodströmstrukturer och begrepp

  • Artikel

XAML-läsare och XAML-skrivare som implementeras i .NET XAML Services baseras på designkonceptet för en XAML-nodström. XAML-nodströmmen är en konceptualisering av en uppsättning XAML-noder. I den här konceptualiseringen går en XAML-processor igenom strukturen för nodrelationerna i XAML en i taget. När som helst finns bara en aktuell post eller aktuell position i en öppen XAML-nodström, och många aspekter av API-rapporten är bara den information som är tillgänglig från den positionen. Den aktuella noden i en XAML-nodström kan beskrivas som ett objekt, en medlem eller ett värde. Genom att behandla XAML som en XAML-nodström kan XAML-läsare kommunicera med XAML-skrivare och göra det möjligt för ett program att visa, interagera med eller ändra innehållet i en XAML-nodström under antingen en inläsningssökväg eller en åtgärd för att spara sökvägen som omfattar XAML. XAML-läsare och skrivar-API-design och XAML-nodströmkonceptet liknar tidigare relaterade läsar- och skrivardesign och begrepp, till exempel XML Document Object Model (DOM) och XmlReader- och XmlWriter-klasserna. I det här avsnittet beskrivs begrepp för XAML-nodström och hur du kan skriva rutiner som interagerar med XAML-representationer på XAML-nodnivå.

Läsa in XAML i en XAML-läsare

Basklassen XamlReader deklarerar inte en viss teknik för att läsa in den första XAML-filen i en XAML-läsare. I stället deklarerar och implementerar en härledd klass inläsningstekniken, inklusive de allmänna egenskaperna och begränsningarna för indatakällan för XAML. Till exempel läser en XamlObjectReader ett objektdiagram, med början från indatakällan för ett enda objekt som representerar roten eller basen. XamlObjectReader skapar sedan en XAML-nodström från objektdiagrammet.

Den mest framstående .NET XAML Services-definierade XamlReader underklassen är XamlXmlReader. XamlXmlReader läser in den första XAML-filen, antingen genom att läsa in en textfil direkt via en dataström eller filsökväg, eller indirekt via en relaterad läsarklass, till exempel TextReader. XamlReader kan anses innehålla hela XAML-indatakällan när den har lästs in. Det XamlReader bas-API:et är dock utformat så att läsaren interagerar med en enda nod i XAML. När den första inläsningen är den första enskilda noden som du stöter på är roten för XAML och dess startobjekt.

XAML Node Stream-konceptet

Om du är mer bekant med en DOM, trädmetafor eller frågebaserad metod för åtkomst till XML-baserade tekniker är ett användbart sätt att konceptualisera en XAML-nodström på följande sätt. Anta att den inlästa XAML:en är en DOM eller ett träd där varje möjlig nod expanderas hela vägen och sedan visas linjärt. När du går vidare genom noderna kanske du går igenom "in" eller "ut" av nivåer som skulle vara relevanta för en DOM, men XAML-nodströmmen håller inte uttryckligen reda på eftersom dessa nivåbegrepp inte är relevanta för en nodström. Nodströmmen har en "aktuell" position, men om du inte har lagrat andra delar av strömmen själv som referenser är varje aspekt av nodströmmen utom den aktuella nodpositionen inte synlig.

XAML-nodströmkonceptet har den betydande fördelen att om du går igenom hela nodströmmen är du säker på att du har bearbetat hela XAML-representationen. Du behöver inte oroa dig för att en fråga, en DOM-åtgärd eller någon annan icke-linjär metod för att bearbeta information har missat någon del av den fullständiga XAML-representationen. Därför är XAML-nodströmsrepresentationen idealisk både för att ansluta XAML-läsare och XAML-skrivare och för att tillhandahålla ett system där du kan infoga din egen process som fungerar mellan läs- och skrivfaserna i en XAML-bearbetningsåtgärd. I många fall optimeras eller sorteras ordningen på noder i XAML-nodströmmen avsiktligt eller sorteras om av XAML-läsare jämfört med hur ordningen kan visas i källtexten, binärdiagrammet eller objektdiagrammet. Det här beteendet är avsett att framtvinga en XAML-bearbetningsarkitektur där XAML-skrivare aldrig befinner sig i en position där de måste gå "tillbaka" i nodströmmen. Helst bör alla XAML-skrivåtgärder kunna agera baserat på schemakontext plus nodströmmens aktuella position.

En grundläggande läsnodsloop

En grundläggande läsnodsloop för att undersöka en XAML-nodström består av följande begrepp. Anta att du läser en textbaserad, läsbar XAML-fil med hjälp av XamlXmlReaderför nodslingor enligt beskrivningen i det här avsnittet. Länkarna i det här avsnittet refererar till det specifika XAML-nodloop-API:et som implementerats av XamlXmlReader.

  • Kontrollera att du inte är i slutet av XAML-nodströmmen (kontrollera IsEofeller använd Read returvärde). Om du är i slutet av strömmen finns det ingen aktuell nod och du bör avsluta.

  • Kontrollera vilken typ av nod XAML-nodströmmen för närvarande exponerar genom att anropa NodeType.

  • Om du har en associerad XAML-objektskrivare som är direkt ansluten anropar du vanligtvis WriteNode just nu.

  • Baserat på vilken XamlNodeType rapporteras som aktuell nod eller aktuell post anropar du något av följande för att hämta information om nodinnehållet:

    • För en NodeType av StartMember eller EndMemberanropar du Member för att hämta XamlMember information om en medlem. Medlemmen kan vara en XamlDirectiveoch kanske därför inte nödvändigtvis är en konventionell typdefinierad medlem i föregående objekt. Till exempel visas x:Name som tillämpas på ett objekt som en XAML-medlem där IsDirective är sant och medlemmens Name är Name, med andra egenskaper som anger att det här direktivet är under XAML-språket XAML-namnområdet.

    • För en NodeType av StartObject eller EndObjectanropar du Type för att hämta XamlType information om ett objekt.

    • För en NodeType av Valueanropar du Value. En nod är bara ett värde om det är det enklaste uttrycket för ett värde för en medlem, eller initieringstexten för ett objekt (du bör dock vara medveten om typkonverteringsbeteendet enligt beskrivningen i ett kommande avsnitt i det här avsnittet).

    • För en NodeType av NamespaceDeclarationanropar du Namespace för att hämta namnområdesinformation för en namnområdesnod.

  • Anropa Read för att flytta XAML-läsaren till nästa nod i XAML-nodströmmen och upprepa stegen igen.

XAML-nodströmmen som tillhandahålls av .NET XAML Services XAML-läsare ger alltid en fullständig, djup bläddering av alla möjliga noder. Typiska tekniker för flödeskontroll för en XAML-nodloop är att definiera en brödtext i while (reader.Read())och att växla på NodeType vid varje nodpunkt i nodloopen.

Om nodströmmen är i slutet av filen är den aktuella noden null.

Den enklaste loopen som använder en läsare och skrivare liknar följande exempel.

XamlXmlReader xxr = new XamlXmlReader(new StringReader(xamlStringToLoad));
//where xamlStringToLoad is a string of well formed XAML
XamlObjectWriter xow = new XamlObjectWriter(xxr.SchemaContext);
while (xxr.Read()) {
  xow.WriteNode(xxr);
}

Det här grundläggande exemplet på en XAML-nodloop för inläsningssökväg ansluter transparent XAML-läsaren och XAML-skrivaren och gör inget annat än om du hade använt XamlServices.Parse. Men den här grundläggande strukturen utökas sedan för att gälla för ditt läs- eller skrivscenario. Några möjliga scenarier är följande:

  • Slå på NodeType. Utför olika åtgärder beroende på vilken nodtyp som läss.

  • Anropa inte WriteNode i alla fall. Anropa endast WriteNode i vissa NodeType fall.

  • I logiken för en viss nodtyp analyserar du nodens specifika egenskaper och agerar på dem. Du kan till exempel bara skriva objekt som kommer från ett visst XAML-namnområde och sedan släppa eller skjuta upp objekt som inte kommer från XAML-namnområdet. Eller så kan du släppa eller på annat sätt bearbeta eventuella XAML-direktiv som XAML-systemet inte stöder som en del av din medlemsbearbetning.

  • Definiera en anpassad XamlObjectWriter som åsidosätter Write* metoder och eventuellt utför typmappning som kringgår XAML-schemakontexten.

  • Konstruera XamlXmlReader för att använda en XAML-schemakontext utan fel, så att anpassade skillnader i XAML-beteende används både av läsaren och skrivaren.

Åtkomst till XAML utöver node-loopkonceptet

Det finns potentiellt andra sätt att arbeta med en XAML-representation än som en XAML-nodloop. Det kan till exempel finnas en XAML-läsare som kan läsa en indexerad nod, eller i synnerhet komma åt noder direkt via x:Name, genom x:Uideller via andra identifierare. .NET XAML Services tillhandahåller ingen fullständig implementering, men ger ett föreslaget mönster via tjänster och supporttyper. Mer information finns i IXamlIndexingReader och XamlNodeList.

Arbeta med den aktuella noden

De flesta scenarier som använder en XAML-nodloop läser inte bara noderna. De flesta scenarier bearbetar aktuella noder och skickar varje nod en i taget till en implementering av XamlWriter.

I det typiska inläsningssökvägsscenariot skapar en XamlXmlReader en XAML-nodström. XAML-noderna bearbetas enligt din logik och XAML-schemakontext. och noderna skickas till en XamlObjectWriter. Sedan integrerar du det resulterande objektdiagrammet i ditt program eller ramverk.

I ett typiskt scenario för spara sökväg läser en XamlObjectReader objektdiagrammet, enskilda XAML-noder bearbetas och en XamlXmlWriter matar ut det serialiserade resultatet som en XAML-textfil. Nyckeln är att både sökvägar och scenarier innebär att arbeta med exakt en XAML-nod i taget, och XAML-noderna är tillgängliga för behandling på ett standardiserat sätt som definieras av XAML-typsystemet och the.NET XAML Services-API:er.

Ramar och omfång

En XAML-nodloop går igenom en XAML-nodström på ett linjärt sätt. Nodströmmen passerar in i objekt, till medlemmar som innehåller andra objekt och så vidare. Det är ofta användbart att hålla reda på omfånget i XAML-nodströmmen genom att implementera ett ram- och stackkoncept. Detta gäller särskilt om du aktivt justerar nodströmmen medan du är i den. Det stöd för ram och stack som du implementerar som en del av nodlooplogik kan räkna StartObject (eller GetObject) och EndObject omfång när du går in i en XAML-nodstruktur om strukturen betraktas ur ett DOM-perspektiv.

Bläddring och inmatning av objektnoder

Den första noden i en nodström när den öppnas av en XAML-läsare är rotobjektets startobjektnod. Det här objektet är per definition alltid en enskild objektnod och har inga peer-datorer. I ett verkligt XAML-exempel definieras rotobjektet att ha en eller flera egenskaper som innehåller fler objekt, och dessa egenskaper har medlemsnoder. Medlemsnoderna har sedan en eller flera objektnoder eller kan också avslutas i en värdenod i stället. Rotobjektet definierar vanligtvis XAML-namnskop, som syntaktiskt tilldelas som attribut i XAML-textmarkeringen men mappas till en Namescope nodtyp i XAML-nodströmsrepresentationen.

Överväg följande XAML-exempel (det här är godtycklig XAML, som inte backas upp av befintliga typer i .NET). Anta att FavorCollection i den här objektmodellen är List<T> av Favor, Balloon och NoiseMaker kan tilldelas till Favor, Balloon.Color egenskapen backas upp av ett Color objekt som liknar hur WPF definierar färger som kända färgnamn och Color stöder en typkonverterare för attributsyntax.

XAML-markering Resulterande XAML-nodström
<Party Namespace nod för Party
xmlns="PartyXamlNamespace"> StartObject nod för Party
<Party.Favors> StartMember nod för Party.Favors
StartObject nod för implicit FavorCollection
StartMember nod för egenskapen implicita FavorCollection objekt.
<Balloon StartObject nod för Balloon
Color="Red" StartMember nod för Color

Value nod för attributvärdesträngen "Red"

EndMember för Color
HasHelium="True" StartMember nod för HasHelium

Value nod för attributvärdesträngen "True"

EndMember för HasHelium
> EndObject för Balloon
<NoiseMaker>Loudest</NoiseMaker> StartObject nod för NoiseMaker

StartMember nod för _Initialization

Value nod för initieringsvärdesträngen "Loudest"

EndMember nod för _Initialization

EndObject för NoiseMaker
EndMember nod för egenskapen implicita FavorCollection objekt.
EndObject nod för implicit FavorCollection
</Party.Favors> EndMember för Favors
</Party> EndObject för Party

I XAML-nodströmmen kan du förlita dig på följande beteende:

  • Om det finns en Namespace nod läggs den till i strömmen omedelbart före StartObject som deklarerade XAML-namnområdet med xmlns. Titta på föregående tabell med XAML och exempelnodströmmen igen. Observera hur noderna StartObject och Namespace verkar transponeras jämfört med deras deklarationspositioner i textmarkering. Detta är representativt för det beteende där namnområdesnoderna alltid visas före noden de gäller för i nodströmmen. Syftet med den här designen är att namnområdesinformationen är viktig för objektskrivare och måste vara känd innan objektskrivaren försöker utföra typmappning eller på annat sätt bearbeta objektet. Om du placerar XAML-namnområdesinformationen före dess programomfång i dataströmmen blir det enklare att alltid bearbeta nodströmmen i den angivna ordningen.

  • På grund av ovanstående överväganden är det en eller flera Namespace noder som du läser först i de flesta verkliga markeringsfall när du passerar noder från början, inte StartObject av roten.

  • En StartObject nod kan följas av StartMember, Valueeller en omedelbar EndObject. Det följs aldrig omedelbart av en annan StartObject.

  • En StartMember kan följas av en StartObject, Valueeller en omedelbar EndMember. Det kan följas av GetObject, för medlemmar där värdet ska komma från ett befintligt värde för det överordnade objektet i stället för en StartObject som instansierar ett nytt värde. Den kan också följas av en Namespace nod, som gäller för en kommande StartObject. Det följs aldrig omedelbart av en annan StartMember.

  • En Value nod representerar själva värdet. det finns ingen "EndValue". Det kan bara följas av en EndMember.

    • XAML-initieringstexten för objektet som kan användas av konstruktionen resulterar inte i en Object-Value struktur. I stället skapas en dedikerad medlemsnod för en medlem med namnet _Initialization. och att medlemsnoden innehåller initieringsvärdesträngen. Om den finns är _Initialization alltid den första StartMember. _Initialization kan vara kvalificerade i vissa XAML-tjänstrepresentationer med XAML-språket XAML-namnskop, för att klargöra att _Initialization inte är en definierad egenskap i säkerhetskopieringstyper.

    • En Member-Value kombination representerar en attributinställning för värdet. Det kan så småningom finnas en värdekonverterare som är involverad i bearbetningen av det här värdet, och värdet är en vanlig sträng. Detta utvärderas dock inte förrän en XAML-objektskrivare bearbetar den här nodströmmen. XAML-objektskrivaren har nödvändig XAML-schemakontext, typsystemmappning och annat stöd som behövs för värdekonverteringar.

  • En EndMember nod kan följas av en StartMember nod för en efterföljande medlem eller av en EndObject nod för medlemsägaren.

  • En EndObject nod kan följas av en EndMember nod. Det kan också följas av en StartObject nod för fall där objekten är peer-objekt i en samlings objekt. Eller så kan den följas av en Namespace nod, som gäller för en kommande StartObject.

    • För det unika fallet med att stänga hela nodströmmen följs inte rotens EndObject av någonting. läsaren är nu filslut och Read returnerar false.

Värdekonverterare och XAML-nodströmmen

En värdekonverterare är en allmän term för ett markeringstillägg, en typkonverterare (inklusive värde serialiserare) eller en annan dedikerad klass som rapporteras som en värdekonverterare via XAML-typsystemet. I XAML-nodströmmen har en typkonverterareanvändning och en användning av markeringstillägg mycket olika representationer.

Skriv konverterare i XAML-nodströmmen

En attributuppsättning som så småningom resulterar i en typkonverterares användning rapporteras i XAML-nodströmmen som ett värde för en medlem. XAML-nodströmmen försöker inte skapa ett typkonverterarinstansobjekt och skicka värdet till det. Om du använder en typkonverterares konverteringsimplementering måste du anropa XAML-schemakontexten och använda den för typmappning. Även för att avgöra vilken typkonverterareklass som ska användas för att bearbeta värdet krävs XAML-schemakontexten indirekt. När du använder XAML-standardschemakontexten är den informationen tillgänglig från XAML-typsystemet. Om du behöver typkonverterarens klassinformation på XAML-nodströmnivån före anslutning till en XAML-skrivare kan du hämta den från XamlMember information om medlemmen som anges. Annars bör typkonverterarens indata bevaras i XAML-nodströmmen som ett vanligt värde tills resten av åtgärderna som kräver typmappningssystemet och XAML-schemakontexten utförs, till exempel att objektet skapas av en XAML-objektskrivare.

Tänk till exempel på följande klassdefinitionsdisposition och XAML-användning för den:

public class BoardSizeConverter : TypeConverter {
  //converts from string to an int[2] by splitting on an "x" char
}
public class GameBoard {
  [TypeConverter(typeof(BoardSizeConverter))]
  public int[] BoardSize; //2x2 array, initialization not shown
}

<GameBoard BoardSize="8x8"/>

En textrepresentation av XAML-nodströmmen för den här användningen kan uttryckas som följande:

StartObject med XamlType som representerar GameBoard

StartMember med XamlMember som representerar BoardSize

Value nod med textsträngen "8x8"

EndMember matchar BoardSize

EndObject matchar GameBoard

Observera att det inte finns någon typkonverterareinstans i den här nodströmmen. Men du kan hämta typkonverterareinformation genom att anropa XamlMember.TypeConverter på XamlMember för BoardSize. Om du har en giltig XAML-schemakontext kan du också anropa konverterarmetoderna genom att hämta en instans från ConverterInstance.

Markeringstillägg i XAML-nodströmmen

En användning av markeringstillägg rapporteras i XAML-nodströmmen som en objektnod i en medlem, där objektet representerar en instans av markeringstillägget. Därför visas en användning av markeringstillägg mer explicit i nodströmsrepresentationen än vad en typkonverterare använder och innehåller mer information. XamlMember information kunde inte ha berättat något om markeringstillägget, eftersom användningen är situationell och varierar i varje möjligt markeringsfall. Den är inte dedikerad och implicit per typ eller medlem, vilket är fallet med typkonverterare.

Nodströmsrepresentationen av markeringstillägg som objektnoder är fallet även om markeringstilläggsanvändningen gjordes i attributform i XAML-textpålägget (vilket ofta är fallet). Markeringstilläggsanvändningar som använde ett explicit objektelementformulär behandlas på samma sätt.

I en objektnod för markeringstillägg kan det finnas medlemmar i det markeringstillägget. XAML-nodströmsrepresentationen bevarar användningen av det markeringstillägget, oavsett om det är en positionell parameteranvändning eller en användning med explicita namngivna parametrar.

För användning av en positionsparameter innehåller XAML-nodströmmen en XAML-språkdefinierad egenskap _PositionalParameters som registrerar användningen. Den här egenskapen är en allmän List<T> med Object villkor. Villkoret är objekt och inte sträng eftersom en positionsparameteranvändning kan innehålla kapslade användningar av markeringstillägg i den. Om du vill komma åt positionsparametrarna från användningen kan du iterera genom listan och använda indexerarna för enskilda listvärden.

För en namngiven parameteranvändning representeras varje namngiven parameter som en medlemsnod med det namnet i nodströmmen. Medlemsvärdena är inte nödvändigtvis strängar, eftersom det kan finnas en kapslad markeringstilläggsanvändning.

ProvideValue från markeringstillägget har ännu inte anropats. Det anropas dock om du ansluter en XAML-läsare och XAML-skrivare så att WriteEndObject anropas på markeringstilläggsnoden när du undersöker den i nodströmmen. Därför behöver du vanligtvis samma XAML-schemakontext som skulle användas för att skapa objektdiagrammet på inläsningssökvägen. Annars kan ProvideValue från valfritt markeringstillägg utlösa undantag här, eftersom det inte har förväntade tjänster tillgängliga.

XAML- och XML-Language-Defined medlemmar i XAML-nodströmmen

Vissa medlemmar introduceras till en XAML-nodström på grund av tolkningar och konventioner för en XAML-läsare, i stället för via en explicit XamlMember sökning eller konstruktion. Dessa medlemmar är ofta XAML-direktiv. I vissa fall är det att läsa XAML som introducerar direktivet i XAML-nodströmmen. Med andra ord angav den ursprungliga XAML-texten inte uttryckligen medlemsdirektivet, men XAML-läsaren infogar direktivet för att uppfylla en strukturell XAML-konvention och rapportera information i XAML-nodströmmen innan den informationen går förlorad.

I följande lista beskrivs alla fall där en XAML-läsare förväntas introducera en XAML-medlemsnod för direktiv och hur den medlemsnoden identifieras i .NET XAML Services-implementeringar.

  • Initieringstext för en objektnod: Namnet på den här medlemsnoden är _Initialization, representerar det ett XAML-direktiv och definieras i XAML-språk-XAML-namnområdet. Du kan hämta en statisk entitet för den från Initialization.

  • Positionsparametrar för ett markeringstillägg: Namnet på den här medlemsnoden är _PositionalParametersoch definieras i XAML-språketS XAML-namnområde. Den innehåller alltid en allmän lista över objekt, som var och en är en positionsparameter som avgränsas i förväg genom att dela på , avgränsartecken som anges i indata-XAML. Du kan hämta en statisk entitet för positionsparametrar från PositionalParameters.

  • Okänt innehåll: Namnet på den här medlemsnoden är _UnknownContent. Strängt taget är det en XamlDirective, och den definieras i XAML-språket XAML-namnområdet. Det här direktivet används som en sentinel för fall där ett XAML-objektelement innehåller innehåll i XAML-källan, men ingen innehållsegenskap kan fastställas under den för närvarande tillgängliga XAML-schemakontexten. Du kan identifiera det här fallet i en XAML-nodström genom att söka efter medlemmar med namnet _UnknownContent. Om ingen annan åtgärd vidtas i en XAML-nodström för inläsningssökväg utlöses standard XamlObjectWriter på försök WriteEndObject när _UnknownContent-medlemmen påträffas på något objekt. Standard-XamlXmlWriter genererar inte och behandlar medlemmen som implicit. Du kan hämta en statisk entitet för _UnknownContent från UnknownContent.

  • Samlingsegenskap för en samling: Även om den säkerhetskopierade CLR-typen för en samlingsklass som används för XAML vanligtvis har en dedikerad namngiven egenskap som innehåller samlingsobjekten, är den egenskapen inte känd för ett XAML-typsystem innan matchning av bakgrundstyp. I stället introducerar XAML-nodströmmen en Items platshållare som medlem i samlingens XAML-typ. I implementeringen av .NET XAML Services är namnet på det här direktivet eller medlemmen i nodströmmen _Items. En konstant för det här direktivet kan hämtas från Items.

    Observera att en XAML-nodström kan innehålla en objektegenskap med objekt som inte kan parsas baserat på bakgrundstypmatchningen och XAML-schemakontexten. Till exempel

  • XML-definierade medlemmar: XML-definierade medlemmar xml:base, xml:lang och xml:space rapporteras som XAML-direktiv med namnet base, langoch space i .NET XAML Services-implementeringar. Namnområdet för dessa är XML-namnområdet http://www.w3.org/XML/1998/namespace. Konstanter för var och en av dessa kan hämtas från XamlLanguage.

Nodordning

I vissa fall ändrar XamlXmlReader ordningen på XAML-noder i XAML-nodströmmen, jämfört med den ordning som noderna visas om de visas i markeringen eller om de bearbetas som XML. Detta görs för att ordna noderna så att en XamlObjectWriter kan bearbeta nodströmmen på ett framåtblickande sätt. I .NET XAML Services ordnar XAML-läsaren om noder i stället för att lämna den här uppgiften till XAML-skrivaren, som en prestandaoptimering för XAML-objektskrivarens användare av nodströmmen.

Vissa direktiv är särskilt avsedda att ge mer information för att skapa ett objekt från ett objektelement. Dessa direktiv är: Initialization, PositionalParameters, TypeArguments, FactoryMethod, Arguments. .NET XAML Services XAML-läsare försöker placera dessa direktiv som de första medlemmarna i nodströmmen efter ett objekts StartObject, av skäl som förklaras i nästa avsnitt.

XamlObjectWriter-beteende och nodordning

StartObject till en XamlObjectWriter är inte nödvändigtvis en signal till XAML-objektskrivaren att omedelbart konstruera objektinstansen. XAML innehåller flera språkfunktioner som gör det möjligt att initiera ett objekt med ytterligare indata, och att inte helt förlita sig på att anropa en parameterlös konstruktor för att skapa det första objektet och först därefter ange egenskaper. Dessa funktioner är: XamlDeferLoadAttribute; initieringstext; x:TypeArguments; positionsparametrar för ett markeringstillägg. fabriksmetoder och associerade x:Argument noder (XAML 2009). Var och en av dessa fall fördröjer den faktiska objektkonstruktionen, och eftersom nodströmmen har ordnats om kan XAML-objektskrivaren förlita sig på beteendet att faktiskt konstruera instansen när en startmedlem påträffas som inte specifikt är ett byggdirektiv för den objekttypen.

GetObject

GetObject representerar en XAML-nod där en XAML-objektskrivare i stället ska hämta värdet för objektets innehållande egenskap i stället för att konstruera ett nytt objekt. Ett typiskt fall där en GetObject nod påträffas i en XAML-nodström är för ett samlingsobjekt eller ett ordlisteobjekt, när den innehållande egenskapen avsiktligt är skrivskyddad i bakgrundstypens objektmodell. I det här scenariot skapas och initieras ofta samlingen eller ordlistan (vanligtvis tom) av initieringslogik av en ägande typ.

Se även