Estruturas e conceitos de fluxo de nó XAML

Artigo
07/13/2023

Os leitores XAML e os gravadores XAML implementados nos Serviços XAML do .NET são baseados no conceito de design de um fluxo de nó XAML. O fluxo de nós XAML é uma conceituação de um conjunto de nós XAML. Nessa conceituação, um processador XAML percorre a estrutura das relações de nó no XAML, uma de cada vez. A qualquer momento, existe apenas um registro ou posição atual em um fluxo de nó XAML aberto, e muitos aspectos da API relatam apenas as informações disponíveis nessa posição. O nó atual em um fluxo de nó XAML pode ser descrito como sendo um objeto, um membro ou um valor. Ao tratar XAML como um fluxo de nó XAML, os leitores XAML podem se comunicar com gravadores XAML e permitir que um programa exiba, interaja ou altere o conteúdo de um fluxo de nó XAML durante um caminho de carregamento ou uma operação de caminho de salvamento que envolva XAML. O design da API do leitor e gravador XAML e o conceito de fluxo de nó XAML são semelhantes aos designs e conceitos anteriores relacionados ao leitor e gravador, como o DOM (Modelo de Objeto de Documento XML) e as XmlReader classes e XmlWriter . Este tópico discute os conceitos de fluxo de nó XAML e descreve como você pode escrever rotinas que interagem com representações XAML no nível do nó XAML.

Carregando XAML em um leitor XAML

A classe base XamlReader não declara uma técnica específica para carregar o XAML inicial em um leitor XAML. Em vez disso, uma classe derivada declara e implementa a técnica de carregamento, incluindo as características gerais e restrições de sua fonte de entrada para XAML. Por exemplo, um lê um gráfico de objeto, a partir da fonte de entrada de um XamlObjectReader único objeto que representa a raiz ou base. O XamlObjectReader então produz um fluxo de nó XAML a partir do gráfico de objeto.

A subclasse definida pelos XamlReader Serviços XAML do .NET mais proeminente é XamlXmlReader. XamlXmlReader carrega o XAML inicial, carregando um arquivo de texto diretamente por meio de um fluxo ou caminho de arquivo, ou indiretamente por meio de uma classe de leitor relacionada, como TextReader. O XamlReader pode ser considerado como contendo a totalidade da fonte de entrada XAML depois de carregada. No entanto, a XamlReader API base foi projetada para que o leitor interaja com um único nó do XAML. Quando carregado pela primeira vez, o primeiro nó único que você encontra é a raiz do XAML e seu objeto inicial.

O conceito de fluxo de nó XAML

Se você estiver mais familiarizado com um DOM, metáfora de árvore ou abordagem baseada em consulta para acessar tecnologias baseadas em XML, uma maneira útil de conceituar um fluxo de nó XAML é a seguinte. Imagine que o XAML carregado é um DOM ou uma árvore onde cada nó possível é expandido por todo o caminho e, em seguida, apresentado linearmente. À medida que você avança pelos nós, você pode estar atravessando "dentro" ou "fora" de níveis que seriam relevantes para um DOM, mas o fluxo de nó XAML não acompanha explicitamente porque esses conceitos de nível não são relevantes para um fluxo de nó. O fluxo de nó tem uma posição "atual", mas a menos que você mesmo tenha armazenado outras partes do fluxo como referências, todos os aspectos do fluxo de nó diferentes da posição atual do nó estão fora de exibição.

O conceito de fluxo de nó XAML tem a vantagem notável de que, se você percorrer todo o fluxo de nó, terá certeza de que processou toda a representação XAML; você não precisa se preocupar que uma consulta, uma operação DOM ou alguma outra abordagem não linear para processar informações tenha perdido alguma parte da representação XAML completa. Por esse motivo, a representação de fluxo de nó XAML é ideal para conectar leitores XAML e gravadores XAML e para fornecer um sistema onde você pode inserir seu próprio processo que atua entre as fases de leitura e gravação de uma operação de processamento XAML. Em muitos casos, a ordem dos nós no fluxo de nós XAML é deliberadamente otimizada ou reordenada pelos leitores XAML versus como a ordem pode aparecer no texto de origem, binário ou gráfico de objeto. Esse comportamento destina-se a impor uma arquitetura de processamento XAML pela qual os gravadores XAML nunca estão em uma posição em que precisam "voltar" no fluxo de nós. Idealmente, todas as operações de gravação XAML devem ser capazes de agir com base no contexto do esquema mais a posição atual do fluxo do nó.

