Struktury i pojęcia strumienia węzłów XAML

Artykuł
07/06/2022
Czas czytania: 18 min

Czytniki XAML i autorzy XAML zaimplementowani w usługach XAML .NET są oparte na koncepcji projektowania strumienia węzłów XAML. Strumień węzłów XAML jest koncepcyjną koncepcją zestawu węzłów XAML. W tej koncepcji procesor XAML przechodzi przez strukturę relacji węzłów w języku XAML po jednym na raz. W dowolnym momencie w otwartym strumieniu węzła XAML istnieje tylko jeden bieżący rekord lub bieżące położenie, a wiele aspektów interfejsu API zgłasza tylko informacje dostępne z tego położenia. Bieżący węzeł w strumieniu węzła XAML można opisać jako obiekt, element członkowski lub wartość. Traktując język XAML jako strumień węzłów XAML, czytelnicy JĘZYKA XAML mogą komunikować się ze autorami XAML i umożliwiać programowi wyświetlanie, interakcję lub zmianę zawartości strumienia węzła XAML podczas ścieżki ładowania lub operacji zapisywania ścieżki, która obejmuje język XAML. Projekt interfejsu API czytnika i zapisu języka XAML oraz koncepcja strumienia węzłów XAML są podobne do poprzednich powiązanych projektów i koncepcji czytnika i zapisu, takich jak xml Document Object Model (DOM) XmlReader oraz klasy i XmlWriter . W tym temacie omówiono pojęcia dotyczące strumienia węzłów XAML i opisano sposób pisania procedur, które współdziałają z reprezentacjami XAML na poziomie węzła XAML.

Ładowanie kodu XAML do czytnika XAML

Klasa bazowa XamlReader nie deklaruje określonej techniki ładowania początkowego kodu XAML do czytnika XAML. Zamiast tego klasa pochodna deklaruje i implementuje technikę ładowania, w tym ogólne właściwości i ograniczenia źródła danych wejściowych dla języka XAML. Na przykład obiekt odczytuje XamlObjectReader wykres obiektu, zaczynając od źródła danych wejściowych pojedynczego obiektu reprezentującego obiekt główny lub podstawowy. Następnie XamlObjectReader tworzy strumień węzła XAML z grafu obiektów.

Najbardziej znaczącą podklasą zdefiniowaną przez usługi XAML XamlReader .NET jest XamlXmlReader. XamlXmlReader ładuje początkowy kod XAML przez załadowanie pliku tekstowego bezpośrednio za pośrednictwem strumienia lub ścieżki pliku albo pośrednio za pośrednictwem powiązanej klasy czytnika, takiej jak TextReader. Można XamlReader ją uważać za zawierającą całe źródło danych wejściowych XAML po jego załadowaniu. Jednak podstawowy interfejs XamlReader API został zaprojektowany tak, aby czytnik wchodził w interakcję z jednym węzłem XAML. Po pierwszym załadowaniu pierwszy pojedynczy węzeł, który napotkasz, to katalog główny XAML i jego obiekt start.

Koncepcja strumienia węzłów XAML

Jeśli znasz już model DOM, metaforę drzewa lub oparte na zapytaniach podejście do uzyskiwania dostępu do technologii opartych na języku XML, przydatnym sposobem na koncepcję strumienia węzłów XAML jest następujący sposób. Imagine, że załadowany kod XAML jest domem lub drzewem, w którym każdy możliwy węzeł jest rozszerzany na całej drodze, a następnie przedstawiany liniowo. W przypadku przechodzenia przez węzły możesz przechodzić przez poziomy "in" lub "out", które byłyby istotne dla modelu DOM, ale strumień węzłów XAML nie jest jawnie śledzone, ponieważ te koncepcje poziomu nie są istotne dla strumienia węzłów. Strumień węzłów ma "bieżącą" pozycję, ale jeśli inne części strumienia nie zostały zapisane samodzielnie jako odwołania, każdy aspekt strumienia węzła inny niż bieżąca pozycja węzła jest poza widokiem.

