XAML-knooppuntstroomstructuren en -concepten

Artikel
12/17/2024

XAML-lezers en XAML-schrijvers zoals geïmplementeerd in .NET XAML Services zijn gebaseerd op het ontwerpconcept van een XAML-knooppuntstroom. De XAML-knooppuntstroom is een conceptuele weergave van een set XAML-knooppunten. In deze conceptualisatie doorloopt een XAML-processor de structuur van de knooppuntrelaties in de XAML één voor één. Er bestaat op elk gewenst moment slechts één huidige record of huidige positie in een open XAML-knooppuntstroom en veel aspecten van het API-rapport bevatten alleen de informatie die op die positie beschikbaar is. Het huidige knooppunt in een XAML-knooppuntstroom kan worden beschreven als een object, een lid of een waarde. Door XAML als een XAML-knooppuntstroom te behandelen, kunnen XAML-lezers communiceren met XAML-schrijvers en een programma in staat stellen om de inhoud van een XAML-knooppuntstroom te bekijken, te gebruiken of te wijzigen tijdens een laadpad of een opslagpadbewerking waarbij XAML is betrokken. Het XAML-lezer- en schrijver-API-ontwerp en het XAML-knooppuntstroomconcept zijn vergelijkbaar met eerdere gerelateerde lezer- en schrijfontwerpen en -concepten, zoals het XML Document Object Model (DOM) en de XmlReader- en XmlWriter-klassen. In dit onderwerp worden concepten van XAML-knooppuntstromen besproken en wordt beschreven hoe u routines kunt schrijven die interactie hebben met XAML-weergaven op XAML-knooppuntniveau.

XAML laden in een XAML-lezer

De basisklasse XamlReader declareert geen bepaalde techniek voor het laden van de initiële XAML in een XAML-lezer. In plaats daarvan declareert en implementeert een afgeleide klasse de laadtechniek, inclusief de algemene kenmerken en beperkingen van de invoerbron voor XAML. Een XamlObjectReader bijvoorbeeld een objectgrafiek leest, beginnend bij de invoerbron van één object dat de hoofdmap of basis vertegenwoordigt. De XamlObjectReader produceert vervolgens een XAML-knooppuntstroom uit de objectgrafiek.

De meest prominente .NET XAML Services-gedefinieerde XamlReader subklasse is XamlXmlReader. XamlXmlReader de eerste XAML laadt door een tekstbestand rechtstreeks via een stroom of bestandspad te laden, of indirect via een gerelateerde lezerklasse, zoals TextReader. De XamlReader kan worden beschouwd als het bevatten van de gehele XAML-invoerbron nadat deze is geladen. De XamlReader basis-API is echter zo ontworpen dat de lezer communiceert met één knooppunt van de XAML. Wanneer het eerst wordt geladen, is het eerste knooppunt dat u tegenkomt de hoofdmap van de XAML en het bijbehorende beginobject.

Het XAML-knooppuntstroomconcept

Als u meer bekend bent met een DOM-, structuurafafoor of op query's gebaseerde benadering voor toegang tot XML-technologieën, is een handige manier om een XAML-knooppuntstroom te conceptualiseren als volgt. Stel dat de geladen XAML een DOM of een boomstructuur is waar elk mogelijk knooppunt helemaal wordt uitgevouwen en vervolgens lineair wordt gepresenteerd. Wanneer u door de knooppunten gaat, kunt u 'in' of 'buiten' niveaus doorlopen die relevant zijn voor een DOM, maar de XAML-knooppuntstroom houdt het niet expliciet bij omdat deze niveauconcepten niet relevant zijn voor een knooppuntstroom. De knooppuntstroom heeft een 'huidige' positie, maar tenzij u andere onderdelen van de stroom zelf hebt opgeslagen als verwijzingen, is elk aspect van de knooppuntstroom anders dan de huidige knooppuntpositie niet zichtbaar.

