다음을 통해 공유


XAML 노드 스트림 구조 및 개념

.NET XAML 서비스에서 구현된 XAML 판독기 및 XAML 작성기는 XAML 노드 스트림의 디자인 개념을 기반으로 합니다. XAML 노드 스트림은 XAML 노드 집합의 개념화입니다. 이 개념화에서 XAML 프로세서는 XAML에서 노드 관계의 구조를 한 번에 하나씩 안내합니다. 언제든지 열려 있는 XAML 노드 스트림에 현재 레코드 또는 현재 위치가 하나만 존재하며, API 보고서의 여러 측면은 해당 위치에서 사용할 수 있는 정보만 보고합니다. XAML 노드 스트림의 현재 노드는 개체, 멤버 또는 값으로 설명할 수 있습니다. XAML을 XAML 노드 스트림으로 처리하면 XAML 판독기는 XAML 작성기와 통신하고, 로드 경로 또는 XAML과 관련된 경로 저장 작업 중에 프로그램이 XAML 노드 스트림의 내용을 보거나 상호 작용하거나 변경할 수 있도록 할 수 있습니다. XAML 판독기 및 기록기 API 디자인 및 XAML 노드 스트림 개념은 XML DOM(문서 개체 모델) 및 XmlReaderXmlWriter 클래스와 같은 이전 관련 판독기 및 작성기 디자인 및 개념과 유사합니다. 이 항목에서는 XAML 노드 스트림 개념에 대해 설명하고 XAML 노드 수준에서 XAML 표현과 상호 작용하는 루틴을 작성하는 방법을 설명합니다.

XAML 판독기에 XAML 로드

기본 XamlReader 클래스는 초기 XAML을 XAML 판독기에 로드하기 위한 특정 기술을 선언하지 않습니다. 대신 파생 클래스는 XAML에 대한 입력 소스의 일반적인 특성 및 제약 조건을 포함하여 로드 기술을 선언하고 구현합니다. 예를 들어 XamlObjectReader 루트 또는 밑을 나타내는 단일 개체의 입력 소스에서 시작하여 개체 그래프를 읽습니다. 그런 다음 XamlObjectReader 개체 그래프에서 XAML 노드 스트림을 생성합니다.

가장 눈에 띄는 .NET XAML 서비스 정의 XamlReader 서브클래스는 XamlXmlReader. XamlXmlReader 스트림 또는 파일 경로를 통해 직접 텍스트 파일을 로드하거나 TextReader같은 관련 판독기 클래스를 통해 간접적으로 초기 XAML을 로드합니다. XamlReader 로드된 후 XAML 입력 원본 전체를 포함하는 것으로 간주할 수 있습니다. 그러나 XamlReader 기본 API는 판독기에서 XAML의 단일 노드와 상호 작용하도록 설계되었습니다. 처음 로드될 때 첫 번째 단일 노드는 XAML의 루트 및 시작 개체입니다.

XAML 노드 스트림 개념

XML 기반 기술에 액세스하는 DOM, 트리 은유 또는 쿼리 기반 접근 방식에 더 익숙한 경우 XAML 노드 스트림을 개념화하는 유용한 방법은 다음과 같습니다. 로드된 XAML이 가능한 모든 노드가 확장된 다음 선형으로 표시되는 DOM 또는 트리라고 상상해 보십시오. 노드를 진행하면서 DOM과 관련된 수준의 "in" 또는 "out"을 트래버스할 수 있지만 이러한 수준 개념은 노드 스트림과 관련이 없으므로 XAML 노드 스트림은 명시적으로 추적하지 않습니다. 노드 스트림에는 "현재" 위치가 있지만 스트림의 다른 부분을 참조로 직접 저장하지 않는 한 현재 노드 위치 이외의 노드 스트림의 모든 측면이 표시되지 않습니다.