Koncepcja strumienia węzłów XAML ma tę zaletę, że jeśli przechodzisz przez cały strumień węzłów, masz pewność, że przetworzona została cała reprezentacja XAML; Nie musisz się martwić, że zapytanie, operacja DOM lub inne nieliniowe podejście do przetwarzania informacji pominięto część pełnej reprezentacji XAML. Z tego powodu reprezentacja strumienia węzłów XAML idealnie nadaje się zarówno do łączenia czytników XAML i autorów XAML, jak i do zapewnienia systemu, w którym można wstawić własny proces, który działa między fazami odczytu i zapisu operacji przetwarzania XAML. W wielu przypadkach kolejność węzłów w strumieniu węzłów XAML jest celowo optymalizowana lub zmieniana przez czytniki XAML w porównaniu ze tym, jak kolejność może być wyświetlana w tekście źródłowym, binarnym lub grafie obiektu. To zachowanie ma na celu wymuś architekturę przetwarzania XAML, w której autorzy XAML nigdy nie są w stanie, w którym muszą wrócić do strumienia węzłów. W idealnym przypadku wszystkie operacje zapisu w języku XAML powinny mieć możliwość działania na podstawie kontekstu schematu oraz bieżącej pozycji strumienia węzła.

Podstawowa czytelna Loop

Podstawowa pętla odczytu węzłów do badania strumienia węzłów XAML składa się z następujących pojęć. Na potrzeby pętli węzłów, jak omówiono w tym temacie, załóżmy, że odczytujesz tekstowy, czytelny dla człowieka plik XAML przy użyciu elementu XamlXmlReader. Linki w tej sekcji odnoszą się do konkretnego interfejsu API pętli węzłów XAML zaimplementowanego przez program XamlXmlReader.

Upewnij się, że nie jesteś na końcu strumienia węzła XAML ( IsEofsprawdź lub użyj wartości Read zwracanej). Jeśli jesteś na końcu strumienia, nie ma bieżącego węzła i należy zakończyć pracę.
Sprawdź, jakiego typu węzeł strumień węzła XAML aktualnie uwidacznia, wywołując .NodeType
Jeśli masz skojarzony element zapisujący obiektu XAML, który jest połączony bezpośrednio, zazwyczaj w WriteNode tym momencie jest to wywołanie.
Na podstawie tego, XamlNodeType który jest zgłaszany jako bieżący węzeł lub bieżący rekord, wywołaj jedną z następujących czynności, aby uzyskać informacje o zawartości węzła:
- W przypadku lub NodeType StartMember wywołaj EndMemberwywołanie , Member aby uzyskać XamlMember informacje o członkowskim. Członkiem może być , i XamlDirectivew związku z tym nie musi być konwencjonalnym typem zdefiniowanym członkiem poprzedniego obiektu. Na przykład x:Name zastosowane do obiektu pojawia się jako element członkowski XAML IsDirective , gdzie ma wartość true NameName, a element członkowski ma wartość , z innymi właściwościami wskazującymi, że ta dyrektywa znajduje się w przestrzeni nazw XAML języka XAML.
- W przypadku obiektu StartObject NodeType lub EndObjectwywołaj wywołanie , Type aby uzyskać XamlType informacje o obiekcie.
- W przypadku , NodeType Valuewywołaj .Value Węzeł jest wartością tylko wtedy, gdy jest to najprostsze wyrażenie wartości dla członka lub tekst inicjalizacji obiektu (należy jednak pamiętać o zachowaniu konwersji typu, zgodnie z dokumentacją w kolejnej sekcji tego tematu).
- W przypadku elementu NodeType wywołaj NamespaceDeclarationwywołanie , Namespace aby uzyskać informacje o przestrzeni nazw dla węzła przestrzeni nazw.
Wywołaj Read wywołanie , aby przejść do następnego węzła w strumieniu węzłów XAML, i powtórz te kroki ponownie.