Het concept van de XAML-knooppuntstroom heeft het opmerkelijke voordeel dat als u de hele knooppuntstroom doorloopt, u zeker weet dat u de volledige XAML-weergave hebt verwerkt; U hoeft zich geen zorgen te maken dat een query, een DOM-bewerking of een andere niet-lineaire benadering voor het verwerken van informatie een deel van de volledige XAML-weergave heeft gemist. Daarom is de XAML-knooppuntstroomweergave ideaal voor het verbinden van XAML-lezers en XAML-schrijvers en voor het leveren van een systeem waarin u uw eigen proces kunt invoegen dat tussen de lees- en schrijffasen van een XAML-verwerkingsbewerking werkt. In veel gevallen wordt de volgorde van knooppunten in de XAML-knooppuntstroom opzettelijk geoptimaliseerd of opnieuw gerangschikt door XAML-lezers versus hoe de volgorde kan worden weergegeven in de brontekst, binaire of objectgrafiek. Dit gedrag is bedoeld om een XAML-verwerkingsarchitectuur af te dwingen, waarbij XAML-schrijvers zich nooit in een positie bevinden waar ze 'terug' moeten gaan in de knooppuntstroom. In het ideale geval moeten alle XAML-schrijfbewerkingen kunnen reageren op basis van schemacontext plus de huidige positie van de knooppuntstroom.

Een eenvoudige knooppuntlus voor lezen

Een eenvoudige leesknooppuntlus voor het onderzoeken van een XAML-knooppuntstroom bestaat uit de volgende concepten. Voor knooppuntlussen zoals besproken in dit onderwerp, gaat u ervan uit dat u een op tekst gebaseerd, door mensen leesbaar XAML-bestand leest met behulp van XamlXmlReader. De koppelingen in deze sectie verwijzen naar de specifieke XAML-knooppuntlus-API die is geïmplementeerd door XamlXmlReader.

Zorg ervoor dat u zich niet aan het einde van de XAML-knooppuntstroom bevindt (controleer IsEofof gebruik de Read retourwaarde). Als u zich aan het einde van de stream bevindt, is er geen huidig knooppunt en moet u afsluiten.
Controleer welk type knooppunt de XAML-knooppuntstroom momenteel beschikbaar maakt door NodeTypeaan te roepen.
Als u een gekoppelde XAML-objectschrijver hebt die rechtstreeks is verbonden, roept u meestal WriteNode aan.
Op basis waarvan XamlNodeType wordt gerapporteerd als het huidige knooppunt of de huidige record, roept u een van de volgende aan om informatie over de inhoud van het knooppunt op te halen:
- Voor een NodeType van StartMember of EndMemberbelt u Member om XamlMember informatie over een lid te verkrijgen. Het lid kan een XamlDirectivezijn en is dus niet noodzakelijkerwijs een conventioneel typegedefinieerde lid van het voorgaande object. Bijvoorbeeld, x:Name toegepast op een object wordt weergegeven als een XAML-lid waar IsDirective waar is en de Name van het lid is Name, met andere eigenschappen die aangeven dat deze richtlijn zich onder de XAML-taal XAML-naamruimte bevindt.
- Voor een NodeType van StartObject of EndObjectroept u Type aan om XamlType informatie over een object te verkrijgen.
- Bel Valuevoor een NodeType van Value. Een knooppunt is alleen een waarde als het de eenvoudigste expressie is van een waarde voor een lid of de initialisatietekst voor een object (u moet echter rekening houden met het gedrag van typeconversie zoals beschreven in een volgende sectie van dit onderwerp).
- Voor een NodeType van NamespaceDeclarationroept u Namespace aan om naamruimtegegevens voor een naamruimteknooppunt te verkrijgen.
Roep Read aan om de XAML-lezer naar het volgende knooppunt in de XAML-knooppuntstroom te gaan en herhaal de stappen opnieuw.

De XAML-knooppuntstroom van .NET XAML Services XAML-lezers biedt altijd een volledige, diepe doorkruising van alle mogelijke knooppunten. Typische technieken voor stroombeheer voor een XAML-knooppuntlus omvatten het definiëren van een hoofdtekst binnen while (reader.Read())en het inschakelen van NodeType op elk knooppuntpunt in de knooppuntlus.