XAML 노드 스트림 개념은 전체 노드 스트림을 통과하는 경우 전체 XAML 표현을 처리했음을 보장한다는 주목할 만한 이점이 있습니다. 쿼리, DOM 작업 또는 정보 처리에 대한 다른 비선형 접근 방식이 전체 XAML 표현의 일부를 놓친 것을 걱정할 필요가 없습니다. 이러한 이유로 XAML 노드 스트림 표현은 XAML 판독기와 XAML 작성기를 연결하고 XAML 처리 작업의 읽기 및 쓰기 단계 간에 작동하는 고유한 프로세스를 삽입할 수 있는 시스템을 제공하는 데 적합합니다. 대부분의 경우 XAML 노드 스트림의 노드 순서는 원본 텍스트, 이진 또는 개체 그래프에 순서가 표시되는 방식과 비교해 XAML 판독기에서 의도적으로 최적화 또는 순서를 다시 지정합니다. 이 동작은 XAML 작성기가 노드 스트림에서 "뒤로" 이동해야 하는 위치에 있지 않은 XAML 처리 아키텍처를 적용하기 위한 것입니다. 이상적으로 모든 XAML 쓰기 작업은 스키마 컨텍스트와 노드 스트림의 현재 위치에 따라 작동할 수 있어야 합니다.

기본 읽기 노드 루프

XAML 노드 스트림을 검사하기 위한 기본 읽기 노드 루프는 다음 개념으로 구성됩니다. 이 항목에서 설명한 대로 노드 루프의 목적을 위해 XamlXmlReader사용하여 텍스트 기반의 사람이 읽을 수 있는 XAML 파일을 읽고 있다고 가정합니다. 이 섹션의 링크는 XamlXmlReader구현된 특정 XAML 노드 루프 API를 참조합니다.

  • XAML 노드 스트림의 끝에 있지 않은지 확인합니다(IsEof확인하거나 Read 반환 값 사용). 스트림의 끝에 있는 경우 현재 노드가 없으므로 종료해야 합니다.

  • NodeType호출하여 XAML 노드 스트림이 현재 노출하는 노드 유형을 확인합니다.

  • 연결된 XAML 개체 작성기가 직접 연결된 경우 일반적으로 이 시점에서 WriteNode 호출합니다.

  • 현재 노드 또는 현재 레코드로 보고되는 XamlNodeType 따라 다음 중 하나를 호출하여 노드 내용에 대한 정보를 가져옵니다.

    • StartMember 또는 EndMemberNodeType 경우 Member 호출하여 멤버에 대한 XamlMember 정보를 가져옵니다. 멤버는 XamlDirective수 있으므로 이전 개체의 기존 형식 정의 멤버가 아닐 수도 있습니다. 예를 들어 개체에 적용된 x:NameIsDirective true이고 멤버의 NameNameXAML 멤버로 표시되며, 다른 속성은 이 지시문이 XAML 언어 XAML 네임스페이스 아래에 있음을 나타냅니다.

    • StartObject 또는 EndObjectNodeType 경우 Type 호출하여 개체에 대한 XamlType 정보를 가져옵니다.

    • Value NodeType 경우 Value호출합니다. 노드는 멤버에 대한 값의 가장 간단한 식이거나 개체의 초기화 텍스트인 경우에만 값입니다(그러나 이 항목의 향후 섹션에 설명된 대로 형식 변환 동작을 알고 있어야 합니다).

    • NamespaceDeclaration NodeType 경우 Namespace 호출하여 네임스페이스 노드에 대한 네임스페이스 정보를 가져옵니다.

  • Read 호출하여 XAML 판독기를 XAML 노드 스트림의 다음 노드로 이동하고 단계를 다시 반복합니다.

.NET XAML Services XAML 판독기에서 제공하는 XAML 노드 스트림은 항상 가능한 모든 노드의 전체 심층 순회를 제공합니다. XAML 노드 루프에 대한 일반적인 흐름 제어 기술에는 while (reader.Read())내에서 본문을 정의하고 노드 루프의 각 노드 지점에서 NodeType 전환하는 것이 포함됩니다.

노드 스트림이 파일 끝에 있는 경우 현재 노드는 null입니다.

판독기와 작성기를 사용하는 가장 간단한 루프는 다음 예제와 유사합니다.

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

