Struktury i pojęcia dotyczące strumienia węzłów XAML

Czytniki XAML i składniki zapisywania XAML implementowane w usługach XAML platformy .NET są oparte na koncepcji projektowania strumienia węzła XAML. Strumień węzła XAML to koncepcyjna koncepcja zestawu węzłów XAML. W tej koncepcji procesor XAML przechodzi przez strukturę relacji węzłów w języku XAML pojedynczo. W dowolnym momencie w otwartym strumieniu węzła XAML istnieje tylko jeden bieżący rekord lub bieżąca pozycja, a wiele aspektów raportu interfejsu API zawiera tylko informacje dostępne z tej pozycji. 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ła XAML, czytelnicy XAML mogą komunikować się z składnikami zapisywania XAML i umożliwić programowi wyświetlanie, interakcję lub zmienianie zawartości strumienia węzła XAML podczas ścieżki ładowania lub operacji zapisywania ścieżki, która obejmuje XAML. Projekt interfejsu API czytnika i modułu zapisywania XAML oraz koncepcja strumienia węzłów XAML są podobne do poprzednich projektów i koncepcji czytników i składników zapisywania, takich jak model obiektów dokumentów XML (DOM) i XmlReader 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 cechy i ograniczenia źródła danych wejściowych dla języka XAML. Na przykład element XamlObjectReader odczytuje graf obiektu, zaczynając od źródła wejściowego pojedynczego obiektu reprezentującego element główny lub podstawowy. Następnie XamlObjectReader tworzy strumień węzła XAML z grafu obiektu.

Najbardziej widoczną podklasą zdefiniowaną przez usługi XamlReader XAML platformy .NET jest XamlXmlReader. XamlXmlReader ładuje początkowy kod XAML, ładując plik tekstowy bezpośrednio za pośrednictwem strumienia lub ścieżki pliku albo pośrednio za pośrednictwem powiązanej klasy czytnika, takiej jak TextReader. Element XamlReader może być uważany za zawierający całą część źródła wejściowego XAML po załadowaniu. XamlReader Jednak podstawowy interfejs API został zaprojektowany tak, aby czytelnik wchodził w interakcję z jednym węzłem XAML. Po pierwszym załadowaniu pierwszy napotkany pojedynczy węzeł jest katalogiem głównym kodu XAML i jego obiektem początkowym.

Koncepcja strumienia węzła XAML

Jeśli znasz bardziej dom, metaforę drzewa lub oparte na zapytaniach podejście do uzyskiwania dostępu do technologii opartych na formacie XML, przydatnym sposobem koncepcyjnego koncepcyjnego przesyłania strumieniowego węzła XAML jest następujący sposób. Wyobraź sobie, że załadowany kod XAML jest modelem DOM lub drzewem, w którym każdy możliwy węzeł jest rozwijany w sposób liniowy, a następnie przedstawiany liniowo. W miarę przechodzenia przez węzły można przechodzić "w" lub "poza" poziomów, które byłyby istotne dla modelu DOM, ale strumień węzła XAML nie jest jawnie śledzone, ponieważ te pojęcia na poziomie nie są istotne dla strumienia węzła. Strumień węzła ma "bieżącą" pozycję, ale jeśli nie zapisano innych części strumienia samodzielnie jako odwołania, każdy aspekt strumienia węzła inny niż bieżące położenie węzła jest poza widokiem.

Koncepcja strumienia węzłów XAML ma godną uwagi zaletę, że jeśli przejdziesz przez cały strumień węzłów, masz pewność, że przetworzyno całą reprezentację XAML; Nie musisz martwić się, że zapytanie, operacja DOM lub inne nieliniowe podejście do przetwarzania informacji nie przegapiło części pełnej reprezentacji XAML. Z tego powodu reprezentacja strumienia węzła XAML jest idealna zarówno do łączenia czytników XAML i składników zapisywania XAML, jak i do udostępniania 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 zoptymalizowana lub zmieniana przez czytniki XAML w porównaniu z kolejnością wyświetlania kolejności w tekście źródłowym, binarnym lub grafie obiektów. To zachowanie ma na celu wymuszenie architektury przetwarzania XAML, w której składniki zapisywania XAML nigdy nie znajdują się w sytuacji, w której muszą wrócić do strumienia węzła. Najlepiej, aby wszystkie operacje zapisu XAML mogły działać na podstawie kontekstu schematu oraz bieżącej pozycji strumienia węzłów.

