Compartilhar via

Classe XAMLServices e leitura ou escrita XAML básica

  • Artigo

XamlServices é uma classe fornecida pelo .NET que pode ser usada para lidar com cenários XAML que não exigem acesso específico ao fluxo de nós XAML ou às informações do sistema de tipo XAML obtidas desses nós. XamlServices API pode ser resumida da seguinte maneira: Load ou Parse para dar suporte a um caminho de carga XAML, Save para dar suporte a um caminho de salvamento XAML e Transform para fornecer uma técnica que une um caminho de carga e salva o caminho. Transform pode ser usado para alterar de um esquema XAML para outro. Este tópico resume cada uma dessas classificações de API e descreve as diferenças entre sobrecargas de método específicas.

Carga

Várias sobrecargas de Load implementar a lógica completa para um caminho de carga. O caminho de carga usa XAML em algum formato e gera um fluxo de nó XAML. A maioria desses caminhos de carga usa XAML em um formulário de arquivo de texto XML codificado. No entanto, você também pode carregar um fluxo geral ou carregar uma fonte XAML pré-carregada que já está contida em uma implementação de XamlReader diferente.

A sobrecarga mais simples para a maioria dos cenários é Load(String). Essa sobrecarga tem um parâmetro fileName que é simplesmente o nome de um arquivo de texto que contém o XAML a ser carregado. Isso é apropriado para cenários de aplicativo, como aplicativos de confiança total que já serializaram o estado ou os dados para o computador local. Isso também é útil para estruturas em que você está definindo o modelo de aplicativo e deseja carregar um dos arquivos padrão que define o comportamento do aplicativo, a interface do usuário inicial ou outros recursos definidos por estrutura que usam XAML.

Load(Stream) tem cenários semelhantes. Essa sobrecarga poderá ser útil se o usuário escolher arquivos para carregar, pois um Stream é uma saída frequente de outras APIs System.IO que podem acessar um sistema de arquivos. Ou você pode estar acessando fontes XAML por meio de downloads assíncronos ou outras técnicas de rede que também fornecem um fluxo. (O carregamento de um fluxo ou de uma fonte selecionada pelo usuário pode ter implicações de segurança. Para obter mais informações, consulte considerações de segurança XAML.)

Load(TextReader) e Load(XmlReader) são sobrecargas que dependem de leitores de formatos de versões anteriores do .NET. Para usar essas sobrecargas, você já deve ter criado uma instância de leitor e usado sua API Create para carregar o XAML no formato relevante (texto ou XML). Se você já moveu ponteiros de registro em outros leitores ou executou outras operações com eles, isso não é importante. A lógica do caminho de carga de Load sempre processa toda a entrada XAML da raiz para baixo. Os seguintes cenários podem justificar o uso dessas sobrecargas:

  • Superfícies de design em que você fornece uma funcionalidade de edição XAML simples de um editor de texto específico de XML existente.

  • Variantes dos principais cenários de System.IO, em que você usa os leitores dedicados para abrir arquivos ou fluxos. Sua lógica executa verificação rudimentar ou processamento do conteúdo antes de tentar carregar como XAML.

Você pode carregar um arquivo ou fluxo ou carregar um XmlReader, TextReaderou XamlReader que encapsula sua entrada XAML carregando com as APIs do leitor.

Internamente, cada uma das sobrecargas anteriores é, em última análise, Load(XmlReader)e a XmlReader passada é usada para criar um novo XamlXmlReader.

A assinatura Load que fornece cenários mais avançados é Load(XamlReader). Você pode usar essa assinatura para um dos seguintes casos:

  • Você definiu sua própria implementação de um XamlReader.

  • Você precisa especificar configurações para XamlReader que variam das configurações padrão.

Exemplos de configurações não padrão:

AllowProtectedMembersOnRoot
BaseUri
IgnoreUidsOnPropertyElements
LocalAssembly
ValuesMustBeString.

O leitor padrão para XamlServices é XamlXmlReader. Se você fornecer seu próprio XamlXmlReader com configurações, as propriedades a seguir serão definidas XamlXmlReaderSettingsnão padrão:

CloseInput
SkipXmlCompatibilityProcessing
XmlLang
XmlSpacePreserve

Analisar

Parse é como Load porque é uma API de caminho de carga que cria um fluxo de nó XAML da entrada XAML. No entanto, nesse caso, a entrada XAML é fornecida diretamente como uma cadeia de caracteres que contém todo o XAML a ser carregado. Parse é uma abordagem leve mais apropriada para cenários de aplicativo do que cenários de estrutura. Para obter mais informações, consulte Parse. Parse é apenas uma chamada Load(XmlReader) encapsulada que envolve um StringReader internamente.

Salvar

Várias sobrecargas de Save implementar o caminho de salvamento. Todos os métodos Save tomam um grafo de objeto como entrada e produzem saída como um fluxo, arquivo ou XmlWriter/TextWriter instância.

Espera-se que o objeto de entrada seja o objeto raiz de alguma representação de objeto. Essa pode ser a única raiz de um objeto de negócios, a raiz de uma árvore de objetos para uma página em um cenário de interface do usuário, a superfície de edição de trabalho de uma ferramenta de design ou outros conceitos de objeto raiz apropriados para cenários.

Em muitos cenários, a árvore de objetos salva está relacionada a uma operação original que carregou XAML com Load ou com outra API implementada por um modelo de estrutura/aplicativo. Pode haver diferenças capturadas na árvore de objetos que se devem a alterações de estado, alterações em que seu aplicativo capturou configurações de runtime de um usuário, XAML alterado porque seu aplicativo é uma superfície de design XAML etc. Com ou sem alterações, o conceito de primeiro carregar XAML da marcação e salvá-lo novamente e comparar os dois formulários de marcação XAML às vezes é chamado de representação de ida e volta do XAML.

O desafio de salvar e serializar um objeto complexo definido em uma forma de marcação é alcançar um equilíbrio entre a representação completa sem perda de informações, versus a verbosidade que torna o XAML menos legível por humanos. Além disso, clientes diferentes para XAML podem ter definições ou expectativas diferentes sobre como esse equilíbrio deve ser definido. As APIs de Save representam uma definição desse equilíbrio. As APIs de Save usam o contexto de esquema XAML disponível e as características padrão baseadas em CLR de XamlType, XamlMembere outros conceitos de sistema de tipo XAML intrínsecos e XAML para determinar onde determinados constructos de fluxo de nó XAML podem ser otimizados quando são salvos novamente na marcação. Por exemplo, XamlServices caminhos de salvamento podem usar o contexto de esquema XAML padrão baseado em CLR para resolver XamlType para objetos, pode determinar um XamlType.ContentPropertye, em seguida, pode omitir marcas de elemento de propriedade ao gravar a propriedade no conteúdo XAML do objeto.

Transformar

Transform converte ou transforma XAML vinculando um caminho de carga e um caminho de salvamento como uma única operação. Um contexto de esquema diferente ou um sistema de tipo de backup diferente pode ser usado para XamlReader e XamlWriter, que é o que influencia a forma como o XAML resultante é transformado. Isso funciona bem para operações de transformação amplas.

Para operações que dependem de examinar cada nó em um fluxo de nó XAML, normalmente você não usa Transform. Em vez disso, você precisa definir sua própria série de operações de caminho de salvamento de caminho de carga e interjetar sua própria lógica. Em um dos caminhos, use um par de gravadores XAML/leitor XAML em torno de seu próprio loop de nó. Por exemplo, carregue o XAML inicial usando XamlXmlReader e entre nos nós com chamadas Read sucessivas. Operando no nível de fluxo do nó XAML, agora você pode ajustar nós individuais (tipos, membros, outros nós) para aplicar uma transformação ou deixar o nó as-is. Em seguida, você envia o nó em diante para a API de Write relevante de um XamlObjectWriter e grava o objeto. Para obter mais informações, consulte Noções básicas sobre estruturas e conceitos de fluxo de nó XAML.

Consulte também