Als de knooppuntstroom zich aan het einde van het bestand bevindt, is het huidige knooppunt null.

De eenvoudigste lus die gebruikmaakt van een lezer en schrijver lijkt op het volgende voorbeeld.

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

In dit basisvoorbeeld van een XAML-knooppuntlus van een laadpad wordt de XAML-lezer en XAML-schrijver transparant verbonden. Dit doet niets anders dan als u XamlServices.Parsehebt gebruikt. Maar deze basisstructuur wordt vervolgens uitgebreid om toe te passen op uw lees- of schrijfscenario. Enkele mogelijke scenario's zijn als volgt:

Schakel NodeTypein. Voer verschillende acties uit, afhankelijk van het type knooppunt dat wordt gelezen.
Roep in alle gevallen geen WriteNode aan. Roep in sommige NodeType gevallen alleen WriteNode aan.
Analyseer in de logica voor een bepaald knooppunttype de specifieke kenmerken van dat knooppunt en werk erop. U kunt bijvoorbeeld alleen objecten schrijven die afkomstig zijn van een bepaalde XAML-naamruimte en vervolgens objecten uit die XAML-naamruimte verwijderen of uitstellen. U kunt ook XAML-instructies verwijderen of anderszins opnieuw verwerken die uw XAML-systeem niet ondersteunt als onderdeel van de verwerking van uw leden.
Definieer een aangepaste XamlObjectWriter die Write* methoden overschrijft, waarbij mogelijk typetoewijzingen worden uitgevoerd die de context van het XAML-schema omzeilen.
Maak de XamlXmlReader om een niet-standaard XAML-schemacontext te gebruiken, zodat aangepaste verschillen in XAML-gedrag worden gebruikt door zowel de lezer als de schrijver.

Toegang tot XAML buiten het concept Knooppuntlus

Er zijn mogelijk andere manieren om te werken met een andere XAML-weergave dan een XAML-knooppuntlus. Er kan bijvoorbeeld een XAML-lezer bestaan die een geïndexeerd knooppunt kan lezen of met name knooppunten rechtstreeks kan openen door x:Name, door x:Uidof via andere id's. .NET XAML Services biedt geen volledige implementatie, maar biedt een voorgesteld patroon via services en ondersteuningstypen. Zie IXamlIndexingReader en XamlNodeListvoor meer informatie.

Werken met het huidige knooppunt

De meeste scenario's die gebruikmaken van een XAML-knooppuntlus, lezen niet alleen de knooppunten. De meeste scenario's verwerken huidige knooppunten en geven elk knooppunt één voor één door aan een implementatie van XamlWriter.

In het typische scenario van het laadpad produceert een XamlXmlReader een XAML-knooppuntstroom; de XAML-knooppunten worden verwerkt volgens uw logica en XAML-schemacontext; en de knooppunten worden doorgegeven aan een XamlObjectWriter. Vervolgens integreert u de resulterende objectgrafiek in uw toepassing of framework.

In een typisch scenario voor het opslaan van een pad leest een XamlObjectReader de objectgrafiek leest, worden afzonderlijke XAML-knooppunten verwerkt en een XamlXmlWriter het geserialiseerde resultaat als een XAML-tekstbestand uitvoert. De sleutel is dat beide paden en scenario's betrekking hebben op exact één XAML-knooppunt tegelijk en dat de XAML-knooppunten beschikbaar zijn voor behandeling op een gestandaardiseerde manier die wordt gedefinieerd door het XAML-typesysteem en the.NET XAML Services-API's.

Frames en bereik