로드 경로 XAML 노드 루프의 이 기본 예제는 XAML 판독기와 XAML 기록기를 투명하게 연결하여 XamlServices.Parse사용한 경우와 다른 작업을 수행합니다. 그러나 이 기본 구조는 읽기 또는 쓰기 시나리오에 적용되도록 확장됩니다. 몇 가지 가능한 시나리오는 다음과 같습니다.

  • NodeType. 읽는 노드 유형에 따라 다른 작업을 수행합니다.

  • 모든 경우에 WriteNode 호출하지 마세요. 일부 NodeType 경우에는 WriteNode 호출합니다.

  • 특정 노드 형식에 대한 논리 내에서 해당 노드의 세부 정보를 분석하고 해당 노드에 대해 작동합니다. 예를 들어 특정 XAML 네임스페이스에서 온 개체만 작성한 다음 해당 XAML 네임스페이스가 아닌 개체를 삭제하거나 연기할 수 있습니다. 또는 멤버 처리의 일부로 XAML 시스템에서 지원하지 않는 XAML 지시문을 삭제하거나 다시 처리할 수 있습니다.

  • Write* 메서드를 재정의하는 사용자 지정 XamlObjectWriter 정의합니다. XAML 스키마 컨텍스트를 우회하는 형식 매핑을 수행할 수 있습니다.

  • XAML 동작의 사용자 지정된 차이점이 판독기와 작성기 모두에서 사용되도록 기본이 아닌 XAML 스키마 컨텍스트를 사용하도록 XamlXmlReader 생성합니다.

노드 루프 개념 이외의 XAML 액세스

XAML 노드 루프 이외의 XAML 표현으로 작업하는 다른 방법이 있을 수 있습니다. 예를 들어 인덱싱된 노드를 읽거나, 특히 x:Name, x:Uid또는 다른 식별자를 통해 노드에 직접 액세스할 수 있는 XAML 판독기가 있을 수 있습니다. .NET XAML Services는 전체 구현을 제공하지 않지만 서비스 및 지원 유형을 통해 제안된 패턴을 제공합니다. 자세한 내용은 IXamlIndexingReaderXamlNodeList참조하세요.

현재 노드 작업

XAML 노드 루프를 사용하는 대부분의 시나리오는 노드를 읽을 뿐만 아니라 대부분의 시나리오는 현재 노드를 처리하고 각 노드를 한 번에 하나씩 XamlWriter구현에 전달합니다.

일반적인 로드 경로 시나리오에서 XamlXmlReader XAML 노드 스트림을 생성합니다. XAML 노드는 논리 및 XAML 스키마 컨텍스트에 따라 처리됩니다. 노드가 XamlObjectWriter전달됩니다. 그런 다음 결과 개체 그래프를 애플리케이션 또는 프레임워크에 통합합니다.

일반적인 저장 경로 시나리오에서 XamlObjectReader 개체 그래프를 읽고, 개별 XAML 노드가 처리되고, XamlXmlWriter 직렬화된 결과를 XAML 텍스트 파일로 출력합니다. 핵심은 경로와 시나리오 모두 한 번에 정확히 하나의 XAML 노드로 작업하는 것을 포함하며 XAML 노드는 XAML 형식 시스템과 the.NET XAML 서비스 API에 의해 정의된 표준화된 방식으로 처리할 수 있다는 것입니다.

프레임 및 범위

XAML 노드 루프는 선형 방식으로 XAML 노드 스트림을 안내합니다. 노드 스트림은 개체, 다른 개체를 포함하는 멤버 등으로 트래버스됩니다. 프레임 및 스택 개념을 구현하여 XAML 노드 스트림 내에서 범위를 추적하는 것이 유용한 경우가 많습니다. 노드 스트림에 있는 동안 노드 스트림을 적극적으로 조정하는 경우 특히 그렇습니다. 노드 루프 논리의 일부로 구현하는 프레임 및 스택 지원은 DOM 관점에서 구조가 고려되는 경우 XAML 노드 구조로 내림차순으로 StartObject(또는 GetObject) 및 EndObject 범위를 계산할 수 있습니다.

개체 노드 트래버스 및 입력

XAML 판독기에서 노드 스트림을 열 때 노드 스트림의 첫 번째 노드는 루트 개체의 시작 개체 노드입니다. 정의에 따라 이 개체는 항상 단일 개체 노드이며 피어가 없습니다. 실제 XAML 예제에서 루트 개체는 더 많은 개체를 보유하는 하나 이상의 속성을 포함하도록 정의되며 이러한 속성에는 멤버 노드가 있습니다. 멤버 노드에는 하나 이상의 개체 노드가 있거나 대신 값 노드에서 종료될 수도 있습니다. 루트 개체는 일반적으로 XAML 텍스트 태그에서 특성으로 구문적으로 할당되지만 XAML 노드 스트림 표현의 Namescope 노드 형식에 매핑되는 XAML 이름 범위를 정의합니다.