Um loop de nó de leitura básico

Um loop de nó de leitura básico para examinar um fluxo de nó XAML consiste nos seguintes conceitos. Para fins de loops de nó, conforme discutido neste tópico, suponha que você esteja lendo um arquivo XAML baseado em texto e legível por humanos usando XamlXmlReadero . Os links nesta seção referem-se à API de loop de nó XAML específica implementada pelo XamlXmlReader.

Verifique se você não está no final do fluxo de nó XAML (marque IsEofou use o Read valor de retorno). Se você estiver no final do fluxo, não há nó atual e você deve sair.
Verifique que tipo de nó o fluxo de nó XAML expõe atualmente chamando NodeType.
Se você tiver um gravador de objeto XAML associado que esteja conectado diretamente, geralmente chame WriteNode neste ponto.
Com base no que XamlNodeType é relatado como o nó atual ou registro atual, chame um dos seguintes para obter informações sobre o conteúdo do nó:
- Para um de StartMember ou EndMember, ligue Member para obter XamlMember informações sobre um NodeType membro. O membro pode ser um , e, portanto, pode não ser necessariamente um XamlDirectivemembro convencional definido pelo tipo do objeto anterior. Por exemplo, aplicado a um objeto aparece como um membro XAML onde IsDirective é true e o Name do membro é Name, x:Name com outras propriedades indicando que essa diretiva está sob o namespace XAML da linguagem XAML.
- Para um de StartObject ou EndObject, chame Type para obter XamlType informações sobre um NodeType objeto.
- Para um NodeType de Value, ligue Value. Um nó será um valor somente se for a expressão mais simples de um valor para um membro ou o texto de inicialização de um objeto (no entanto, você deve estar ciente do comportamento de conversão de tipo, conforme documentado em uma próxima seção deste tópico).
- Para um de , chame Namespace para obter informações de namespace para um NodeType nó de NamespaceDeclarationnamespace.
Chame Read para avançar o leitor XAML para o próximo nó no fluxo de nós XAML e repita as etapas novamente.

O fluxo de nós XAML fornecido pelos leitores XAML dos Serviços XAML do .NET sempre fornece uma travessia completa e profunda de todos os nós possíveis. As técnicas típicas de controle de fluxo para um loop de nó XAML incluem definir um corpo dentro while (reader.Read())do e ativar NodeType em cada ponto do nó no loop do nó.

Se o fluxo do nó estiver no final do arquivo, o nó atual será nulo.

O loop mais simples que usa um leitor e um gravador se assemelha ao exemplo a seguir.

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

Este exemplo básico de um loop de nó XAML de caminho de carregamento conecta de forma transparente o leitor XAML e o gravador XAML, não fazendo nada diferente do que se você tivesse usado XamlServices.Parseo . Mas essa estrutura básica é então expandida para se aplicar ao seu cenário de leitura ou escrita. Alguns cenários possíveis são os seguintes:

Ligue NodeType. Execute ações diferentes dependendo do tipo de nó que está sendo lido.
Não ligue WriteNode em todos os casos. Só ligue WriteNode em alguns NodeType casos.
Dentro da lógica para um determinado tipo de nó, analise as especificidades desse nó e aja sobre elas. Por exemplo, você só pode escrever objetos que vêm de um namespace XAML específico e, em seguida, descartar ou adiar quaisquer objetos que não sejam desse namespace XAML. Ou você pode descartar ou reprocessar quaisquer diretivas XAML que seu sistema XAML não oferece suporte como parte do processamento de membros.
Defina um personalizado XamlObjectWriter que substitua Write* métodos, possivelmente executando mapeamento de tipo que ignora o contexto do esquema XAML.
Construa o XamlXmlReader para usar um contexto de esquema XAML não padrão, para que as diferenças personalizadas no comportamento XAML sejam usadas tanto pelo leitor quanto pelo gravador.

Acessando XAML além do conceito de loop de nó

Há potencialmente outras maneiras de trabalhar com uma representação XAML que não seja como um loop de nó XAML. Por exemplo, pode existir um leitor XAML que possa ler um nó indexado ou, em particular, acessar nós diretamente por , por , ou por x:Namex:Uidmeio de outros identificadores. Os Serviços XAML do .NET não fornecem uma implementação completa, mas fornecem um padrão sugerido por meio de serviços e tipos de suporte. Para obter mais informações, consulte IXamlIndexingReader e XamlNodeList.

Trabalhando com o nó atual