Een XAML-knooppuntlus doorloopt een XAML-knooppuntstroom op een lineaire manier. De knooppuntstroom gaat over naar objecten, naar leden die andere objecten bevatten, enzovoort. Het is vaak handig om het bereik binnen de XAML-knooppuntstroom bij te houden door een frame- en stackconcept te implementeren. Dit geldt met name als u de knooppuntstroom actief aanpast terwijl u er zich in bevindt. De ondersteuning voor frame en stack die u implementeert als onderdeel van de knooppuntluslogica, kan StartObject (of GetObject) en EndObject bereiken tellen terwijl u afdaalt in een XAML-knooppuntstructuur als de structuur vanuit een DOM-perspectief wordt gezien.

Doorkruisen en objectknooppunten invoeren

Het eerste knooppunt in een knooppuntstream wanneer het wordt geopend door een XAML-lezer is het beginobjectknooppunt van het hoofdobject. Dit object is per definitie altijd één objectknooppunt en heeft geen peers. In een real-world XAML-voorbeeld wordt het hoofdobject gedefinieerd om een of meer eigenschappen te hebben die meer objecten bevatten en deze eigenschappen hebben lidknooppunten. De lidknooppunten hebben vervolgens een of meer objectknooppunten, of kunnen ook worden beëindigd in een waardeknooppunt. Het hoofdobject definieert doorgaans XAML-naamscopen, die syntactisch zijn toegewezen als kenmerken in de XAML-tekstmarkering, maar worden toegewezen aan een Namescope knooppunttype in de XAML-knooppuntstroomweergave.

Bekijk het volgende XAML-voorbeeld (dit is willekeurige XAML, niet ondersteund door bestaande typen in .NET). Stel dat in dit objectmodel FavorCollection is List<T> van Favor, Balloon en NoiseMaker kunnen worden toegewezen aan Favor, wordt de eigenschap Balloon.Color ondersteund door een Color-object dat vergelijkbaar is met de manier waarop WPF kleuren definieert als bekende kleurnamen en Color een typeconversieprogramma voor kenmerksyntaxis ondersteunt.

XAML-markeringen	Resulterende XAML-knooppuntstroom
`<Party`	`Namespace` knooppunt voor `Party`
`xmlns="PartyXamlNamespace">`	`StartObject` knooppunt voor `Party`
`<Party.Favors>`	`StartMember` knooppunt voor `Party.Favors`
	`StartObject` knooppunt voor impliciete `FavorCollection`
	`StartMember` knooppunt voor impliciete eigenschap `FavorCollection` items.
`<Balloon`	`StartObject` knooppunt voor `Balloon`
`Color="Red"`	`StartMember` knooppunt voor `Color` `Value` knooppunt voor de tekenreeks met kenmerkwaarden `"Red"` `EndMember` voor `Color`
`HasHelium="True"`	`StartMember` knooppunt voor `HasHelium` `Value` knooppunt voor de tekenreeks met kenmerkwaarden `"True"` `EndMember` voor `HasHelium`
`>`	`EndObject` voor `Balloon`
`<NoiseMaker>Loudest</NoiseMaker>`	`StartObject` knooppunt voor `NoiseMaker` `StartMember` knooppunt voor `_Initialization` `Value` knooppunt voor de tekenreeks initialisatiewaarde `"Loudest"` `EndMember` knooppunt voor `_Initialization` `EndObject` voor `NoiseMaker`
	`EndMember` knooppunt voor impliciete eigenschap `FavorCollection` items.
	`EndObject` knooppunt voor impliciete `FavorCollection`
`</Party.Favors>`	`EndMember` voor `Favors`
`</Party>`	`EndObject` voor `Party`

In de XAML-knooppuntstroom kunt u vertrouwen op het volgende gedrag:

Als er een Namespace knooppunt bestaat, wordt het direct vóór de StartObject toegevoegd die de XAML-naamruimte met xmlnsheeft gedeclareerd. Bekijk de vorige tabel met de XAML en de voorbeeldstroom van het knooppunt opnieuw. U ziet hoe de StartObject- en Namespace-knooppunten lijken te worden getransponeerd ten opzichte van hun declaratieposities in tekstmarkeringen. Dit is representatief voor het gedrag waarbij de naamruimteknooppunten altijd vóór het knooppunt worden weergegeven waarop ze van toepassing zijn in de knooppuntstroom. Het doel van dit ontwerp is dat de naamruimtegegevens essentieel zijn voor objectschrijvers en moeten bekend zijn voordat de objectschrijver probeert typetoewijzing uit te voeren of anderszins het object te verwerken. Door de informatie over de XAML-naamruimte vóór het toepassingsbereik in de stroom te plaatsen, is het eenvoudiger om de knooppuntstroom altijd in de gepresenteerde volgorde te verwerken.
Vanwege de bovenstaande overweging is het een of meer Namespace knooppunten die u eerst leest in de meeste praktijkvoorbeelden bij het doorlopen van knooppunten vanaf het begin, niet de StartObject van de hoofdmap.
Een StartObject knooppunt kan worden gevolgd door StartMember, Valueof een onmiddellijke EndObject. Het wordt nooit onmiddellijk gevolgd door een andere StartObject.
Een StartMember kan worden gevolgd door een StartObject, Valueof een onmiddellijke EndMember. Dit kan worden gevolgd door GetObject, voor leden waarvan de waarde afkomstig moet zijn van een bestaande waarde van het bovenliggende object in plaats van een StartObject die een nieuwe waarde zou instantiëren. Het kan ook worden gevolgd door een Namespace-knooppunt, dat van toepassing is op een toekomstige StartObject. Het wordt nooit onmiddellijk gevolgd door een andere StartMember.
Een Value-knooppunt vertegenwoordigt de waarde zelf; er is geen endvalue. Het kan alleen worden gevolgd door een EndMember.
- De XAML-initialisatietekst van het object, zoals kan worden gebruikt door de constructie, leidt niet tot een Object-Value structuur. In plaats daarvan wordt een toegewezen lidknooppunt voor een lid met de naam _Initialization gemaakt. en dat lidknooppunt bevat de tekenreeks voor initialisatiewaarden. Als deze bestaat, is _Initialization altijd de eerste StartMember. _Initialization kunnen worden gekwalificeerd in sommige XAML-services met de XAML-taal XAML-naamscoop, om te verduidelijken dat _Initialization geen gedefinieerde eigenschap is in back-uptypen.
- Een combinatie van Member-Value vertegenwoordigt een kenmerkinstelling van de waarde. Er kan uiteindelijk een waardeconversieprogramma zijn dat betrokken is bij het verwerken van deze waarde en de waarde is een gewone tekenreeks. Dit wordt echter pas geëvalueerd als een XAML-objectschrijver deze knooppuntstroom verwerkt. De XAML-objectschrijver beschikt over de benodigde XAML-schemacontext, typesysteemtoewijzing en andere ondersteuning die nodig is voor waardeconversies.
Een EndMember-knooppunt kan worden gevolgd door een StartMember knooppunt voor een volgend lid of door een EndObject knooppunt voor de eigenaar van het lid.
Een EndObject knooppunt kan worden gevolgd door een EndMember knooppunt. Het kan ook worden gevolgd door een StartObject knooppunt voor gevallen waarin de objecten peers zijn in de items van een verzameling. Of het kan worden gevolgd door een Namespace knooppunt, dat van toepassing is op een toekomstige StartObject.
- Voor het unieke geval van het sluiten van de hele knooppuntstroom wordt het EndObject van de hoofdmap niet gevolgd door iets; de lezer is nu einde van bestand en Read retourneert false.

Waardeconversieprogramma's en de XAML-knooppuntstroom

Een waardeconversieprogramma is een algemene term voor een markeringsextensie, een typeconversieprogramma (inclusief waardeserialisaties) of een andere toegewezen klasse die wordt gerapporteerd als een waardeconversieprogramma via het XAML-typesysteem. In de XAML-knooppuntstroom hebben een conversieprogrammagebruik en een markeringsuitbreidingsgebruik zeer verschillende weergaven.

Conversieprogramma's typen in de XAML-knooppuntstroom