다음 XAML 예제를 고려합니다(.NET의 기존 형식에서 지원하지 않고 임의 XAML임). 이 개체 모델에서 FavorCollectionFavorList<T>, BalloonNoiseMakerFavor할당할 수 있다고 가정합니다. Balloon.Color 속성은 WPF가 알려진 색 이름으로 색을 정의하는 방법과 유사한 Color 개체에 의해 지원되며 Color 특성 구문에 대한 형식 변환기를 지원합니다.

XAML 태그 결과 XAML 노드 스트림
<Party Party 대한 Namespace 노드
xmlns="PartyXamlNamespace"> Party 대한 StartObject 노드
<Party.Favors> Party.Favors 대한 StartMember 노드
암시적 FavorCollection 대한 StartObject 노드
암시적 FavorCollection 항목 속성에 대한 노드를 StartMember.
<Balloon Balloon 대한 StartObject 노드
Color="Red" Color 대한 StartMember 노드

특성 값 문자열 "Red" 대한 Value 노드

Color 대한 EndMember
HasHelium="True" HasHelium 대한 StartMember 노드

특성 값 문자열 "True" 대한 Value 노드

HasHelium 대한 EndMember
> Balloon 대한 EndObject
<NoiseMaker>Loudest</NoiseMaker> NoiseMaker 대한 StartObject 노드

_Initialization 대한 StartMember 노드

초기화 값 문자열 "Loudest" 대한 Value 노드

_Initialization 대한 EndMember 노드

NoiseMaker 대한 EndObject
암시적 FavorCollection 항목 속성에 대한 노드를 EndMember.
암시적 FavorCollection 대한 EndObject 노드
</Party.Favors> Favors 대한 EndMember
</Party> Party 대한 EndObject

XAML 노드 스트림에서 다음 동작을 사용할 수 있습니다.

  • Namespace 노드가 있는 경우 xmlns사용하여 XAML 네임스페이스를 선언한 StartObject 바로 앞에 스트림에 추가됩니다. XAML 및 예제 노드 스트림을 사용하여 이전 테이블을 다시 확인합니다. StartObjectNamespace 노드가 텍스트 태그의 선언 위치와 어떻게 다른지 확인합니다. 이는 네임스페이스 노드가 노드 스트림에 적용되는 노드보다 항상 앞에 나타나는 동작을 대표합니다. 이 디자인의 목적은 네임스페이스 정보가 개체 작성기에 매우 중요하며 개체 작성기가 형식 매핑을 수행하거나 개체를 처리하려고 시도하기 전에 알고 있어야 한다는 것입니다. XAML 네임스페이스 정보를 스트림의 애플리케이션 범위보다 먼저 배치하면 노드 스트림을 항상 제시된 순서대로 더 간단하게 처리할 수 있습니다.

  • 위의 고려 사항 때문에 루트의 StartObject 아니라 처음부터 노드를 트래버스할 때 대부분의 실제 태그 사례에서 먼저 읽은 하나 이상의 Namespace 노드입니다.

  • StartObject 노드 뒤에 StartMember, Value또는 즉시 EndObject수 있습니다. 그것은 다른 StartObject즉시 따르지 않습니다.

  • StartMember 뒤에 StartObject, Value또는 즉시 EndMember수 있습니다. 값이 새 값을 인스턴스화하는 StartObject 아닌 부모 개체의 기존 값에서 가져온 멤버의 경우 GetObject뒤에 올 수 있습니다. 다음에 Namespace 노드가 있을 수도 있습니다. 이 노드는 예정된 StartObject적용됩니다. 그것은 다른 StartMember즉시 따르지 않습니다.

  • Value 노드는 값 자체를 나타냅니다. "EndValue"가 없습니다. 다음에는 EndMember.

    • 생성에서 사용할 수 있는 개체의 XAML 초기화 텍스트로 인해 Object-Value 구조가 발생하지 않습니다. 대신 _Initialization 멤버에 대한 전용 멤버 노드가 만들어집니다. 및 해당 멤버 노드에 초기화 값 문자열이 포함됩니다. 있는 경우 _Initialization 항상 첫 번째 StartMember. _Initialization XAML 언어 XAML 이름 범위가 있는 일부 XAML 서비스 표현에서 정규화되어 _Initialization 지원 형식의 정의된 속성이 아님을 명확히 할 수 있습니다.

    • Member-Value 조합은 값의 특성 설정을 나타냅니다. 결국 이 값을 처리하는 데 관련된 값 변환기가 있을 수 있으며 값은 일반 문자열입니다. 그러나 XAML 개체 작성기가 이 노드 스트림을 처리할 때까지 평가되지 않습니다. XAML 개체 작성기에는 필요한 XAML 스키마 컨텍스트, 형식 시스템 매핑 및 값 변환에 필요한 기타 지원이 있습니다.

  • EndMember 노드 뒤에는 후속 멤버에 대한 StartMember 노드 또는 멤버 소유자에 대한 EndObject 노드가 있을 수 있습니다.

  • EndObject 노드 뒤에 EndMember 노드가 있을 수 있습니다. 또한 개체가 컬렉션 항목의 피어인 경우 StartObject 노드가 뒤따를 수 있습니다. 또는 Namespace 노드 뒤에 올 StartObject적용할 수 있습니다.

    • 전체 노드 스트림을 닫는 고유한 경우 루트의 EndObject 뒤에는 아무 것도 없습니다. 이제 판독기는 파일의 끝이며 Readfalse반환합니다.