A maioria dos cenários que usam um loop de nó XAML não lê apenas os nós. A maioria dos cenários processa os nós atuais e passa cada nó, um de cada vez, para uma implementação do XamlWriter.

No cenário típico de caminho de carga, um produz um fluxo de nó XAML, os nós XAML são processados de acordo com sua lógica e contexto de esquema XAML e os nós são passados para um XamlXmlReader XamlObjectWriter. Em seguida, você integra o gráfico de objeto resultante em seu aplicativo ou estrutura.

Em um cenário típico de caminho de salvamento, um lê o gráfico de objeto, nós XAML individuais são processados e um gera o resultado serializado como um XamlObjectReader XamlXmlWriter arquivo de texto XAML. A chave é que ambos os caminhos e cenários envolvem trabalhar com exatamente um nó XAML por vez, e os nós XAML estão disponíveis para tratamento de forma padronizada que é definida pelo sistema de tipos XAML e the.NET APIs de Serviços XAML.

Quadros e escopo

Um loop de nó XAML percorre um fluxo de nó XAML de forma linear. O fluxo de nó atravessa em objetos, em membros que contêm outros objetos e assim por diante. Muitas vezes, é útil manter o controle do escopo dentro do fluxo de nós XAML implementando um conceito de quadro e pilha. Isso é particularmente verdadeiro se você estiver ajustando ativamente o fluxo do nó enquanto estiver nele. O suporte a quadro e pilha que você implementa como parte da lógica de loop do nó pode contar StartObject (ou GetObject) e EndObject escopos à medida que você desce para uma estrutura de nó XAML se a estrutura for pensada de uma perspectiva DOM.

Atravessando e inserindo nós de objeto

O primeiro nó em um fluxo de nó quando ele é aberto por um leitor XAML é o nó de objeto inicial do objeto raiz. Por definição, esse objeto é sempre um único nó de objeto e não tem pares. Em qualquer exemplo XAML do mundo real, o objeto raiz é definido para ter uma ou mais propriedades que contêm mais objetos, e essas propriedades têm nós de membro. Os nós de membro têm um ou mais nós de objeto ou também podem terminar em um nó de valor. O objeto raiz normalmente define namescopes XAML, que são atribuídos sintaticamente como atributos na marcação de texto XAML, mas mapeados para um Namescope tipo de nó na representação de fluxo de nó XAML.

Considere o exemplo de XAML a seguir (esse é um XAML arbitrário, não apoiado por tipos existentes no .NET). Suponha que, neste modelo de objeto, é de , e são atribuíveis a , FavorCollectionBalloon a propriedade é List<T> apoiada por um objeto semelhante a como o WPF define cores como nomes de cores conhecidos e ColorNoiseMaker oferece suporte a Balloon.ColorFavorum Color conversor de tipo para sintaxe de Favoratributo.

Marcação XAML	Fluxo de nó XAML resultante
`<Party`	`Namespace` nó para `Party`
`xmlns="PartyXamlNamespace">`	`StartObject` nó para `Party`
`<Party.Favors>`	`StartMember` nó para `Party.Favors`
	`StartObject` nó para implícito `FavorCollection`
	`StartMember` para a propriedade de itens implícitos `FavorCollection` .
`<Balloon`	`StartObject` nó para `Balloon`
`Color="Red"`	`StartMember` nó para `Color` `Value` nó para a cadeia de caracteres de valor de atributo `"Red"` `EndMember` para `Color`
`HasHelium="True"`	`StartMember` nó para `HasHelium` `Value` nó para a cadeia de caracteres de valor de atributo `"True"` `EndMember` para `HasHelium`
`>`	`EndObject` para `Balloon`
`<NoiseMaker>Loudest</NoiseMaker>`	`StartObject` nó para `NoiseMaker` `StartMember` nó para `_Initialization` `Value` para a cadeia de caracteres de valor de inicialização `"Loudest"` `EndMember` nó para `_Initialization` `EndObject` para `NoiseMaker`
	`EndMember` para a propriedade de itens implícitos `FavorCollection` .
	`EndObject` nó para implícito `FavorCollection`
`</Party.Favors>`	`EndMember` para `Favors`
`</Party>`	`EndObject` para `Party`

No fluxo de nó XAML, você pode confiar no seguinte comportamento:

Se existir um Namespace nó, ele será adicionado ao fluxo imediatamente antes do StartObject que declarou o namespace XAML com xmlns. Observe a tabela anterior com o fluxo de nó XAML e de exemplo novamente. Observe como os StartObject nós e Namespace parecem ser transpostos versus suas posições de declaração na marcação de texto. Isso é representativo do comportamento em que os nós de namespace sempre aparecem à frente do nó ao qual se aplicam no fluxo de nó. O objetivo desse design é que as informações de namespace são vitais para os gravadores de objetos e devem ser conhecidas antes que o gravador de objetos tente executar o mapeamento de tipos ou processar o objeto de outra forma. Colocar as informações do namespace XAML à frente de seu escopo de aplicativo no fluxo torna mais simples sempre processar o fluxo de nó em sua ordem apresentada.
Devido à consideração acima, é um ou mais Namespace nós que você lê primeiro na maioria dos casos de marcação do mundo real ao atravessar nós desde o início, não o StartObject da raiz.
Um StartObject nó pode ser seguido por StartMember, Valueou um EndObjectimediato . Nunca é seguido imediatamente por outro StartObject.
A StartMember pode ser seguido por um , Valueou um StartObjectimediato EndMember. Ele pode ser seguido por GetObject, para membros em que o valor deve vir de um valor existente do objeto pai, em vez de um que instanciaria um StartObject novo valor. Ele também pode ser seguido por um nó, que se aplica a um Namespace próximo StartObject. Nunca é seguido imediatamente por outro StartMember.
Um Value nó representa o valor em si, não há "EndValue". Ele pode ser seguido apenas por um EndMember.
- O texto de inicialização XAML do objeto como pode ser usado pela construção não resulta em uma estrutura Object-Value. Em vez disso, um nó de membro dedicado para um membro chamado _Initialization é criado. e esse nó membro contém a cadeia de caracteres do valor de inicialização. Se existe, _Initialization é sempre o primeiro StartMember. _Initialization pode ser qualificado em algumas representações de serviços XAML com o namescope XAML da linguagem XAML, para esclarecer que _Initialization não é uma propriedade definida em tipos de suporte.
- Uma combinação Member-Value representa uma configuração de atributo do valor. Eventualmente, pode haver um conversor de valor envolvido no processamento desse valor, e o valor é uma cadeia de caracteres simples. No entanto, isso não é avaliado até que um gravador de objeto XAML processe esse fluxo de nó. O gravador de objeto XAML possui o contexto de esquema XAML necessário, o mapeamento do sistema de tipos e outro suporte necessário para conversões de valor.
Um EndMember nó pode ser seguido por um nó para um membro subsequente ou por um StartMemberEndObject nó para o proprietário do membro.
Um EndObject nó pode ser seguido por um EndMember nó. Ele também pode ser seguido por um StartObject nó para casos em que os objetos são pares nos itens de uma coleção. Ou pode ser seguido por um nó, que se aplica a um Namespace próximo StartObject.
- Para o caso único de fechar todo o fluxo do nó, o EndObject da raiz não é seguido por nada, o leitor agora é o fim do arquivo e Read retorna false.

Conversores de valor e o fluxo de nós XAML

Um conversor de valor é um termo geral para uma extensão de marcação, um conversor de tipo (incluindo serializadores de valor) ou outra classe dedicada que é relatada como um conversor de valor por meio do sistema de tipos XAML. No fluxo de nó XAML, o uso de um conversor de tipo e um uso de extensão de marcação têm representações muito diferentes.

Conversores de tipo no fluxo de nó XAML

Um conjunto de atributos que eventualmente resulta no uso de um conversor de tipo é relatado no fluxo de nó XAML como um valor de um membro. O fluxo de nó XAML não tenta produzir um objeto de instância do conversor de tipo e passar o valor para ele. O uso da implementação de conversão de um conversor de tipo requer invocar o contexto do esquema XAML e usá-lo para mapeamento de tipo. Até mesmo determinar qual classe de conversor de tipo deve ser usada para processar o valor requer o contexto do esquema XAML indiretamente. Quando você usa o contexto de esquema XAML padrão, essas informações estão disponíveis no sistema de tipos XAML. Se você precisar das informações de classe do conversor de tipo no nível de fluxo do nó XAML antes da conexão com um gravador XAML, poderá obtê-las a XamlMember partir das informações do membro que está sendo definido. Mas, caso contrário, a entrada do conversor de tipo deve ser preservada no fluxo de nó XAML como um valor simples até que o restante das operações que exigem o sistema de mapeamento de tipo e o contexto do esquema XAML sejam executados, por exemplo, a criação de objeto por um gravador de objeto XAML.

Por exemplo, considere a seguinte estrutura de tópicos de definição de classe e o uso de XAML para ela:

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