Podstawowa pętla węzła odczytu

Podstawowa pętla węzła odczytu do badania strumienia węzła XAML składa się z następujących pojęć. Na potrzeby pętli węzłów, jak opisano w tym temacie, załóżmy, że czytasz tekstowy plik XAML czytelny dla człowieka przy użyciu polecenia XamlXmlReader. Linki w tej sekcji odnoszą się do określonego 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 (sprawdź IsEof, lub użyj wartości zwracanej Read ). Jeśli jesteś na końcu strumienia, nie ma bieżącego węzła i należy zamknąć.

• Sprawdź, jakiego typu węzeł obecnie uwidacznia strumień węzła XAML, wywołując polecenie NodeType.

• Jeśli masz skojarzony moduł zapisywania obiektów XAML, który jest połączony bezpośrednio, zazwyczaj wywołujesz WriteNode w tym momencie.

• Na podstawie tego, który XamlNodeType jest zgłaszany jako bieżący węzeł lub bieżący rekord, wywołaj jeden z następujących elementów, aby uzyskać informacje o zawartości węzła:

  • W przypadku elementu NodeTypeStartMember lub EndMemberwywołaj metodę Member , aby uzyskać XamlMember informacje o elemencie członkowskim. Element członkowski może być elementem XamlDirective, a tym samym nie musi być konwencjonalnym elementem członkowskim zdefiniowanym przez typ poprzedniego obiektu. Na przykład x:Name zastosowanie do obiektu jest wyświetlane jako element członkowski XAML, gdzie IsDirective jest prawdziwe, a element Name członkowski to Name, z innymi właściwościami wskazującymi, że ta dyrektywa znajduje się w przestrzeni nazw XAML języka XAML.

  • W przypadku elementu NodeTypeStartObject lub EndObjectwywołaj metodę Type , aby uzyskać XamlType informacje o obiekcie.

  • W przypadku elementu wywołaj metodę NodeTypeValueValue. Węzeł jest wartością tylko wtedy, gdy jest najprostszym wyrażeniem wartości elementu członkowskiego lub tekstem inicjowania obiektu (należy jednak pamiętać o zachowaniu konwersji typu, jak opisano w następnej sekcji tego tematu).

  • W przypadku elementu wywołaj metodę NodeTypeNamespaceDeclarationNamespace , aby uzyskać informacje o przestrzeni nazw dla węzła przestrzeni nazw.

• Wywołaj metodę Read , aby przejść do następnego węzła czytnika XAML w strumieniu węzła XAML i powtórzyć kroki ponownie.

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

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

Najprostsza pętla korzystająca z czytnika i składnika zapisywania 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ła XAML ścieżki ładowania w sposób przezroczysty łączy czytnik XAML i składnik zapisywania XAML, co nie różni się od używanego elementu XamlServices.Parse. Jednak ta podstawowa struktura jest następnie rozszerzana w celu zastosowania do scenariusza odczytu lub zapisu. Niektóre możliwe scenariusze są następujące:

• Włącz opcję NodeType. Wykonywanie różnych akcji w zależności od typu węzła, który jest odczytywany.

• Nie należy wywoływać WriteNode we wszystkich przypadkach. Wywołaj tylko WriteNode w niektórych NodeType przypadkach.

• W ramach logiki dla określonego typu węzła przeanalizuj szczegóły tego węzła i wykonaj na nich działania. Można na przykład zapisywać tylko obiekty pochodzące z określonej przestrzeni nazw XAML, a następnie usuwać lub odroczyć wszystkie obiekty nie z tej przestrzeni nazw XAML. Możesz też usunąć lub w inny sposób ponownie przetworzyć wszelkie dyrektywy XAML, które system XAML nie obsługuje w ramach przetwarzania składowych.

• Zdefiniuj niestandardowy obiekt XamlObjectWriter , który zastępuje Write* metody, prawdopodobnie wykonując mapowanie typów, które pomija kontekst schematu XAML.

• Skonstruuj XamlXmlReader element , aby używać kontekstu schematu XAML, tak aby dostosowane różnice w zachowaniu XAML były używane zarówno przez czytelnika, jak i moduł zapisywania.

Uzyskiwanie dostępu do kodu XAML poza koncepcją pętli węzła

