Noções básicas sobre conceitos e estruturas de fluxo XAML nó
Os leitores XAML e gravadores XAML, conforme implementado.NET Framework XAML Services baseiam-se no conceito de design de um fluxo de nó XAML. O fluxo de nó XAML é uma conceituação, passando de um conjunto de nós XAML. Na conceituação esta passando, um processador XAML percorre a estrutura das relações no XAML em um nó por vez. A qualquer momento, existe a apenas um registro atual ou a posição atual em um fluxo de nó XAML aberto e muitos aspectos da API relatam somente 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. Tratando o XAML como um fluxo de nó XAML, os leitores XAML podem se comunicar com os gravadores XAML e permitir que um programa exibir, interagir com ou alterar o conteúdo de um fluxo de nó XAML durante um caminho de carregar ou salvar operação de caminho que envolve o XAML. Projeto de API de leitor e gravador XAML e o conceito de fluxo XAML nó assemelham anterior leitor relacionado e designs de gravador e conceitos, como o XML Document Object Model (DOM) e o XmlReader e XmlWriter classes. Este tópico aborda conceitos de fluxo XAML nó e descreve como você pode escrever rotinas que interagem com representações de XAML no nível do nó do XAML.
Este tópico contém as seguintes seções.
- Carregar o XAML em um leitor XAML
- Um Loop de nó de leitura básica
- Trabalhando com o nó atual
- Atravessando e inserir nós de objeto
- Valor conversores e o fluxo XAML nó
- Membros XAML e XML idioma definido no fluxo de XAML nó
- Ordem do nó
- Tópicos relacionados
Carregar o XAML em um leitor XAML
Base da XamlReader classe 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 XamlObjectReader lê um gráfico de objeto, iniciando a partir da fonte de entrada de um único objeto que representa a raiz ou base. O XamlObjectReader , em seguida, produz um fluxo de nó XAML do objeto gráfico.
O mais proeminente.Services–defined de XAML do NET Framework XamlReader é a subclasse XamlXmlReader. XamlXmlReadercarrega um XAML inicial, por carregar um arquivo de texto diretamente por meio de um caminho de arquivo ou fluxo ou indiretamente por meio de uma classe de leitor relacionados, como TextReader. O XamlReader pode ser pensado como contendo na íntegra a fonte de entrada de XAML, depois de ter carregado. No entanto, o XamlReader API base foi projetado para que o leitor está interagindo com um único nó do XAML. Quando carregada pela primeira vez, o primeiro nó único que você encontrar é a raiz de XAML e o objeto de início.
O conceito de fluxo XAML nó
Se você estiver mais familiarizado com DOM, metáfora da árvore ou a abordagem baseada em consulta em direção ao acessar tecnologias baseadas em XML, uma maneira útil a formarem um fluxo de nó XAML é a seguinte. Imagine que o XAML carregado é um DOM ou uma árvore onde cada nó possível é expandido completamente e, então, apresentada linearmente. Conforme você avança através de nós, você talvez atravessando "in" ou "out" de níveis que seriam relevantes para um DOM, mas o XAML de fluxo de nó não explicitamente controlar porque esses conceitos de nível não são relevantes para um fluxo de nó. O fluxo de nó tem um "atual" Posicionar, mas a menos que você armazenou outras partes do fluxo faz referência a mesmo como todos os aspectos do fluxo de nó diferente, por exemplo, a posição do nó atual estão fora do modo de exibição.
O conceito de fluxo de nó XAML tem a vantagem notável que se você percorrer o fluxo do nó inteiro, você pode contar que processou a representação de XAML inteira; Você não precisa se preocupar que uma consulta, uma operação de DOM ou outra abordagem não linear para processamento de informações tenha perdido alguma parte da representação completa do XAML. Por esse motivo, a representação de fluxo XAML nó é ideal para conectar os leitores XAML e gravadores XAML e para fornecer um sistema onde você pode inserir seu próprio processo que funciona entre as fases de leitura e gravação de uma operação de processamento de XAML. Em muitos casos, a ordenação de nós no fluxo do nó do XAML é deliberadamente otimizada ou reordenada pelos leitores do XAML em vez de como a ordem pode aparecer no texto de origem, binário ou gráfico do objeto. Esse comportamento destina-se para impor uma arquitetura de processamento XAML na qual os gravadores XAML são nunca em uma posição onde eles Voltar "" no fluxo do nó. Idealmente, XAML todas as operações de gravação deve ser capaz de atuar baseado no contexto de esquema mais a posição atual do fluxo de nó.
Um Loop de nó de leitura básica
Um basic loop de nó para examinar o fluxo de um nó XAML consiste nos seguintes conceitos de leitura. Para fins de nó loops conforme discutido neste tópico, suponha que você está lendo um XAML baseado em texto e humanamente legível usando o arquivo XamlXmlReader. Consultem os links desta seção o loop de nó específico do XAML API implementada pelo XamlXmlReader.
Certifique-se de que não estão no final do fluxo de nó de XAML (verificar IsEof, ou use o Read() valor de retorno). Se você estiver no final do fluxo, não há nenhum nó atual e você deve sair.
Verifique o tipo de nó de fluxo XAML nó atualmente expõe chamando NodeType.
Se você tiver um gravador de objeto associado XAML que está conectado diretamente, você geralmente chama WriteNode nesse ponto.
Com base no qual XamlNodeType é relatado como o nó atual ou o registro atual, ligue para um dos procedimentos a seguir para obter informações sobre o conteúdo do nó:
Para um NodeType de StartMember ou EndMember, chamada Member para obter XamlMember informações sobre um membro. Observe que o membro pode ser um XamlDirective, e portanto pode não ser necessariamente convencional membro definido pelo tipo de objeto anterior. Por exemplo, x:Name aplicado a um objeto aparece como um membro XAML onde IsDirective é verdadeiro e o Name do membro é Name, com outras propriedades, indicando que essa diretiva está a linguagem XAML namespace XAML.
Para um NodeType de StartObject ou EndObject, chamada Type para obter XamlType informações sobre um objeto.
For a NodeType of Value, call Value. Um nó é um valor somente se estiver a expressão mais simples de um valor para um membro ou o texto de inicialização para 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 NodeType de NamespaceDeclaration, chamada Namespace para obter informações de namespace para um nó de namespace.
Chame Read para avançar o leitor de XAML para o próximo nó de fluxo XAML nó e repita as etapas novamente.
O fluxo de nó XAML fornecido pelo.Os leitores de XAML de serviços do NET Framework XAML sempre fornece uma passagem completa, detalhada de todos os nós possíveis. Técnicas de controle de fluxo típico para um loop de nó XAML incluem a definição de um corpo em while (reader.Read())e o switching em NodeType em cada ponto do nó no loop de nó.
Se o fluxo de nó no fim do arquivo, o nó atual é nulo.
O loop mais simples que usa um leitor e gravador lembra o 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 carga transparente, conecta-se o leitor de XAML e o gravador XAML, fazendo nada diferente do que se você tivesse usado XamlServices.Parse. Mas essa estrutura básica é expandida para aplicar ao seu cenário de escrita ou de leitura. Alguns cenários possíveis são:
Alternar NodeType. Execute ações diferentes, dependendo de qual nó o tipo está sendo lido.
Não chame WriteNode em todos os casos. Somente chamar WriteNode em alguns NodeType casos.
Dentro da lógica de um tipo de nó específico, analisamos as especificações desse nó e agir sobre eles. Por exemplo, você poderia escrever apenas os objetos que vêm de um namespace específico do XAML e em seguida, solte ou adiar quaisquer objetos não a partir do namespace XAML. Ou você pode soltar ou caso contrário reprocessar quaisquer diretivas XAML não oferece suporte a seu sistema XAML como parte do seu processamento de membro.
Definir um personalizado XamlObjectWriter que substitui Write* métodos, possivelmente executando o mapeamento de tipo que ignora o contexto de esquema XAML.
Construir o XamlXmlReader usar um contexto de esquema XAML não padrão, de modo que o personalizado diferenças no comportamento do XAML são usadas tanto o leitor e escritor.
Acessando o XAML, além do conceito de Loop de nó
Há potencialmente outras maneiras de trabalhar com uma representação de XAML diferente, como um loop de nó XAML. Por exemplo, poderia existir um leitor XAML que pode ler um nó indexado ou em particular acessa nós diretamente por x:Name, por x:Uid, ou através de outros identificadores. .NET Framework XAML Services fornece uma implementação completa, mas fornece um padrão sugerido por meio de tipos de serviços e suporte. For more information, see IXamlIndexingReader and XamlNodeList.
Observação
Também, a Microsoft produz uma versão de out-of-band, conhecida como Toolkit de XAML Microsoft.Esta versão de out-of-band ainda está em seus estágios de pré-lançamento.No entanto, se você estiver disposto a trabalhar com componentes de pré-lançamento, o Toolkit de XAML Microsoft fornece alguns recursos interessantes para ferramentas de XAML e análise estática de XAML.Toolkit de XAML Microsoft inclui uma API do DOM XAML, suporte para análise de FxCop e um contexto de esquema XAML do Silverlight.For more information, see Microsoft XAML Toolkit.
Trabalhando com o nó atual
A maioria dos cenários, usar um loop de nó XAML não lêem somente os nós. A maioria dos cenários processar nós atuais e passar cada nó, um por vez para uma implementação de XamlWriter.
No cenário de caminho típico de carga, um XamlXmlReader produz um fluxo de nó XAML; os nós XAML são processados de acordo com a lógica e o contexto de esquema XAML; e os nós são passados para um XamlObjectWriter. Em seguida, você pode integrar o gráfico resultante do objeto em seu aplicativo ou framework.
Em um típico cenário de caminho, de salvar um XamlObjectReader lê o gráfico do objeto, nós individuais de XAML são processadas e um XamlXmlWriter apresenta o resultado serializado como um arquivo de texto XAML. A chave é que tanto os caminhos cenários envolvem o trabalho com exatamente um nó XAML ao mesmo tempo e os nós XAML estão disponíveis para o tratamento de uma maneira padronizada que é definida pelo sistema de tipos XAML e o.NET Framework APIs de serviços XAML.
Quadros e escopo
Um loop de nó XAML percorre o fluxo de um nó XAML de maneira linear. O fluxo de nó percorre em objetos, os membros que contêm outros objetos e assim por diante. Muitas vezes é útil controlar o escopo dentro do fluxo de XAML nó implementando um conceito de quadro e a pilha. Isso é especialmente verdadeiro se você está ajustando ativamente o fluxo do nó enquanto estiver nela. O quadro e a pilha de suportam que você implemente como parte de sua lógica de loop de nó poderia contar StartObject (ou GetObject) e EndObject escopos conforme você passem para uma estrutura de nó XAML se a estrutura é pensada de uma perspectiva de DOM.
Atravessando e inserir nós de objeto
O primeiro nó em um fluxo de nó quando ele é aberto por um leitor XAML é o nó de objeto do início do objeto raiz. Por definição, este objeto está sempre um nó único objeto e nenhum par. Qualquer exemplo de 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 tem um ou mais nós de objeto ou também podem encerrar em um nó de valor em vez disso. O objeto raiz normalmente define XAML namescopes, que são atribuídos sintaticamente como atributos de marcação de texto XAML, mas mapear para uma Namescope o tipo de nó na representação de fluxo do XAML do nó.
Considere o seguinte exemplo XAML (Este é o XAML arbitrário, não é feito por tipos existentes na.NET Framework). Assumir que, nesse modelo de objeto, FavorCollection é List<T> de Favor, Balloon e NoiseMaker são pode ser atribuído a Favor, o Balloon.Color propriedade é feita por um Color objeto semelhante à forma como o WPF define as cores como nomes de cor conhecida, e Color suporta um conversor de tipo para a sintaxe de atributo.
Marcação XAML |
Fluxo resultante do nó de XAML |
---|---|
<Party |
NamespacenóParty |
xmlns="PartyXamlNamespace"> |
StartObjectnóParty |
<Party.Favors> |
StartMembernóParty.Favors |
StartObjectnó implícitaFavorCollection |
|
StartMembernó implícito FavorCollection propriedade de itens. |
|
<Balloon |
StartObjectnóBalloon |
Color="Red" |
StartMembernóColor Valuenó para a seqüência de caracteres do valor de atributo"Red" EndMemberparaColor |
HasHelium="True" |
StartMembernóHasHelium Valuenó para a seqüência de caracteres do valor de atributo"True" EndMemberparaHasHelium |
> |
EndObjectparaBalloon |
<NoiseMaker>Loudest</NoiseMaker> |
StartObjectnóNoiseMaker StartMembernó_Initialization Valuenó para a seqüência de caracteres do valor de inicialização"Loudest" EndMembernó_Initialization EndObjectparaNoiseMaker |
EndMembernó implícito FavorCollection propriedade de itens. |
|
EndObjectnó implícitaFavorCollection |
|
</Party.Favors> |
EndMemberparaFavors |
</Party> |
EndObjectparaParty |
No fluxo de nó de XAML, você pode contar com o seguinte comportamento:
Se um Namespace nó existe, ele é adicionado ao fluxo imediatamente antes do StartObject que declarado o namespace XAML com xmlns. Examine a tabela anterior com o fluxo de nó XAML e exemplo novamente. Observe como o StartObject e Namespace nós parecem ser transposto versus suas posições de declaração na marcação de texto. Esse é representativo do comportamento de onde os nós de namespace aparecem sempre à frente do nó eles se aplicam a no fluxo do nó. A finalidade desse design é que as informações de namespace são vitais para os escritores de objeto e devem ser conhecidas antes que as tentativas de gravador de objeto para executar o tipo de mapeamento ou caso contrário, o objeto de processo. Colocar as informações do namespace XAML à frente do seu escopo de aplicativo no fluxo se torna mais simples para sempre processar o fluxo do nó em sua ordem apresentada.
Devido a consideração acima, é um ou mais Namespace nós que você leia primeiro na maioria dos casos de marcação do mundo real quando atravessando nós desde o início, não o StartObject de raiz.
A StartObject nó pode ser seguido por StartMember, Value, ou imediata EndObject. Ele nunca é seguido imediatamente por outra StartObject.
A StartMember pode ser seguido por um StartObject, Value, ou imediata EndMember. Pode ser seguido por GetObject, para onde o valor deve ser provenientes de um valor existente do objeto pai de membros em vez de um StartObject que seria instanciar um novo valor. Também pode ser seguido por um Namespace nó, o qual se aplica para um futuro StartObject. Ele nunca é seguido imediatamente por outra StartMember.
A Value nó representa o valor em si; Não há "endvalue". Pode ser seguido apenas por um EndMember.
Texto de inicialização de XAML do objeto, como pode ser usado por construção não resulta em uma estrutura de valor do objeto. Em vez disso, um nó dedicado de membro de um membro chamado _Initialization é criado. e o nó do membro contém a seqüência de caracteres do valor de inicialização. Se ele existir, _Initialization é sempre o primeiro StartMember. _Initializationpodem ser qualificados em algumas representações de serviços XAML com namescope XAML a linguagem XAML, esclarecer que _Initialization é não uma propriedade definida em tipos de backup.
Uma combinação de valor do membro representa uma configuração do valor de atributo. Pode eventualmente haver um conversor de valor envolvidos no processamento esse valor e o valor é uma seqüência de caracteres simples. No entanto, que não é avaliada até que um escritor de objeto XAML processa este fluxo de nó. O gravador de objeto XAML possui outro suporte necessário para conversões de valor, digite o mapeamento do sistema e o contexto de esquema XAML necessário.
Um EndMember nó pode ser seguido por um StartMember nó para o membro subseqüente, ou por um EndObject o nó para o proprietário do membro.
Um EndObject nó pode ser seguido por um EndMember nó. Também pode ser seguido por um StartObject o nó para casos onde os objetos estão no mesmo nível em de itens. uma coleção Ou pode ser seguido por um Namespace nó, o qual se aplica para um futuro StartObject.
- No caso de exclusivo de fechar o fluxo de nó inteiro, o EndObject da raiz não é seguido por qualquer coisa; o leitor agora é o fim do arquivo, e Read retorna false.
Valor conversores e o fluxo XAML nó
Um conversor de valor é um termo geral para uma extensão de marcação, um conversor de tipo (incluindo serializadores de valor) ou de outra classe dedicado que é relatado como um conversor de valor através do sistema de tipo XAML. No fluxo de nó de XAML, um uso de tipo de conversor e um uso de extensão de marcação tem representações muito diferentes.
Conversores de tipo no fluxo de XAML nó
Um atributo definido que eventualmente resulta em um tipo de uso de conversor é relatado no fluxo de nó de 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. Usando a implementação de conversão do conversor de tipo requer invocando o contexto de esquema XAML e usá-lo para o mapeamento de tipo. Até mesmo determinar qual tipo de conversor de classe deve ser usado para processar o valor requer o contexto de esquema XAML indiretamente. Quando você usa o contexto de esquema XAML padrão, essas informações são disponíveis no sistema de tipo XAML. Se você precisar que as informações de classe do conversor de tipo no nível do fluxo de XAML nó antes da conexão com um gravador XAML, você pode obtê-lo do XamlMember informações do membro que está sendo definido. Mas, caso contrário, entrada do conversor de tipo deve ser preservada no fluxo de nó de XAML como um valor simples até que o restante das operações que exigem o sistema de mapeamento de tipo e o contexto de esquema XAML é executado, por exemplo, a criação do objeto XAML objeto gravador.
Por exemplo, considere a seguinte estrutura de tópicos de definição de classe e o uso XAML para ele:
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ó de XAML para este uso pode ser expresso como a seguir:
StartObjectcom XamlType representando GameBoard
StartMembercom XamlMember representando BoardSize
Valuenó, com a seqüência de caracteres de texto "8x8"
EndMembercorrespondênciasBoardSize
EndObjectcorrespondênciasGameBoard
Observe que não há nenhuma instância do conversor de tipo no fluxo neste nó. Mas você pode obter informações sobre o conversor tipo chamando XamlMember.TypeConverter sobre o XamlMember para BoardSize. Se você tiver um contexto de esquema válido do XAML, você também pode chamar os métodos de conversor obtendo uma instância de ConverterInstance.
Extensões de marcação de fluxo XAML nó
Um uso de extensão de marcação é relatado no fluxo de nó de 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 a representação de fluxo de nó que é um uso de tipo de conversor e transporta as informações mais. XamlMemberinformações poderiam não ter lhe disse algo sobre a extensão de marcação, porque o uso é situacional e varia em cada caso de marcação possíveis; não é dedicado e implícita, por tipo ou membro assim como acontece com os conversores de tipo.
A representação de fluxo de nó de extensões de marcação como nós de objeto é o caso mesmo se o uso de extensão de marcação foi feito no formulário de atributo na marcação de texto XAML (que é geralmente o caso). Usos da extensão de marcação usado 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, podem ser membros de extensão de marcação. A representação de fluxo XAML nó preserva o uso do que a extensão de marcação, seja o uso de um parâmetro posicional ou um com os parâmetros nomeados explícitos.
Para o uso de um parâmetro posicional, o fluxo de nó XAML contém uma propriedade de definição de linguagem XAML _PositionalParameters que registra o uso. Esta propriedade é um genérico List<T> com Object restrição. A restrição é objeto e não string porque perfeitamente o uso de um parâmetro posicional poderia conter os usos de extensão de marcação aninhadas dentro dela. Para acessar a parâmetros posicionais com o uso, você pode percorrer a lista e usar os indexadores para valores de lista individuais.
Para o uso de parâmetro nomeado cada parâmetro nomeado é representado como um nó de membro, esse nome no fluxo do nó. Os valores de membro não são necessariamente cadeias de caracteres, porque pode haver um uso de extensão de marcação aninhadas.
ProvideValueda marcação extensão não é ainda invocado. No entanto, é invocado se você se conectar a um leitor XAML e o gravador XAML para que WriteEndObject é chamado no nó de extensão de marcação quando você examinar a ele no fluxo de nó. Por esse motivo, você geralmente precisa mesmo contexto de esquema XAML disponível como seria usado para formar o gráfico do objeto no caminho de carga. Caso contrário, ProvideValue a partir de qualquer marcação extensão pode lançar exceções aqui, porque não tem os serviços esperados disponíveis.
Membros XAML e XML idioma definido no fluxo de XAML nó
Determinados membros são introduzidos em um fluxo de nó XAML devido de interpretações e convenções de um leitor XAML, em vez de por meio de um explícita XamlMember pesquisa ou construção. Geralmente, esses membros estão as diretivas XAML. Em alguns casos, é o ato de leitura de XAML que apresenta a diretiva no fluxo de nó de XAML. Em outras palavras, o texto XAML de entrada original não explicitamente especificou a diretiva do membro, mas o leitor XAML insere a diretiva para atender um XAML convenção e relatar informações estruturais no fluxo XAML nó antes que essas informações serão perdidas.
A lista a seguir notas de todos os casos onde um leitor XAML é esperado para apresentar um nó Diretiva de membro XAML e como o nó do membro é identificado na.Implementações de serviços do NET Framework XAML.
Texto de inicialização para um nó de objeto: O nome do nó membro é _Initialization, ele representa uma diretiva XAML, e ele é definido na linguagem XAML namespace XAML. Você pode obter uma entidade estática para ele de Initialization.
Parâmetros de posição para uma extensão de marcação: O nome do nó membro é _PositionalParameters, e ela está definida na linguagem XAML namespace XAML. Ele sempre contém uma lista genérica de objetos, cada um deles é um parâmetro posicional pre-separated dividindo-se na , caractere delimitador, conforme fornecido na entrada do XAML. Você pode obter uma entidade estática para a diretiva de parâmetros de posição de PositionalParameters.
Conteúdo desconhecido: O nome do nó membro é _UnknownContent. Estritamente falando, é um XamlDirective, e ela está definida na linguagem XAML namespace XAML. Essa diretiva é usada como um sentinel casos em que um elemento de objeto XAML contém o conteúdo na fonte de XAML, mas nenhuma propriedade de conteúdo pode ser determinada no contexto de esquema XAML disponível no momento. Você pode detectar neste caso em um fluxo de nó XAML, verificando membros chamados _UnknownContent. Se nenhuma outra ação é executada em um fluxo de nó XAML do caminho de carga, o padrão XamlObjectWriter lança tentativa WriteEndObject quando encontra a _UnknownContent membro no objeto. O padrão XamlXmlWriter não emite e trata o membro como implícita. Você pode obter uma entidade estática para _UnknownContent de UnknownContent.
**Propriedade de coleção de uma coleção:**Embora o tipo CLR de backup de uma classe de coleção é usado geralmente para XAML tem dedicado denominado propriedade que contém os itens da coleção, essa propriedade não é conhecida para um sistema de tipos XAML para a realização de resolução de tipo. Em vez disso, o fluxo de nó XAML introduz uma Items espaço reservado como um membro da coleção do tipo XAML. No.NET o nome dessa diretiva a implementação de serviços de estrutura XAML / membro no fluxo de nó é _Items. Uma constante para essa diretiva pode ser obtida em Items.
Observe que o fluxo de um nó XAML pode conter uma propriedade Items com itens ficam não pode ser analisado com base no contexto de esquema XAML e resolução de tipo de backup. For example,
Membros definidos pelo XML: Definidos pelo XML xml:base, xml:lang e xml:space membros são relatados como diretivas XAML chamadas base, lang, e space na.NET Framework XAML Services implementações. O namespace para eles é o namespace XML http://www.w3.org/XML/1998/namespace. Constantes para cada um deles podem ser obtidos em XamlLanguage.
Ordem do nó
Em alguns casos, XamlXmlReader altera a ordem de nós XAML no fluxo de nó de XAML, em comparação com a ordem em que os nós exibidos se visualizados na marcação ou processado como XML. Isso é feito para solicitar os nós de tal forma que um XamlObjectWriter pode processar o fluxo de nó em um modo somente de encaminhamento. No.NET Framework XAML Services, o leitor XAML reordena a nós em vez de deixar esta tarefa para o gravador XAML como uma otimização de desempenho para os consumidores do XAML objeto gravador do fluxo de nó.
Determinadas diretivas destinam-se especificamente para fornecer mais informações para a criação de um objeto de um elemento de objeto. Essas diretivas são: Initialization, PositionalParameters, TypeArguments, FactoryMethod, Arguments. A.Os leitores de XAML de serviços do NET Framework XAML tentam colocar essas diretivas como participantes primeiro no fluxo nó após um objeto StartObject, por motivos explicados na próxima seção.
Ordem de nó e o comportamento de XamlObjectWriter
StartObjectpara um XamlObjectWriter é não necessariamente um sinal para o gravador de objeto XAML imediatamente construir a instância do objeto. XAML inclui vários recursos de linguagem que tornam possível inicializar um objeto com entrada adicional e não depender inteiramente chamar um construtor padrão para produzir o objeto inicial e só então definindo propriedades. Esses recursos incluem: XamlDeferLoadAttribute; texto de inicialização; X:TypeArguments; parâmetros de posição de uma extensão de marcação; os métodos de fábrica e associados Argumentos de x: nós (XAML de 2009). Cada um desses casos atrasar a construção do objeto real e porque o fluxo de nó é reordenado, o gravador de objeto XAML pode depender de um comportamento de realmente construir a instância, sempre que um membro de início é encontrado, não é especificamente uma diretiva de construção para esse tipo de objeto.
GetObject
GetObjectrepresenta um nó XAML onde em vez de construir um novo objeto, um gravador de objeto XAML deve em vez disso, obter o valor da propriedade de recipiente do objeto. Um caso típico onde uma GetObject nó for encontrado em um nó XAML fluxo é para um objeto de coleção ou um objeto de dicionário, quando a propriedade recipiente é deliberadamente somente leitura no modelo de objeto. do tipo de backup Nesse cenário, a coleção ou dicionário geralmente é criado e inicializado (geralmente vazio) pela lógica de inicialização de um tipo de proprietário.