Uma representação de texto do fluxo de nó XAML para esse uso pode ser expressa da seguinte forma:

StartObject com XamlType representação GameBoard

StartMember com XamlMember representação BoardSize

Valuenó, com cadeia de texto ""8x8

EndMember Corresponde BoardSize

EndObject Corresponde GameBoard

Observe que não há nenhuma instância de conversor de tipo nesse fluxo de nó. Mas você pode obter informações do conversor de tipo chamando XamlMember.TypeConverter o XamlMember para BoardSize. Se você tiver um contexto de esquema XAML válido, também poderá invocar os métodos conversor obtendo uma instância do ConverterInstance.

Extensões de marcação no fluxo de nós XAML

Um uso de extensão de marcação é relatado no fluxo de nó XAML como um nó de objeto dentro de um membro, onde o objeto representa uma instância de extensão de marcação. Assim, um uso de extensão de marcação é apresentado mais explicitamente na representação de fluxo de nó do que um uso de conversor de tipo e carrega mais informações. XamlMember as informações não poderiam ter dito nada sobre a extensão de marcação, porque o uso é situacional e varia em cada caso de marcação possível; não é dedicado e implícito por tipo ou membro, como é o caso dos conversores de tipo.

A representação de fluxo de nó de extensões de marcação como nós de objeto é o caso, mesmo que o uso da extensão de marcação tenha sido feito em forma de atributo na marcação de texto XAML (o que geralmente é o caso). Os usos de extensão de marcação que usaram um formulário de elemento de objeto explícito são tratados da mesma maneira.

Dentro de um nó de objeto de extensão de marcação, pode haver membros dessa extensão de marcação. A representação de fluxo de nó XAML preserva o uso dessa extensão de marcação, seja um uso de parâmetro posicional ou um uso com parâmetros nomeados explícitos.

Para um uso de parâmetro posicional, o fluxo de nó XAML contém uma propriedade _PositionalParameters definida pela linguagem XAML que registra o uso. Esta propriedade é um genérico List<T> com Object restrição. A restrição é objeto e não cadeia de caracteres porque concebivelmente um uso de parâmetro posicional poderia conter usos de extensão de marcação aninhada dentro dele. Para acessar os parâmetros posicionais do uso, você pode iterar pela lista e usar os indexadores para valores de lista individuais.

Para um uso de parâmetro nomeado, cada parâmetro nomeado é representado como um nó membro desse nome no fluxo de nó. Os valores de membro não são necessariamente cadeias de caracteres, porque pode haver um uso de extensão de marcação aninhada.

ProvideValue da extensão de marcação ainda não é invocada. No entanto, ele será invocado se você conectar um leitor XAML e um gravador XAML para que WriteEndObject seja invocado no nó de extensão de marcação quando você examiná-lo no fluxo de nó. Por esse motivo, você geralmente precisa do mesmo contexto de esquema XAML disponível que seria usado para formar o gráfico de objeto no caminho de carregamento. Caso contrário, a partir de qualquer extensão de marcação pode lançar exceções aqui, ProvideValue porque não tem serviços esperados disponíveis.

Membros definidos pela linguagem XAML e XML no fluxo de nós XAML

Certos membros são apresentados a um fluxo de nó XAML devido a interpretações e convenções de um leitor XAML, em vez de por meio de uma pesquisa ou construção explícita XamlMember . Muitas vezes, esses membros são diretivas XAML. Em alguns casos, é o ato de ler o XAML que introduz a diretiva no fluxo do nó XAML. Em outras palavras, o texto XAML de entrada original não especificou explicitamente a diretiva de membro, mas o leitor XAML insere a diretiva para satisfazer uma convenção XAML estrutural e relatar informações no fluxo de nó XAML antes que essas informações sejam perdidas.

A lista a seguir observa todos os casos em que se espera que um leitor XAML introduza um nó membro XAML de diretiva e como esse nó membro é identificado nas implementações dos Serviços XAML do .NET.