값 변환기 및 XAML 노드 스트림

값 변환기는 태그 확장, 형식 변환기(값 serializer 포함) 또는 XAML 형식 시스템을 통해 값 변환기로 보고되는 다른 전용 클래스에 대한 일반적인 용어입니다. XAML 노드 스트림에서 형식 변환기 사용 및 태그 확장 사용은 표현이 매우 다릅니다.

XAML 노드 스트림의 형식 변환기

결국 형식 변환기 사용을 초래하는 특성 집합은 XAML 노드 스트림에서 멤버의 값으로 보고됩니다. XAML 노드 스트림은 형식 변환기 인스턴스 개체를 생성하고 값을 전달하려고 시도하지 않습니다. 형식 변환기 변환기 변환 구현을 사용하려면 XAML 스키마 컨텍스트를 호출하고 형식 매핑에 사용해야 합니다. 값을 처리하는 데 사용해야 하는 형식 변환기 클래스를 결정하는 경우에도 XAML 스키마 컨텍스트가 간접적으로 필요합니다. 기본 XAML 스키마 컨텍스트를 사용하는 경우 해당 정보는 XAML 형식 시스템에서 사용할 수 있습니다. XAML 작성기에 연결하기 전에 XAML 노드 스트림 수준에서 형식 변환기 클래스 정보가 필요한 경우 설정되는 멤버의 XamlMember 정보에서 가져올 수 있습니다. 그렇지 않으면 형식 매핑 시스템 및 XAML 스키마 컨텍스트가 필요한 작업의 나머지 부분(예: XAML 개체 작성기에서 개체 만들기)이 수행될 때까지 XAML 노드 스트림에서 형식 변환기 입력을 일반 값으로 유지해야 합니다.

예를 들어 다음 클래스 정의 개요 및 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"/>

이 사용에 대한 XAML 노드 스트림의 텍스트 표현은 다음과 같이 표현될 수 있습니다.

GameBoard 나타내는 XamlType 있는 StartObject

BoardSize 나타내는 XamlMember 있는 StartMember

Value 노드, 텍스트 문자열 "8x8"

EndMember 일치 BoardSize

EndObject 일치 GameBoard

이 노드 스트림에는 형식 변환기 인스턴스가 없습니다. 그러나 BoardSizeXamlMemberXamlMember.TypeConverter 호출하여 형식 변환기 정보를 가져올 수 있습니다. 유효한 XAML 스키마 컨텍스트가 있는 경우 ConverterInstance인스턴스를 가져와 변환기 메서드를 호출할 수도 있습니다.

XAML 노드 스트림의 태그 확장

태그 확장 사용은 XAML 노드 스트림에서 개체가 태그 확장 인스턴스를 나타내는 멤버 내의 개체 노드로 보고됩니다. 따라서 태그 확장 사용은 형식 변환기 사용량보다 노드 스트림 표현에서 더 명시적으로 표시되며 더 많은 정보를 전달합니다. XamlMember 정보는 태그 확장에 대해 아무 말도 할 수 없습니다. 사용법은 상황이며 가능한 각 태그 사례에 따라 다르기 때문입니다. 형식 변환기의 경우처럼 형식 또는 멤버당 전용 및 암시적이 아닙니다.