Een kenmerkset die uiteindelijk resulteert in een type conversieprogrammagebruik wordt gerapporteerd in de XAML-knooppuntstroom als waarde van een lid. De XAML-knooppuntstroom probeert geen exemplaarobject van het type conversieprogramma te produceren en geeft de waarde hieraan door. Voor het gebruik van de conversie-implementatie van een typeconversieprogramma moet u de XAML-schemacontext aanroepen en deze gebruiken voor typetoewijzing. Zelfs het bepalen welke type conversieklasse moet worden gebruikt om de waarde te verwerken, vereist indirect de context van het XAML-schema. Wanneer u de standaardcontext van het XAML-schema gebruikt, is die informatie beschikbaar via het XAML-typesysteem. Als u de klassegegevens van het type conversieprogramma nodig hebt op het niveau van de stroom van het XAML-knooppunt voordat u verbinding maakt met een XAML-schrijver, kunt u deze verkrijgen via de XamlMember informatie van het lid dat wordt ingesteld. Maar anders moet de invoer van het type conversieprogramma in de XAML-knooppuntstroom als een gewone waarde worden bewaard totdat de rest van de bewerkingen waarvoor het typetoewijzingssysteem en de XAML-schemacontext zijn vereist, bijvoorbeeld het maken van het object door een XAML-objectschrijver.

Bekijk bijvoorbeeld het volgende overzicht van de klassedefinitie en het XAML-gebruik hiervoor:

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

Een tekstweergave van de XAML-knooppuntstroom voor dit gebruik kan als volgt worden uitgedrukt:

StartObject met XamlType die GameBoard vertegenwoordigen

StartMember met XamlMember die BoardSize vertegenwoordigen

Value knooppunt, met tekenreeks "8x8"

EndMember komt overeen met BoardSize

EndObject komt overeen met GameBoard

U ziet dat er geen type converterexemplaren aanwezig zijn in deze knooppuntstroom. Maar u kunt typeconversiegegevens ophalen door XamlMember.TypeConverter aan te roepen op de XamlMember voor BoardSize. Als u een geldige XAML-schemacontext hebt, kunt u de conversiemethoden ook aanroepen door een exemplaar van ConverterInstancete verkrijgen.

Markeringsextensies in de XAML-knooppuntstroom

Er wordt een gebruik van markeringsuitbreidingen gerapporteerd in de XAML-knooppuntstroom als een objectknooppunt binnen een lid, waarbij het object een exemplaar van de markeringsextensie vertegenwoordigt. Een uitbreidingsgebruik voor markeringen wordt dus expliciet weergegeven in de knooppuntstroomweergave dan het gebruik van een type conversieprogramma en bevat meer informatie. XamlMember informatie had u niets kunnen vertellen over de markeringsextensie, omdat het gebruik situatie is en varieert in elke mogelijke opmaakcase; het is niet toegewezen en impliciet per type of lid zoals het geval is met typeconversieprogramma's.

De knooppuntstroomweergave van markeringsextensies als objectknooppunten is het geval, zelfs als het gebruik van de markeringsextensie is gemaakt in kenmerkvorm in de XAML-tekstmarkeringen (dit is vaak het geval). Gebruik van markeringsuitbreidingen die een formulier voor een expliciet objectelement hebben gebruikt, worden op dezelfde manier behandeld.

Binnen een knooppunt voor markeringsuitbreidingsobjecten zijn er mogelijk leden van die markeringsextensie. De XAML-knooppuntstroomweergave behoudt het gebruik van die markeringsextensie, ongeacht of dit een positioneel parametergebruik is of een gebruik met expliciete benoemde parameters.

Voor het gebruik van positionele parameters bevat de XAML-knooppuntstroom een door de taal gedefinieerde XAML-eigenschap _PositionalParameters waarmee het gebruik wordt vastgelegd. Deze eigenschap is een algemene List<T> met Object beperking. De beperking is object en geen tekenreeks, omdat een positioneel parametergebruik mogelijk geneste markeringsuitbreidingsgebruik bevat. Als u toegang wilt krijgen tot de positionele parameters van het gebruik, kunt u de lijst doorlopen en de indexeerfuncties gebruiken voor afzonderlijke lijstwaarden.