Strumień węzłów XAML dostarczany przez czytniki XAML usług XAML .NET zawsze zapewnia pełne, głębokie przechodzenie wszystkich możliwych węzłów. Typowe techniki sterowania przepływem dla pętli węzłów XAML while (reader.Read())NodeType obejmują definiowanie treści w ramach i włączanie w każdym punkcie węzła w pętli węzłów.

Jeśli strumień węzła znajduje się na końcu pliku, bieżący węzeł ma wartość null.

Najprostsza pętla, która korzysta z czytnika i zapisu, przypomina poniższy przykład.

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

Ten podstawowy przykład pętli węzłów XAML ścieżki ładowania w sposób przezroczysty łączy czytnik XAML i program zapisujący XAML, wykonując nic innego, niż w przypadku, gdy był używany .XamlServices.Parse Jednak ta podstawowa struktura jest następnie rozszerzana w celu zastosowania do scenariusza odczytu lub pisania. Poniżej podano niektóre możliwe scenariusze:

Włącz .NodeType Wykonywanie różnych akcji w zależności od typu węzła, który jest odczytywany.
Nie należy wywołać we WriteNode wszystkich przypadkach. W niektórych przypadkach należy WriteNode wywołać tylko NodeType wywołanie .
W ramach logiki dla określonego typu węzła przeanalizuj szczegółowe informacje o tym węźle i przeanalizuj je. Można na przykład zapisywać tylko obiekty, które pochodzą z określonej przestrzeni nazw XAML, a następnie usunąć lub odroczyć wszystkie obiekty, które nie pochodzą z tej przestrzeni nazw XAML. Można też usunąć lub w inny sposób ponownie przetworzyć dyrektywy XAML, których system XAML nie obsługuje w ramach przetwarzania elementów członkowskich.
Zdefiniuj niestandardowy XamlObjectWriter obiekt, który zastępuje Write* metody, prawdopodobnie wykonując mapowanie typów, które pomija kontekst schematu XAML.
Skonstruuj XamlXmlReader obiekt do używania niedefaultowego kontekstu schematu XAML, tak aby niestandardowe różnice w zachowaniu języka XAML były używane zarówno przez czytelnika, jak i przez autora.

Uzyskiwanie dostępu do kodu XAML poza koncepcją Loop Node

Istnieją potencjalnie inne sposoby pracy z reprezentacją XAML, inne niż pętla węzłów XAML. Na przykład może istnieć czytnik XAML, który może odczytywać indeksowany węzeł lub x:Namew szczególności uzyskuje dostęp do węzłów bezpośrednio przez , przez x:Uidlub za pośrednictwem innych identyfikatorów. Usługi XAML .NET nie zapewniają pełnej implementacji, ale zapewniają sugerowany wzorzec za pośrednictwem usług i typów pomocy technicznej. Aby uzyskać więcej informacji, zobacz IXamlIndexingReader i XamlNodeList.

Praca z bieżącym węzłem

Większość scenariuszy, w których jest pętlę węzłów XAML, nie tylko odczytuje węzły. Większość scenariuszy przetwarza bieżące węzły i po jednym węźle jest przekazywać je do implementacji programu XamlWriter.

W typowym scenariuszu XamlXmlReader ścieżki ładowania obiekt generuje strumień węzłów XAML; węzły XAML są przetwarzane zgodnie z logiką i kontekstem schematu XAML, a węzły są przekazywane do elementu XamlObjectWriter. Następnie zintegruj wynikowy graf obiektów z aplikacją lub platformą.

W typowym scenariuszu XamlObjectReader zapisywania ścieżki obiekt odczytuje wykres obiektów, przetwarzane są poszczególne węzły XAML, a XamlXmlWriter serializowany wynik jest wyprowadzony jako plik tekstowy XAML. Kluczem jest to, że zarówno ścieżki, jak i scenariusze obejmują pracę z dokładnie jednym węzłem XAML na raz, a węzły XAML są dostępne do leczenia w standardowy sposób, który jest definiowany przez system typów XAML i interfejsy API the.NET XAML.

Ramki i zakres