태그 확장을 개체 노드로 표시하는 노드 스트림은 XAML 텍스트 태그의 특성 형식으로 태그 확장 사용이 수행된 경우에도 발생합니다(대개 해당). 명시적 개체 요소 양식을 사용한 태그 확장 사용은 동일한 방식으로 처리됩니다.

태그 확장 개체 노드 내에 해당 태그 확장의 멤버가 있을 수 있습니다. XAML 노드 스트림 표현은 위치 매개 변수 사용 또는 명시적 명명된 매개 변수가 있는 사용량 등 해당 태그 확장의 사용을 유지합니다.

위치 매개 변수 사용의 경우 XAML 노드 스트림에는 사용량을 기록하는 XAML 언어 정의 속성 _PositionalParameters 포함되어 있습니다. 이 속성은 Object 제약 조건이 있는 제네릭 List<T>. 위치 매개 변수 사용에 중첩된 태그 확장 사용이 포함될 수 있으므로 제약 조건은 문자열이 아닌 개체입니다. 사용법에서 위치 매개 변수에 액세스하려면 목록을 반복하고 개별 목록 값에 인덱서를 사용할 수 있습니다.

명명된 매개 변수 사용의 경우 명명된 각 매개 변수는 노드 스트림에서 해당 이름의 멤버 노드로 표시됩니다. 중첩된 태그 확장 사용이 있을 수 있으므로 멤버 값이 반드시 문자열은 아닙니다.

태그 확장의 ProvideValue 아직 호출되지 않았습니다. 그러나 XAML 판독기와 XAML 기록기를 연결하면 노드 스트림에서 검사할 때 태그 확장 노드에서 WriteEndObject 호출됩니다. 이러한 이유로 일반적으로 로드 경로에서 개체 그래프를 형성하기 위해 사용되는 것과 동일한 XAML 스키마 컨텍스트를 사용할 수 있어야 합니다. 그렇지 않으면 태그 확장에서 ProvideValue 사용할 수 있는 예상된 서비스가 없으므로 여기에 예외를 throw할 수 있습니다.

XAML 노드 스트림의 XAML 및 XML Language-Defined 멤버

명시적 XamlMember 조회 또는 생성 대신 XAML 판독기의 해석 및 규칙 때문에 특정 멤버가 XAML 노드 스트림에 도입됩니다. 종종 이러한 멤버는 XAML 지시문입니다. 경우에 따라 XAML 노드 스트림에 지시문을 도입하는 XAML을 읽는 동작입니다. 즉, 원래 입력 XAML 텍스트는 멤버 지시문을 명시적으로 지정하지 않았지만 XAML 판독기는 구조적 XAML 규칙을 충족하고 해당 정보가 손실되기 전에 XAML 노드 스트림의 정보를 보고하기 위해 지시문을 삽입합니다.

다음 목록에서는 XAML 판독기에서 지시문 XAML 멤버 노드를 도입해야 하는 모든 사례와 .NET XAML 서비스 구현에서 해당 멤버 노드를 식별하는 방법을 설명합니다.

  • 개체 노드의 초기화 텍스트입니다. 이 멤버 노드의 이름이 _InitializationXAML 지시문을 나타내며 XAML 언어 XAML 네임스페이스로 정의됩니다. Initialization정적 엔터티를 가져올 수 있습니다.

  • 태그 확장에 대한 위치 매개 변수 : 이 멤버 노드의 이름이 _PositionalParametersXAML 언어 XAML 네임스페이스로 정의됩니다. 항상 제네릭 개체 목록이 포함되며, 각 개체는 입력 XAML에 제공된 대로 , 구분 기호 문자를 분할하여 미리 구분된 위치 매개 변수입니다. PositionalParameters위치 매개 변수 지시문에 대한 정적 엔터티를 가져올 수 있습니다.

  • 알 수 없는 콘텐츠 : 이 멤버 노드의 이름이 _UnknownContent. 엄밀히 말하면 XamlDirectiveXAML 언어 XAML 네임스페이스에 정의됩니다. 이 지시문은 XAML 개체 요소에 원본 XAML의 콘텐츠가 포함되어 있지만 현재 사용 가능한 XAML 스키마 컨텍스트에서 콘텐츠 속성을 확인할 수 없는 경우의 경우 sentinel로 사용됩니다. 이름이 _UnknownContent멤버를 확인하여 XAML 노드 스트림에서 이 사례를 검색할 수 있습니다. 로드 경로 XAML 노드 스트림에서 다른 작업을 수행하지 않으면 기본 XamlObjectWriter 개체에서 _UnknownContent 멤버를 발견할 때 시도된 WriteEndObject throw합니다. 기본 XamlXmlWriter throw되지 않으며 멤버를 암시적으로 처리합니다. UnknownContent _UnknownContent 정적 엔터티를 가져올 수 있습니다.

  • 컬렉션의 컬렉션 속성 : XAML에 사용되는 컬렉션 클래스의 지원 CLR 형식에는 일반적으로 컬렉션 항목을 보유하는 전용 명명된 속성이 있지만 해당 속성은 지원 형식 확인 전에 XAML 형식 시스템에 알려지지 않았습니다. 대신 XAML 노드 스트림은 컬렉션 XAML 형식의 멤버로 Items 자리 표시자를 도입합니다. .NET XAML Services 구현에서 노드 스트림에서 이 지시문 또는 멤버의 이름은 _Items. 이 지시문에 대한 상수는 Items가져올 수 있습니다.

    XAML 노드 스트림에는 지원 형식 확인 및 XAML 스키마 컨텍스트에 따라 구문 분석할 수 없는 항목이 있는 Items 속성이 포함될 수 있습니다. 예를 들어

  • XML 정의 멤버: XML 정의 xml:base, xml:langxml:space 멤버는 .NET XAML 서비스 구현에서 base, langspace 이름이 지정된 XAML 지시문으로 보고됩니다. 이러한 네임스페이스는 XML 네임스페이스 http://www.w3.org/XML/1998/namespace. 이러한 각 상수는 XamlLanguage가져올 수 있습니다.