Voor een benoemd parametergebruik wordt elke benoemde parameter weergegeven als lidknooppunt van die naam in de knooppuntstroom. De lidwaarden zijn niet noodzakelijkerwijs tekenreeksen, omdat er mogelijk een geneste markeringsextensie wordt gebruikt.

ProvideValue van de markeringsextensie wordt nog niet aangeroepen. Het wordt echter aangeroepen als u een XAML-lezer en XAML-schrijver verbindt, zodat WriteEndObject wordt aangeroepen op het extensieknooppunt voor markeringen wanneer u deze in de knooppuntstroom onderzoekt. Daarom hebt u over het algemeen dezelfde XAML-schemacontext nodig, zoals zou worden gebruikt om de objectgrafiek op het laadpad te vormen. Anders kan ProvideValue van elke markeringsextensie hier uitzonderingen genereren, omdat er geen verwachte services beschikbaar zijn.

XAML- en XML-Language-Defined leden in de XAML-knooppuntstroom

Bepaalde leden worden geïntroduceerd in een XAML-knooppuntstroom vanwege interpretaties en conventies van een XAML-lezer, in plaats van via een expliciete XamlMember opzoeken of bouwen. Deze leden zijn vaak XAML-richtlijnen. In sommige gevallen is het het lezen van de XAML die de richtlijn introduceert in de XAML-knooppuntstroom. Met andere woorden, de oorspronkelijke invoer XAML-tekst heeft niet expliciet de lidrichtlijn opgegeven, maar de XAML-lezer voegt de richtlijn in om te voldoen aan een structurele XAML-conventie en rapportinformatie in de XAML-knooppuntstroom voordat deze informatie verloren gaat.

In de volgende lijst worden alle gevallen vermeld waarin een XAML-lezer naar verwachting een XAML-lidknooppunt introduceert en hoe dat lidknooppunt wordt geïdentificeerd in .NET XAML Services-implementaties.

initialisatietekst voor een objectknooppunt: De naam van dit lidknooppunt is _Initialization, vertegenwoordigt deze een XAML-instructie en wordt gedefinieerd in de XAML-taal XAML-naamruimte. U kunt er een statische entiteit voor ophalen uit Initialization.
Positionele parameters voor een markeringsextensie: De naam van dit lidknooppunt is _PositionalParametersen is gedefinieerd in de XAML-taal XAML-naamruimte. Het bevat altijd een algemene lijst met objecten, die elk een positionele parameter vooraf is gescheiden door te splitsen op het , scheidingsteken zoals opgegeven in de invoer XAML. U kunt een statische entiteit ophalen voor de instructie positionele parameters van PositionalParameters.
Onbekende inhoud: De naam van dit lidknooppunt is _UnknownContent. Strikt genomen is het een XamlDirectiveen wordt deze gedefinieerd in de XAML-taal XAML-naamruimte. Deze richtlijn wordt gebruikt als een sentinel voor gevallen waarin een XAML-objectelement inhoud bevat in de bron-XAML, maar er kan geen inhoudseigenschap worden bepaald onder de momenteel beschikbare XAML-schemacontext. U kunt dit geval detecteren in een XAML-knooppuntstroom door te controleren op leden met de naam _UnknownContent. Als er geen andere actie wordt ondernomen in een XAML-knooppuntstroom van een laadpad, wordt de standaard-XamlObjectWriter uitgevoerd op geprobeerde WriteEndObject wanneer het _UnknownContent lid op een object tegenkomt. De standaard-XamlXmlWriter genereert niet en behandelt het lid als impliciet. U kunt een statische entiteit voor _UnknownContent ophalen uit UnknownContent.
eigenschap Verzameling van een verzameling: Hoewel het type backing CLR van een verzamelingsklasse die wordt gebruikt voor XAML meestal een toegewezen benoemde eigenschap bevat die de verzamelingsitems bevat, is die eigenschap niet bekend bij een XAML-typesysteem voordat de oplossing van het type back-up wordt gemaakt. In plaats daarvan introduceert de XAML-knooppuntstroom een tijdelijke aanduiding voor Items als lid van het XAML-type verzameling. In .NET XAML Services-implementatie wordt de naam van deze richtlijn of het lid in de knooppuntstroom _Items. Een constante voor deze richtlijn kan worden verkregen uit Items.