Istnieją potencjalnie inne sposoby pracy z reprezentacją XAML inną niż pętla węzła XAML. Na przykład może istnieć czytnik XAML, który może odczytać indeksowany węzeł lub w szczególności uzyskuje dostęp do węzłów bezpośrednio przez x:Name, przez x:Uid, lub za pośrednictwem innych identyfikatorów. Usługi XAML platformy .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 tematy IXamlIndexingReader oraz XamlNodeList.

Praca z bieżącym węzłem

Większość scenariuszy korzystających z pętli węzła XAML nie tylko odczytuje węzły. Większość scenariuszy przetwarza bieżące węzły i przekazuje każdy węzeł pojedynczo do implementacji programu XamlWriter.

W typowym scenariuszu ścieżki obciążenia generuje XamlXmlReader strumień węzła XAML; węzły XAML są przetwarzane zgodnie z logiką i kontekstem schematu XAML, a węzły są przekazywane do XamlObjectWriterelementu . Następnie integrujesz wynikowy graf obiektu z aplikacją lub strukturą.

W typowym scenariuszu ścieżki zapisywania wykres XamlObjectReader obiektu odczytuje poszczególne węzły XAML są przetwarzane, a XamlXmlWriter dane wyjściowe serializowanego wyniku jako plik tekstowy XAML. Kluczem jest to, że obie ścieżki i scenariusze obejmują pracę z dokładnie jednym węzłem XAML w danym momencie, a węzły XAML są dostępne do leczenia w ustandaryzowany sposób zdefiniowany przez system typów XAML i the.NET interfejsów API usług XAML.

Ramki i zakres

Pętla węzła 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 itd. Często warto śledzić zakres w strumieniu węzła XAML przez zaimplementowanie koncepcji ramki i stosu. Jest to szczególnie istotne w przypadku aktywnego dostosowywania strumienia węzła podczas jego pracy. Obsługa ramki i stosu zaimplementowana w ramach logiki pętli węzłów może zliczyć StartObject (lub GetObject) i EndObject zakresy po zejściu do struktury węzła XAML, jeśli struktura jest uważana z perspektywy MODELU DOM.

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

Pierwszy węzeł w strumieniu węzła, który jest 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 zdefiniowany tak, aby miał co najmniej jedną 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ą następnie co najmniej jeden węzeł obiektu lub mogą również zakończyć działanie w węźle wartości. Obiekt główny zwykle definiuje zakresy nazw XAML, które są syntaktycznie przypisywane jako atrybuty w znaczniku tekstu XAML, ale są mapowane na Namescope 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 wspierany przez istniejące typy na platformie .NET). Załóżmy, FavorCollection że w tym modelu obiektów element ma List<T> wartość BalloonFavori NoiseMaker można go przypisać do Favorelementu , Balloon.Color właściwość jest wspierana przez Color obiekt podobny do sposobu, w jaki WPF definiuje kolory jako znane nazwy kolorów i Color obsługuje konwerter typów dla składni atrybutów.

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

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

• Namespace Jeśli węzeł istnieje, jest dodawany do strumienia bezpośrednio przed StartObject zadeklarowaną przestrzenią nazw XAML za pomocą polecenia xmlns. Ponownie przyjrzyj się poprzedniej tabeli ze strumieniem XAML i przykładowym węzłem. 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 zachowanie, w którym węzły przestrzeni nazw zawsze pojawiają się przed węzłem, do którego mają zastosowanie w strumieniu węzła. Celem tego projektu jest to, że informacje o przestrzeni nazw są istotne dla składników zapisywania obiektów i muszą być znane przed próbą wykonania mapowania typów przez składnik zapisywania obiektów lub przetworzenia obiektu w inny sposób. Umieszczenie informacji o przestrzeni nazw XAML przed zakresem aplikacji w strumieniu ułatwia zawsze przetwarzanie strumienia węzła w przedstawionej kolejności.

• Z powodu powyższego zagadnienia jest to jeden lub więcej Namespace węzłów, które odczytujesz jako pierwszy w większości rzeczywistych przypadków znaczników podczas przechodzenia węzłów od początku, a nie StartObject katalogu głównego.

• Po StartObject węźle można wykonać instrukcje StartMember, Valuelub bezpośrednio EndObject. Nigdy nie następuje natychmiast po innej StartObject.