Pętla węzłów XAML przechodzi przez strumień węzła XAML w sposób liniowy. Strumień węzła przechodzi do obiektów, do elementów członkowskich, które zawierają inne obiekty i tak dalej. Często przydatne jest śledzenie zakresu w strumieniu węzła XAML przez zaimplementowanie koncepcji ramki i stosu. Jest to szczególnie istotne, jeśli strumień węzłów jest aktywnie dostosowywany podczas jego pracy. Obsługa ramki StartObject i stosu implementowanie w ramach logiki pętli węzłów może liczyć (lub GetObject) EndObject i zakresy w kolejności malejącej do struktury węzłów XAML, jeśli struktura jest uwzględniana z perspektywy modelu DOM.

Przechodzenie i wprowadzanie węzłów obiektów

Pierwszy węzeł w strumieniu węzła otwierany przez czytnik XAML jest węzłem start-object obiektu głównego. Z definicji ten obiekt jest zawsze pojedynczym węzłem obiektu i nie ma żadnych elementów równorzędnych. W każdym rzeczywistym przykładzie XAML obiekt główny jest definiowany w celu posiadania co najmniej jednej właściwości, która zawiera więcej obiektów, a te właściwości mają węzły członkowskie. Węzły członkowskie mają wtedy co najmniej jeden węzeł obiektu lub mogą również kończyć się w węźle wartości. Obiekt główny zazwyczaj definiuje zakresy nazw XAML, które są przypisywane syntaktycznie jako atrybuty w znacznikach tekstowych XAML Namescope , ale są mapowane na typ węzła w reprezentacji strumienia węzła XAML.

Rozważmy następujący przykład XAML (jest to dowolny kod XAML, który nie jest pozyskany przez istniejące typy na .NET). Załóżmy, FavorCollectionList<T>Favorże w tym modelu obiektów obiekt ma wartość i BalloonFavorNoiseMaker można przypisać do obiektu , Balloon.ColorColor właściwość jest wspierana przez obiekt podobny do tego, w jaki WPF definiuje kolory jako znane nazwy kolorów i Color obsługuje konwerter typów dla składni atrybutów.

Na znacznikach XAML	Wynikowy strumień węzłów XAML
`<Party`	`Namespace` node for `Party`
`xmlns="PartyXamlNamespace">`	`StartObject` node for `Party`
`<Party.Favors>`	`StartMember` node for `Party.Favors`
	`StartObject` węzeł niejawny `FavorCollection`
	`StartMember` node dla właściwości elementów `FavorCollection` niejawnych.
`<Balloon`	`StartObject` node for `Balloon`
`Color="Red"`	`StartMember` node for `Color` `Value` węzeł dla ciągu wartości atrybutu `"Red"` `EndMember` For `Color`
`HasHelium="True"`	`StartMember` node for `HasHelium` `Value` węzeł dla ciągu wartości atrybutu `"True"` `EndMember` For `HasHelium`
`>`	`EndObject` For `Balloon`
`<NoiseMaker>Loudest</NoiseMaker>`	`StartObject` node for `NoiseMaker` `StartMember` node for `_Initialization` `Value` węzeł dla ciągu wartości inicjalizacji `"Loudest"` `EndMember` node for `_Initialization` `EndObject` For `NoiseMaker`
	`EndMember` node dla właściwości elementów `FavorCollection` niejawnych.
	`EndObject` węzeł niejawny `FavorCollection`
`</Party.Favors>`	`EndMember` For `Favors`
`</Party>`	`EndObject` For `Party`

W strumieniu węzła XAML można polegać na następującym zachowaniu:

Jeśli węzeł Namespace istnieje, jest on dodawany do strumienia bezpośrednio przed StartObject zadeklarowaną przestrzenią nazw XAML za pomocą .xmlns Ponownie przyjrzyj się poprzedniej tabeli z kodem XAML i przykładowym strumieniem węzłów. Zwróć uwagę, że StartObject węzły i Namespace wydają się być transponowane w porównaniu z ich pozycjami deklaracji w znacznikach tekstowych. Jest to reprezentatywne dla zachowania, w którym węzły przestrzeni nazw zawsze pojawiają się przed węzłem, do którego mają zastosowanie w strumieniu węzłów. Celem tego projektu jest to, że informacje o przestrzeni nazw są istotne dla autorów obiektów i muszą być znane, zanim autor obiektu spróbuje wykonać mapowanie typu lub w inny sposób przetworzyć obiekt. Umieszczenie informacji o przestrzeni nazw XAML przed zakresem aplikacji w strumieniu ułatwia zawsze przetwarzanie strumienia węzłów w przedstawionej kolejności.
Ze względu na powyższe kwestie jest to co najmniej jeden węzeł, Namespace który jest odczytywany jako pierwszy w większości rzeczywistych przypadków na znacznikach podczas przechodzenia przez węzły od początku, StartObject a nie w katalogu głównym.
Po StartObject węźle może nas nasunić StartMembersię element , Valuelub bezpośrednio EndObject. Po niej nigdy nie następuje kolejny .StartObject
Po StartMember a może nas nasunić StartObjectsię , Valuelub bezpośrednio EndMember. Po nim może nasunić GetObjectsię , dla elementów członkowskich, w których wartość ma pochodzić z istniejącej wartości obiektu nadrzędnego, a StartObject nie elementu , który może utworzyć nową wartość. Po nim może również nasycać Namespace węzeł, który ma zastosowanie do nadchodzącego .StartObject Po niej nigdy nie następuje kolejny .StartMember
Węzeł Value reprezentuje samą wartość; nie ma wartości "EndValue". Po nim może nas tylko nasycją .EndMember
- Tekst inicjalizacji XAML obiektu, który może być używany przez konstrukcję, nie powoduje Object-Value struktury. Zamiast tego jest tworzony dedykowany węzeł członkowski dla członka o nazwie _Initialization . i ten węzeł członkowski zawiera ciąg wartości inicjalizacji. Jeśli istnieje, to _Initialization zawsze pierwszy StartMember. _Initialization Może być kwalifikowana w niektórych reprezentacjach usług XAML za pomocą zakresów nazw JĘZYKA XAML, aby wyjaśnić, _Initialization że nie jest zdefiniowaną właściwością w typach kopii zapasowej.
- Kombinacja Member-Value reprezentuje ustawienie atrybutu wartości. W przetwarzaniu tej wartości może być ostatecznie zaangażowany konwerter wartości, a wartość jest zwykłym ciągiem. Nie jest to jednak oceniane, dopóki autor obiektu XAML nie przetnie tego strumienia węzła. Obiekt zapisujący XAML posiada niezbędny kontekst schematu XAML, mapowanie systemu typów i inną obsługę potrzebną do konwersji wartości.
Po EndMember węźle może nas StartMember następnie znaleźć węzeł dla kolejnego członka lub EndObject węzeł dla właściciela członka.
Po EndObject węźle może nas nasunić się EndMember węzeł. Po nim może być również węzeł w StartObject przypadkach, gdy obiekty są elementami równorzędne w elementach kolekcji. Po nim może też nasycać Namespace węzeł, który ma zastosowanie do nadchodzącego .StartObject
- W przypadku unikatowego EndObject przypadku zamknięcia całego strumienia węzła na końcu katalogu głównego nie ma żadnych śladów; czytnik jest teraz końcem pliku i zwraca Read wartość false.

Konwertery wartości i strumień węzła XAML

Konwerter wartości to ogólny termin rozszerzenia znaczników, konwertera typów (w tym serializatorów wartości) lub innej dedykowanej klasy, która jest zgłaszana jako konwerter wartości za pośrednictwem systemu typów XAML. W strumieniu węzła XAML użycie konwertera typów i użycie rozszerzenia znaczników ma bardzo różne reprezentacje.

Konwertery typów w strumieniu węzła XAML