Houd er rekening mee dat een XAML-knooppuntstroom een eigenschap Items kan bevatten met items die niet kunnen worden geparseerbaar op basis van de resolutie van het back-uptype en de XAML-schemacontext. Bijvoorbeeld
xml-gedefinieerde leden: De xml-gedefinieerde xml:base, xml:lang en xml:space leden worden gerapporteerd als XAML-instructies met de naam base, langen space in .NET XAML Services-implementaties. De naamruimte hiervoor is de XML-naamruimte http://www.w3.org/XML/1998/namespace. Constanten voor elk van deze kunnen worden verkregen uit XamlLanguage.

Knooppuntvolgorde

In sommige gevallen wijzigt XamlXmlReader de volgorde van XAML-knooppunten in de XAML-knooppuntstroom, versus de volgorde waarin de knooppunten worden weergegeven in de markering of als ze zijn verwerkt als XML. Dit wordt gedaan om de knooppunten zodanig te orden dat een XamlObjectWriter de knooppuntstroom op een voorwaartse manier kan verwerken. In .NET XAML Services herschikt de XAML-lezer de volgorde van knooppunten in plaats van deze taak over te laten aan de XAML-schrijver, als prestatieoptimalisatie voor gebruikers van de XAML-objectschrijver van de knooppuntstroom.

Bepaalde richtlijnen zijn specifiek bedoeld om meer informatie te verstrekken voor het maken van een object van een objectelement. Deze richtlijnen zijn: Initialization, PositionalParameters, TypeArguments, FactoryMethod, Arguments. .NET XAML Services XAML-lezers proberen deze instructies te plaatsen als de eerste leden in de knooppuntstroom na de StartObjectvan een object, om redenen die in de volgende sectie worden uitgelegd.

Gedrag en knooppuntvolgorde van XamlObjectWriter

StartObject aan een XamlObjectWriter is niet noodzakelijkerwijs een signaal voor de XAML-objectschrijver om onmiddellijk het objectexemplaren te maken. XAML bevat verschillende taalfuncties waarmee u een object met extra invoer kunt initialiseren en niet volledig afhankelijk bent van het aanroepen van een parameterloze constructor om het oorspronkelijke object te produceren en alleen vervolgens eigenschappen in te stellen. Deze functies omvatten: XamlDeferLoadAttribute; initialisatietekst; x:TypeArguments; positionele parameters van een markeringsextensie; factory-methoden en bijbehorende x:Arguments knooppunten (XAML 2009). Elk van deze gevallen vertraagt de daadwerkelijke objectconstructie en omdat de knooppuntstroom opnieuw is gerangschikt, kan de XAML-objectschrijver vertrouwen op een gedrag van het daadwerkelijk samenstellen van het exemplaar wanneer een beginlid wordt aangetroffen dat niet specifiek een bouwrichtlijn voor dat objecttype is.

GetObject

GetObject vertegenwoordigt een XAML-knooppunt waarbij in plaats van een nieuw object te maken, een XAML-objectschrijver in plaats daarvan de waarde van de eigenschap met het object moet ophalen. Een typisch geval waarin een GetObject knooppunt wordt aangetroffen in een XAML-knooppuntstroom, is voor een verzamelingsobject of een woordenlijstobject, wanneer de met deze eigenschap opzettelijk alleen-lezen is in het objectmodel van het backing-type. In dit scenario wordt de verzameling of woordenlijst vaak gemaakt en geïnitialiseerd (meestal leeg) door de initialisatielogica van een type eigenaar.

Delen via