• Po StartMember obiekcie można wykonać instrukcje StartObject, Valuelub bezpośrednio EndMember. Po nim można wykonać polecenie GetObject, dla elementów członkowskich, w których wartość ma pochodzić z istniejącej wartości obiektu nadrzędnego, a nie elementu StartObject , który utworzy wystąpienie nowej wartości. Można go również obserwować za węzłem Namespace , który ma zastosowanie do nadchodzącego StartObjectelementu . Nigdy nie następuje natychmiast po innej StartMember.

• Węzeł Value reprezentuje samą wartość; nie ma wartości "EndValue". Można go śledzić tylko za pomocą .EndMember

  • Tekst inicjowania XAML obiektu, który może być używany przez konstrukcję, nie powoduje struktury Object-Value. Zamiast tego jest tworzony dedykowany węzeł członkowski o nazwie _Initialization . i ten węzeł członkowski zawiera ciąg wartości inicjowania. Jeśli istnieje, _Initialization jest zawsze pierwszym StartMemberelementem . _Initialization może być kwalifikowana w niektórych reprezentacjach usług XAML z zakresem nazw XAML języka XAML, aby wyjaśnić, że _Initialization nie jest zdefiniowaną właściwością w typach kopii zapasowych.

  • Kombinacja wartości składowej reprezentuje ustawienie atrybutu wartości. W końcu może istnieć konwerter wartości zaangażowany w przetwarzanie tej wartości, a wartość jest zwykłym ciągiem. Nie jest to jednak oceniane, dopóki moduł zapisywania obiektów XAML nie przetworzy tego strumienia węzła. Składnik zapisywania obiektów XAML posiada niezbędny kontekst schematu XAML, mapowanie systemu typów i inną obsługę wymaganą do konwersji wartości.

• Po EndMember węźle można utworzyć StartMember węzeł dla kolejnego elementu członkowskiego lub EndObject przez węzeł właściciela elementu członkowskiego.

• Po EndObject węźle EndMember można śledzić węzeł. Można go również obserwować w StartObject węźle w przypadku, gdy obiekty są elementami równorzędnymi w elementach kolekcji. Można też wykonać po węźle Namespace , który ma zastosowanie do nadchodzącego StartObjectelementu .

  • W przypadku unikatowego przypadku zamknięcia całego strumienia węzła element EndObject główny nie jest po nim śledzony; czytnik jest teraz zakończony Read i zwraca wartość false.

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