Zestaw atrybutów, który ostatecznie powoduje użycie konwertera typu, jest raportowany w strumieniu węzła XAML jako wartość elementu członkowskiego. Strumień węzła XAML nie próbuje utworzyć obiektu wystąpienia konwertera typu i przekazać do niego wartość. Korzystanie z implementacji konwersji konwertera typów wymaga wywołania kontekstu schematu XAML i użycia go do mapowania typów. Nawet określenie, która klasa konwertera powinna być używana do przetwarzania wartości, wymaga pośrednio kontekstu schematu XAML. W przypadku korzystania z domyślnego kontekstu schematu XAML te informacje są dostępne w systemie typów XAML. Jeśli potrzebujesz informacji o klasie konwertera typów na poziomie strumienia węzła XAML przed połączeniem ze autorem XAML, XamlMember możesz uzyskać je z informacji o ustawianych członkach. W przeciwnym razie dane wejściowe konwertera typów powinny być zachowywane w strumieniu węzła XAML jako wartość zwykłego elementu do czasu wykonania pozostałych operacji, które wymagają systemu mapowania typów i kontekstu schematu XAML, na przykład tworzenia obiektu przez autora obiektu XAML.

Rozważmy na przykład następujący konspekt definicji klasy i jego użycie w języku XAML:

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

Tekstową reprezentację strumienia węzła XAML dla tego użycia można wyrazić w następujący sposób:

StartObject z XamlType reprezentującą GameBoard

StartMember z XamlMember reprezentującą BoardSize

Value node z ciągiem tekstowym "8x8"

EndMember Pasuje BoardSize

EndObject Pasuje GameBoard

Zwróć uwagę, że w tym strumieniu węzłów nie ma wystąpienia konwertera typów. Można jednak uzyskać informacje o konwerterze typów, wywołując XamlMember.TypeConverter dla XamlMember .BoardSize Jeśli masz prawidłowy kontekst schematu XAML, możesz również wywołać metody konwertera, uzyskanie wystąpienia z klasy ConverterInstance.

Rozszerzenia znaczników w strumieniu węzła XAML

Użycie rozszerzenia znaczników jest zgłaszane w strumieniu węzła XAML jako węzeł obiektu w ramach elementu członkowskiego, gdzie obiekt reprezentuje wystąpienie rozszerzenia znaczników. W związku z tym użycie rozszerzenia znaczników jest bardziej jawnie przedstawione w reprezentacji strumienia węzła niż użycie konwertera typu i zawiera więcej informacji. XamlMember informacje o rozszerzeniu znaczników nie mogły ci nic powiedzieć, ponieważ użycie jest sytuacyjne i różni się w każdym możliwym przypadku na znaczników; Nie jest dedykowany i niejawny dla typu lub członka, jak w przypadku konwerterów typów.

Reprezentacja strumieniowa węzłów rozszerzeń znaczników jako węzłów obiektów ma miejsce nawet wtedy, gdy użycie rozszerzenia znaczników zostało wprowadzone w postaci atrybutu w znaczniku tekstowym XAML (tak często jest). Użycie rozszerzenia znaczników, które używało jawnego formularza elementu obiektu, są traktowane w taki sam sposób.

W węźle obiektu rozszerzenia znaczników mogą być elementy członkowskie tego rozszerzenia znaczników. Reprezentacja strumienia węzła XAML zachowuje użycie tego rozszerzenia znaczników, niezależnie od tego, czy jest to użycie parametru pozyskanego, czy użycie z jawnie nazwanymi parametrami.

W przypadku użycia parametrów pozytkowych strumień węzłów XAML zawiera właściwość języka XAML _PositionalParameters , która rejestruje użycie. Ta właściwość jest ogólną właściwością z List<T> ograniczeniem Object . Ograniczenie jest obiektem, a nie ciągiem, ponieważ prawdopodobnie użycie parametru pozyskanego może zawierać zagnieżdżone użycie rozszerzenia znaczników. Aby uzyskać dostęp do parametrów pozywidalnych z użycia, możesz iterować po liście i używać indeksatorów dla poszczególnych wartości listy.