노드 순서

경우에 따라 XamlXmlReader XAML 노드 스트림에서 XAML 노드의 순서를 변경하고 태그에 표시되거나 XML로 처리되는 경우 노드가 나타나는 순서를 변경합니다. 이 작업은 XamlObjectWriter 노드 스트림을 정방향 전용 방식으로 처리할 수 있도록 노드를 정렬하기 위해 수행됩니다. .NET XAML 서비스에서 XAML 판독기는 노드 스트림의 XAML 개체 작성기 소비자를 위한 성능 최적화로 이 작업을 XAML 기록기에 맡기지 않고 노드를 다시 정렬합니다.

특정 지시문은 개체 요소에서 개체를 만들기 위한 자세한 정보를 제공하도록 특별히 고안되었습니다. 이러한 지시문은 Initialization, PositionalParameters, TypeArguments, FactoryMethod, Arguments. .NET XAML Services XAML 판독기는 다음 섹션에서 설명하는 이유로 개체의 StartObject따라 노드 스트림의 첫 번째 멤버로 이러한 지시문을 배치하려고 합니다.

XamlObjectWriter 동작 및 노드 순서

XamlObjectWriter StartObject 개체 인스턴스를 즉시 생성하기 위해 XAML 개체 작성기에 대한 신호일 필요는 없습니다. XAML에는 추가 입력을 사용하여 개체를 초기화하고 매개 변수가 없는 생성자를 호출하여 초기 개체를 생성한 다음 속성을 설정하는 데 전적으로 의존하지 않도록 하는 여러 언어 기능이 포함되어 있습니다. 이러한 기능은 다음과 같습니다. XamlDeferLoadAttribute; 초기화 텍스트; x:TypeArguments; 태그 확장의 위치 매개 변수; 팩터리 메서드 및 연결된 x:arguments 노드(XAML 2009). 이러한 각 경우는 실제 개체 생성을 지연시키고 노드 스트림의 순서를 다시 지정하기 때문에 XAML 개체 작성기는 해당 개체 형식에 대한 생성 지시문이 아닌 시작 멤버가 발견될 때마다 인스턴스를 실제로 생성하는 동작을 사용할 수 있습니다.

GetObject

GetObject 새 개체를 생성하는 대신 XAML 개체 작성기가 개체의 포함하는 속성 값을 가져와야 하는 XAML 노드를 나타냅니다. XAML 노드 스트림에서 GetObject 노드가 발생하는 일반적인 경우는 포함 속성이 지원 형식의 개체 모델에서 의도적으로 읽기 전용인 경우 컬렉션 개체 또는 사전 개체에 대한 것입니다. 이 시나리오에서는 소유 형식의 초기화 논리에 의해 컬렉션 또는 사전이 생성되고 초기화되는 경우가 많습니다(일반적으로 비어 있음).

참고 항목