Konwerter wartości jest ogólnym terminem dla rozszerzenia znaczników, konwertera typów (w tym serializacji 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 mają bardzo różne reprezentacje.

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

Zestaw atrybutów, który ostatecznie powoduje użycie konwertera typów, jest zgłaszany w strumieniu węzła XAML jako wartość elementu członkowskiego. Strumień węzła XAML nie próbuje utworzyć obiektu wystąpienia konwertera typów i przekazać do niego wartość. Użycie 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 typów powinna być używana do przetwarzania wartości, wymaga pośrednio kontekstu schematu XAML. Jeśli używasz 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 z modułem zapisywania XAML, możesz uzyskać je z XamlMember informacji o ustawianym elemencie członkowskim. W przeciwnym razie dane wejściowe konwertera typów powinny być zachowywane w strumieniu węzła XAML jako zwykła wartość do czasu zakończenia pozostałych operacji, które wymagają systemu mapowania typów i kontekstu schematu XAML są wykonywane, na przykład tworzenie obiektu przez moduł zapisywania obiektów XAML.

Rozważmy na przykład następujący konspekt definicji klasy i użycie kodu 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"/>

Tekstowa reprezentacja strumienia węzła XAML dla tego użycia może być wyrażona jako następująca:

StartObjectz reprezentacją XamlTypeGameBoard

StartMemberz reprezentacją XamlMemberBoardSize

Value węzeł z ciągiem tekstowym "8x8"

EndMember Pasuje BoardSize

EndObject Pasuje GameBoard

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

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 elemencie członkowskim, gdzie obiekt reprezentuje wystąpienie rozszerzenia znaczników. W związku z tym użycie rozszerzenia znaczników jest prezentowane bardziej jawnie w reprezentacji strumienia węzła niż użycie konwertera typów i zawiera więcej informacji. XamlMember nie można powiedzieć nic o rozszerzeniu znaczników, ponieważ użycie jest sytuacyjne i różni się w każdym możliwym przypadku narzutu; nie jest dedykowany i niejawny dla typu lub elementu członkowskiego, tak jak w przypadku konwerterów typów.

Strumień węzła reprezentacja rozszerzeń znaczników jako węzłów obiektów jest przypadek, nawet jeśli użycie rozszerzenia znaczników zostało wykonane w postaci atrybutu w adiustacji tekstu XAML (co jest często przypadkiem). Użycie rozszerzeń znaczników, które używały jawnego formularza elementu obiektu, są traktowane w ten sam sposób.

W węźle obiektu rozszerzenia znaczników mogą istnieć 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 parametrów pozycyjnych, czy użycie z jawnie nazwanymi parametrami.

W przypadku użycia parametrów pozycyjnych strumień węzła XAML zawiera właściwość _PositionalParameters zdefiniowaną w języku XAML, która rejestruje użycie. Ta właściwość jest ogólna List<T> z Object ograniczeniem. Ograniczenie to obiekt, a nie ciąg, ponieważ prawdopodobnie użycie parametrów pozycyjnych może zawierać użycie zagnieżdżonych rozszerzeń znaczników w nim. Aby uzyskać dostęp do parametrów pozycyjnych z użycia, możesz wykonać iterację po liście i użyć 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 tej nazwy w strumieniu węzła. Wartości składowe nie muszą być ciągami, ponieważ może istnieć użycie rozszerzenia znaczników zagnieżdżonych.

ProvideValue z rozszerzenia znaczników nie jest jeszcze wywoływany. Jest on jednak wywoływany, jeśli połączysz czytnik XAML i składnik zapisywania XAML tak, aby WriteEndObject 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 kontekst schematu XAML, który będzie używany w celu utworzenia grafu obiektów na ścieżce ładowania. W przeciwnym razie z dowolnego rozszerzenia znaczników może zgłaszać wyjątki, ProvideValue ponieważ nie ma on oczekiwanych usług dostępnych.

Elementy członkowskie zdefiniowane w języku XAML i XML w strumieniu węzła XAML

Niektóre elementy członkowskie są wprowadzane do strumienia węzła XAML ze względu na interpretacje i konwencje czytnika XAML, a nie za pomocą jawnego XamlMember wyszukiwania lub konstrukcji. Często te elementy członkowskie są dyrektywami XAML. W niektórych przypadkach jest to czynność odczytywania kodu XAML, która wprowadza dyrektywę do strumienia węzła XAML. Innymi słowy, oryginalny tekst wejściowy XAML nie określił jawnie dyrektywy składowej, ale czytnik XAML wstawia dyrektywę w celu spełnienia strukturalnej konwencji XAML i informacji o raporcie w strumieniu węzła XAML przed utratą tych informacji.

Poniższa lista zawiera informacje o wszystkich przypadkach, w których oczekuje się, że czytnik XAML wprowadzi węzeł członkowski dyrektywy XAML oraz sposób identyfikowania tego węzła członkowskiego we wdrożeniach usług XAML platformy .NET.

• Tekst inicjowania 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 pobrać dla niej jednostkę statyczną z witryny Initialization.

• Parametry pozycyjne dla rozszerzenia znaczników: nazwa tego węzła członkowskiego to _PositionalParameters, i jest ona zdefiniowana w przestrzeni nazw XAML języka XAML. Zawsze zawiera ogólną listę obiektów, z których każdy jest wstępnie oddzielony pozycyjnym parametrem, dzieląc , znak ogranicznika, jak podano w wejściowym kodzie XAML. Możesz uzyskać jednostkę statyczną dla dyrektywy parametrów pozycyjnych z witryny PositionalParameters.

• Nieznana zawartość: nazwa tego węzła elementu członkowskiego to _UnknownContent. Ściśle rzecz biorąc, jest to element XamlDirective, który jest 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 kontekście schematu XAML aktualnie dostępnego. Ten przypadek można wykryć w strumieniu węzła XAML, sprawdzając pod kątem elementów członkowskich o nazwie _UnknownContent. Jeśli w strumieniu węzła XAML ścieżki obciążenia nie zostanie podjęta żadna inna akcja, domyślna XamlObjectWriter wartość zgłasza próbę WriteEndObject napotkania _UnknownContent elementu członkowskiego na dowolnym obiekcie. Wartość domyślna XamlXmlWriter nie jest zgłaszana i traktuje element członkowski jako niejawny. Możesz pobrać jednostkę statyczną dla elementu _UnknownContent z pliku UnknownContent.

• Właściwość kolekcji kolekcji: mimo że typ kopii zapasowej CLR klasy kolekcji używanej dla języka XAML zwykle ma dedykowaną właściwość nazwaną, która zawiera elementy kolekcji, ta właściwość nie jest znana systemowi typów XAML przed rozpoznawaniem typu kopii zapasowej. Zamiast tego strumień węzła XAML wprowadza Items symbol zastępczy jako element członkowski typu XAML kolekcji. W implementacji usług XAML platformy .NET nazwa tej dyrektywy lub elementu członkowskiego w strumieniu węzła to _Items. Stała dla tej dyrektywy można uzyskać z Items.

  Należy pamiętać, że strumień węzła XAML może zawierać właściwość Items z elementami, które nie mogą być analizowalne na podstawie rozdzielczości typu kopii zapasowej i kontekstu schematu XAML. Przykład:

• Elementy członkowskie zdefiniowane przez kod XML: zdefiniowane przez xml:basexml:lang xml elementy członkowskie xml:space są zgłaszane jako dyrektywy XAML o nazwach base, langi space w implementacjach usług XAML platformy .NET. Przestrzeń nazw dla nich to przestrzeń nazw http://www.w3.org/XML/1998/namespaceXML . Stałe dla każdego z nich można uzyskać z XamlLanguage.

Kolejność węzłów

W niektórych przypadkach XamlXmlReader zmienia kolejność węzłów XAML w strumieniu węzłów XAML, a kolejność, w przypadku wyświetlenia węzłów w adiustacji lub przetworzenia jako XML. Jest to wykonywane w celu uporządkowania węzłów tak, aby XamlObjectWriter umożliwić przetwarzanie strumienia węzła w sposób tylko do przodu. W usługach XAML platformy .NET czytnik XAML zmienia kolejność węzłów, a nie pozostawia tego zadania składnikowi zapisywania XAML jako optymalizacji wydajności składników zapisywania obiektów XAML odbiorców strumienia węzła.

Niektóre dyrektywy mają na celu dostarczenie dodatkowych informacji na temat tworzenia obiektu z elementu obiektu. Te dyrektywy to: Initialization, , TypeArgumentsPositionalParameters, FactoryMethod, Arguments. Czytniki XAML usług .NET XAML próbują umieścić te dyrektywy jako pierwsze elementy członkowskie w strumieniu węzła StartObjectpo obiekcie , z powodów, które zostały wyjaśnione w następnej sekcji.

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

StartObject element nie XamlObjectWriter musi być sygnałem modułu zapisywania obiektów XAML, aby natychmiast skonstruować wystąpienie obiektu. Język XAML zawiera kilka funkcji językowych, które umożliwiają zainicjowanie obiektu z dodatkowymi danymi wejściowymi, a nie poleganie całkowicie na wywoływaniu konstruktora bez parametrów w celu utworzenia obiektu początkowego, a dopiero następnie ustawiania właściwości. Te funkcje obejmują: XamlDeferLoadAttribute; tekst inicjowania; x:TypeArguments; parametry pozycyjne rozszerzenia znaczników; metody fabryczne 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ła jest zmieniany, moduł zapisywania obiektów XAML może polegać na zachowaniu rzeczywistego konstruowania wystąpienia za każdym razem, gdy napotkano element członkowski rozpoczęcia, który nie jest specjalnie dyrektywą budowlaną dla tego typu obiektu.

GetObject

GetObject reprezentuje węzeł XAML, w którym zamiast konstruować nowy obiekt, moduł zapisywania obiektów XAML powinien zamiast tego uzyskać wartość właściwości zawierającej obiekt. Typowy przypadek, w którym GetObject węzeł występuje w strumieniu węzła XAML, dotyczy obiektu kolekcji lub obiektu słownika, gdy właściwość zawierająca jest celowo tylko do odczytu w modelu obiektów typu zapasowego. W tym scenariuszu kolekcja lub słownik często jest tworzona i inicjowana (zwykle pusta) przez logikę inicjowania typu własnego.

Zobacz też

• XamlObjectReader
• Usługi XAML
• Przestrzeń nazw XAML