Texto de inicialização para um nó de objeto: o nome desse nó membro é , ele representa uma diretiva XAML e é _Initializationdefinido no namespace XAML da linguagem XAML. Você pode obter uma entidade estática para ele do Initialization.
Parâmetros posicionais para uma extensão de marcação: o nome desse nó membro é , e ele é _PositionalParametersdefinido no namespace XAML da linguagem XAML. Ele sempre contém uma lista genérica de objetos, cada um dos quais é um parâmetro posicional pré-separado dividindo no caractere , delimitador conforme fornecido no XAML de entrada. Você pode obter uma entidade estática para a diretiva de parâmetros posicionais do PositionalParameters.
Conteúdo desconhecido: o nome deste nó membro é _UnknownContent. Estritamente falando, é um XamlDirective, e é definido no namespace XAML da linguagem XAML. Essa diretiva é usada como sentinela para casos em que um elemento de objeto XAML contém conteúdo no XAML de origem, mas nenhuma propriedade de conteúdo pode ser determinada no contexto de esquema XAML disponível no momento. Você pode detectar esse caso em um fluxo de nó XAML verificando se há membros chamados _UnknownContent. Se nenhuma outra ação for executada em um fluxo de nó XAML do caminho de carregamento, o padrão XamlObjectWriter será acionado WriteEndObject quando encontrar o _UnknownContent membro em qualquer objeto. O padrão XamlXmlWriter não lança e trata o membro como implícito. Você pode obter uma entidade estática para _UnknownContent de UnknownContent.
Propriedade Collection de uma coleção: Embora o tipo CLR de suporte de uma classe de coleção usada para XAML geralmente tenha uma propriedade nomeada dedicada que contém os itens da coleção, essa propriedade não é conhecida por um sistema de tipo XAML antes da resolução do tipo de backup. Em vez disso, o fluxo de nó XAML introduz um Items espaço reservado como membro do tipo XAML da coleção. Na implementação dos Serviços XAML do .NET, o nome dessa diretiva ou membro no fluxo de nó é _Items. Uma constante para esta directiva pode ser obtida em Items.

Observe que um fluxo de nó XAML pode conter uma propriedade Items com itens que acabam não sendo analisáveis com base na resolução do tipo de backup e no contexto do esquema XAML. Por exemplo,
Membros definidos por XML: os membros e definidos por XML são relatados como diretivas XAML nomeadas base, lange xml:spacexml:basexml:langspace em implementações de Serviços XAML do .NET. O namespace para esses é o namespace http://www.w3.org/XML/1998/namespaceXML . Constantes para cada um deles podem ser obtidas de XamlLanguage.

Ordem do nó

Em alguns casos, XamlXmlReader altera a ordem dos nós XAML no fluxo de nós XAML versus a ordem em que os nós aparecem se exibidos na marcação ou se processados como XML. Isso é feito para ordenar os nós de forma que um XamlObjectWriter possa processar o fluxo de nó de uma maneira somente para frente. Nos Serviços XAML do .NET, o leitor XAML reordena nós em vez de deixar essa tarefa para o gravador XAML, como uma otimização de desempenho para os consumidores de gravador de objetos XAML do fluxo de nós.

Certas diretivas destinam-se especificamente a fornecer mais informações para a criação de um objeto a partir de um elemento de objeto. Estas directivas são: Initialization, , , TypeArgumentsPositionalParametersFactoryMethod, Arguments. Os leitores XAML dos Serviços XAML do .NET tentam colocar essas diretivas como os primeiros membros no fluxo de nó após o , de um objeto, por motivos explicados StartObjectna próxima seção.

Comportamento e ordem do nó XamlObjectWriter

StartObject to a não é necessariamente um sinal para o gravador de objeto XAML para construir imediatamente a XamlObjectWriter instância do objeto. O XAML inclui vários recursos de linguagem que tornam possível inicializar um objeto com entrada adicional e não depender inteiramente da invocação de um construtor sem parâmetros para produzir o objeto inicial e, só então, definir propriedades. Esses recursos incluem: XamlDeferLoadAttribute; texto de inicialização; x:TypeArguments; parâmetros posicionais de uma extensão de marcação; métodos de fábrica e nós x:Arguments associados (XAML 2009). Cada um desses casos atrasa a construção do objeto real e, como o fluxo de nó é reordenado, o gravador de objeto XAML pode confiar em um comportamento de realmente construir a instância sempre que um membro inicial for encontrado que não seja especificamente uma diretiva de construção para esse tipo de objeto.

GetObject

GetObject representa um nó XAML onde, em vez de construir um novo objeto, um gravador de objeto XAML deve obter o valor da propriedade que contém o objeto. Um caso típico em que um nó é encontrado em um fluxo de nó XAML é para um objeto de coleção ou um GetObject objeto de dicionário, quando a propriedade contendo é deliberadamente somente leitura no modelo de objeto do tipo de suporte. Nesse cenário, a coleção ou dicionário geralmente é criado e inicializado (geralmente vazio) pela lógica de inicialização de um tipo proprietário.