W przypadku użycia nazwanego parametru każdy nazwany parametr jest reprezentowany jako węzeł członkowski o tej nazwie w strumieniu węzła. Wartości składowych nie muszą być ciągami, ponieważ może być zagnieżdżone użycie rozszerzenia znaczników.

ProvideValue z rozszerzenia znaczników nie jest jeszcze wywoływana. Jest on jednak wywoływany, jeśli połączysz czytnik XAML i program zapisujący XAML WriteEndObject , aby był wywoływany w węźle rozszerzenia znaczników podczas badania go w strumieniu węzła. Z tego powodu zazwyczaj potrzebny jest ten sam dostępny kontekst schematu XAML, który zostałby użyty do formularza grafu obiektów w ścieżce ładowania. W przeciwnym razie ProvideValue z dowolnego rozszerzenia znaczników może zgłaszać wyjątki, ponieważ nie ma on oczekiwanych dostępnych usług.

Elementy członkowskie języków XAML Language-Defined XML w strumieniu węzłów XAML

Niektóre elementy członkowskie są wprowadzane do strumienia węzłów XAML ze względu na interpretacje i konwencje czytnika XAML, a nie za pomocą jawnego XamlMember wyszukiwania lub konstrukcji. Często są to dyrektywy XAML. W niektórych przypadkach jest to działanie odczytywania kodu XAML, który wprowadza dyrektywę do strumienia węzłów XAML. Innymi słowy, oryginalny wejściowy tekst XAML nie został jawnie określony w dyrektywie elementu członkowskiego, ale czytnik XAML wstawia dyrektywę w celu spełnienia strukturalnej konwencji XAML i informacji raportów w strumieniu węzła XAML przed utraconą informacjami.

Na poniższej liście przedstawiono wszystkie przypadki, w których czytelnik XAML powinien wprowadzić dyrektywę węzła członkowskiego XAML i w jaki sposób ten węzeł członkowski jest identyfikowany w implementacjach usług XAML .NET.

Tekst inicjalizacji dla węzła obiektu: Nazwa tego węzła członkowskiego to _Initialization, reprezentuje dyrektywę XAML i jest zdefiniowana w przestrzeni nazw XAML języka XAML. Możesz uzyskać dla niego jednostkę statyczną z adresu Initialization.
Parametry pozyacyjne rozszerzenia znaczników: Nazwa tego węzła członkowskiego to _PositionalParametersi jest zdefiniowana w przestrzeni nazw XAML języka XAML. Zawsze zawiera ogólną listę obiektów, , z których każdy jest parametrem pozyczywczym wstępnie oddzielonym przez podzielenie znaku ogranicznika podanego w wejściowym pliku XAML. Jednostkę statyczną dla dyrektywy parametry pozyacyjne można uzyskać z adresu PositionalParameters.
Nieznana zawartość: Nazwa tego węzła członkowskiego to _UnknownContent. Ściśle rzecz biorąc, jest to , XamlDirectivei jest on zdefiniowany w przestrzeni nazw XAML języka XAML. Ta dyrektywa jest używana jako sentinel w przypadkach, gdy element obiektu XAML zawiera zawartość w źródłowym języku XAML, ale nie można określić właściwości zawartości w ramach aktualnie dostępnego kontekstu schematu XAML. Ten przypadek można wykryć w strumieniu węzła XAML, sprawdzając elementy członkowskie o nazwie _UnknownContent. Jeśli w strumieniu węzła XAML ścieżki ładowania nie jest podejmowana żadna inna akcja, XamlObjectWriterWriteEndObject_UnknownContent domyślną wartością zgłaszaną podczas próby napotkania elementu członkowskiego w dowolnym obiekcie. Wartość domyślna XamlXmlWriter nie zgłasza i traktuje członka jako niejawnego. Jednostkę statyczną dla elementu można uzyskać z _UnknownContent adresu UnknownContent.
Właściwość kolekcji: Mimo że zapasowy typ CLR klasy kolekcji, który jest używany dla języka XAML, ma zwykle dedykowaną nazwaną właściwość, która przechowuje elementy kolekcji, ta właściwość nie jest znana systemowi typów XAML przed rozpoczęciem rozpoznawania typów kopii zapasowej. Zamiast tego strumień węzłów XAML wprowadza symbol zastępczy Items jako element członkowski typu XAML kolekcji. W implementacji usług XAML .NET nazwa tej dyrektywy lub elementu członkowskiego w strumieniu węzłów to _Items. Stałą dla tej dyrektywy można uzyskać z .Items

Należy pamiętać, że strumień węzłów XAML może zawierać właściwość Items z elementami, które okazuje się nie być analizowalne na podstawie rozpoznawania typu zapasowego i kontekstu schematu XAML. Na przykład
Elementy członkowskie zdefiniowane w formacie XML: Elementy członkowskie i zdefiniowane w języku xml:basexml:langxml:space XML są zgłaszane jako dyrektywy XAML o nazwie base, langi w space implementacjach usług XAML .NET. Przestrzeń nazw jest przestrzenią nazw XML http://www.w3.org/XML/1998/namespace. Stałe dla każdego z nich można uzyskać z .XamlLanguage

Kolejność węzłów

W niektórych przypadkach zmienia XamlXmlReader się kolejność węzłów XAML w strumieniu węzłów XAML w porównaniu z kolejnością, w których węzły są wyświetlane w znacznikach lub przetwarzane w formacie XML. Odbywa się to w celu uporządkowania węzłów w taki sposób, aby strumień XamlObjectWriter węzłów był przetwarzany tylko do przodu. W usługach XAML .NET czytnik XAML zmienia kolejność węzłów, zamiast pozostawiać to zadanie autorowi XAML jako optymalizację wydajności dla odbiorców zapisujących obiekty XAML strumienia węzłów.

Niektóre dyrektywy są przeznaczone specjalnie do zapewnienia więcej informacji na temat tworzenia obiektu z elementu obiektu. Te dyrektywy to: Initialization, PositionalParameters, TypeArguments, FactoryMethod, . Arguments Czytelnicy xaml usług XAML StartObject.NET próbują umieścić te dyrektywy jako pierwsze elementy członkowskie w strumieniu węzła po obiekcie , z przyczyn, które zostały wyjaśnione w następnej sekcji.

Zachowanie XamlObjectWriter i kolejność węzłów

StartObject do a XamlObjectWriter nie musi być sygnałem dla obiektu zapisujący XAML do natychmiastowego konstruowania wystąpienia obiektu. Język XAML zawiera kilka funkcji języka, które umożliwia zainicjowanie obiektu z dodatkowymi elementami wejściowymi i nie poleganie całkowicie na wywołaniach bez parametrów konstruktora w celu utworzenia początkowego obiektu, a dopiero następnie na ustawieniu właściwości. Te funkcje obejmują: XamlDeferLoadAttribute; tekst inicjalizacji; x:TypeArguments; parametry pozyacyjne rozszerzenia znaczników; metody factory i skojarzone węzły x:Arguments (XAML 2009). Każdy z tych przypadków opóźnia rzeczywistą konstrukcję obiektu, a ponieważ strumień węzłów jest zmieniany, autor obiektu XAML może polegać na zachowaniu rzeczywistego konstruowania wystąpienia za każdym razem, gdy napotkany zostanie startowy członek, który nie jest dyrektywą konstrukcji dla tego typu obiektu.

GetObject

GetObject reprezentuje węzeł XAML, gdzie zamiast konstruowania nowego obiektu, a zamiast tego autor obiektu XAML powinien uzyskać wartość właściwości zawierającej obiekt. Typowy przypadek GetObject napotkania węzła w strumieniu węzła XAML dotyczy obiektu kolekcji lub obiektu słownika, gdy zawierająca właściwość jest celowo tylko do odczytu w modelu obiektów typu zapasowego. W tym scenariuszu kolekcja lub słownik jest często tworzona i inicjowana (zazwyczaj pusta) przez logikę inicjowania typu właściciel.