Partilhar via

Namespaces XAML e mapeamento de namespace

Este tópico explica os mapeamentos de namespace XML/XAML (xmlns) encontrados no elemento raiz da maioria dos arquivos XAML. Ele também descreve como produzir mapeamentos semelhantes para tipos e assemblies personalizados.

Como os namespaces XAML se relacionam com bibliotecas de tipos e definições de código

Tanto em sua finalidade geral quanto para sua aplicação à programação de aplicativos do Tempo de Execução do Windows, o XAML é usado para declarar objetos, propriedades desses objetos e relações objeto-propriedade expressas como hierarquias. Os objetos declarados em XAML são apoiados por bibliotecas de tipos ou outras representações definidas por outras técnicas e linguagens de programação. Essas bibliotecas podem ser:

  • O conjunto embutido de objetos para o Windows Runtime. Este é um conjunto fixo de objetos, e acessar esses objetos a partir de XAML usa mapeamento de tipo interno e lógica de ativação.
  • Bibliotecas distribuídas fornecidas pela Microsoft ou por terceiros.
  • Bibliotecas que representam a definição de um controle de terceiros que seu aplicativo incorpora e seu pacote redistribui.
  • Sua própria biblioteca, que faz parte do seu projeto e que contém algumas ou todas as suas definições de código de usuário.

As informações de tipo subjacente estão associadas a definições de namespace XAML específicas. Estruturas XAML, como o Windows Runtime, podem agregar múltiplos assemblies e múltiplos namespaces de código para mapear para um único namespace XAML. Isso habilita o conceito de um vocabulário XAML que abrange uma estrutura ou tecnologia de programação maior. Um vocabulário XAML pode ser bastante extenso — por exemplo, a maioria dos XAML documentados para aplicativos do Tempo de Execução do Windows nesta referência constitui um único vocabulário XAML. Um vocabulário XAML também é extensível: você o estende adicionando tipos às definições de código de suporte, certificando-se de incluir os tipos em namespaces de código que já são usados como fontes de namespace mapeadas para o vocabulário XAML.

Um processador XAML pode procurar tipos e membros dos assemblies de suporte associados a esse namespace XAML quando cria uma representação de objeto em tempo de execução. É por isso que o XAML é útil como uma maneira de formalizar e trocar definições de comportamento de construção de objeto e por que o XAML é usado como uma técnica de definição de interface do usuário para um aplicativo do Tempo de Execução do Windows.

Os namespaces XAML no uso típico de marcação XAML

Um arquivo XAML quase sempre declara um namespace XAML padrão em seu elemento raiz. O namespace XAML padrão define quais elementos você pode declarar sem qualificá-los por um prefixo. Por exemplo, se você declarar um elemento <Balloon />, um analisador XAML esperará que um elemento Balão exista e seja válido no namespace XAML padrão. Por outro lado, se Balloon não estiver no namespace XAML padrão definido, você deverá qualificar esse nome de elemento com um prefixo, por exemplo <party:Balloon />. O prefixo indica que o elemento existe em um namespace XAML diferente do namespace padrão, e você deve mapear um namespace XAML para o grupo de prefixo antes de poder usar esse elemento. Os namespaces XAML se aplicam ao elemento específico no qual são declarados e também a qualquer elemento contido por esse elemento na estrutura XAML. Por esse motivo, os namespaces XAML são quase sempre declarados em elementos raiz de um arquivo XAML para aproveitar essa herança.

As declarações de namespace XAML padrão e de linguagem XAML

Dentro do elemento raiz da maioria dos arquivos XAML, há duas declarações xmlns . A primeira declaração mapeia um namespace XAML como padrão: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Este é o mesmo identificador de namespace XAML usado em várias tecnologias anteriores da Microsoft que também usam XAML como um formato de marcação de definição de interface do usuário. O uso do mesmo identificador é deliberado e é útil quando você migra a interface do usuário definida anteriormente para um aplicativo do Tempo de Execução do Windows em C++, C# ou Visual Basic.

A segunda declaração mapeia um namespace XAML separado para os elementos de linguagem definidos por XAML, mapeando-o (normalmente) para o prefixo "x:": xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Esse valor xmlns e o prefixo "x:" para o qual ele é mapeado também são idênticos às definições usadas em várias tecnologias anteriores da Microsoft que usam XAML.

A relação entre essas declarações é que XAML é uma definição de linguagem e o Tempo de Execução do Windows é uma implementação que usa XAML como uma linguagem e define um vocabulário específico onde seus tipos são referenciados em XAML.

A linguagem XAML especifica determinados elementos de linguagem, e cada um deles deve ser acessível por meio de implementações de processador XAML que trabalham no namespace XAML. A convenção de mapeamento "x:" para o namespace XAML da linguagem XAML é seguida por modelos de projeto, código de exemplo e a documentação para recursos de linguagem. O namespace da linguagem XAML define vários recursos comumente usados que são necessários até mesmo para aplicativos básicos do Tempo de Execução do Windows. Por exemplo, para unir qualquer code-behind a um arquivo XAML por meio de uma classe parcial, você deve nomear essa classe como o atributo x:Class no elemento raiz do arquivo XAML relevante. Ou, qualquer elemento conforme definido numa página XAML como um recurso com uma chave num ResourceDictionary e referências de recurso XAML deve ter o atributo x:Key definido para o elemento de objeto em questão.

Namespaces de código que correspondem ao namespace XAML padrão

A seguir está uma lista de namespaces de código que estão atualmente mapeados para o namespace XAML padrão.

  • Windows.UI
  • Windows.UI.Xaml
  • Windows.UI.Xaml.Automation
  • Windows.UI.Xaml.Automation.Peers
  • Windows.UI.Xaml.Automation.Provider
  • Windows.UI.Xaml.Automation.Text
  • Windows.UI.Xaml.Controls
  • Windows.UI.Xaml.Controls.Primitives
  • Windows.UI.Xaml.Data
  • Windows.UI.Xaml.Documents
  • Windows.UI.Xaml.Input
  • Windows.UI.Xaml.Interop
  • Windows.UI.Xaml.Markup
  • Windows.UI.Xaml.Media
  • Windows.UI.Xaml.Media.Animation
  • Windows.UI.Xaml.Media.Imaging
  • Windows.UI.Xaml.Media.Media3D
  • Windows.UI.Xaml.Navigation
  • Windows.UI.Xaml.Resources
  • Windows.UI.Xaml.Shapes
  • Windows.UI.Xaml.Threading
  • Windows.UI.Text

Outros namespaces XAML

Além do namespace padrão e do namespace XAML da linguagem XAML "x:", você também pode ver outros namespaces XAML mapeados no XAML padrão inicial para aplicativos conforme gerado pelo Microsoft Visual Studio.

d: (http://schemas.microsoft.com/expression/blend/2008)

O namespace XAML "d:" destina-se ao suporte ao designer, especificamente ao suporte ao designer nas superfícies de design XAML do Microsoft Visual Studio. O namespace XAML " d:" habilita atributos de designer ou de tempo de design em elementos XAML. Esses atributos de designer afetam apenas os aspetos de design de como o XAML se comporta. Os atributos de designer são ignorados quando o mesmo XAML é carregado pelo analisador XAML do Windows Runtime quando um aplicativo é executado. Geralmente, os atributos de designer são válidos em qualquer elemento XAML, mas, na prática, há apenas determinados cenários em que aplicar um atributo de designer se justifica. Em particular, muitos dos atributos do designer destinam-se a fornecer uma experiência melhor para interagir com contextos de dados e fontes de dados enquanto você está desenvolvendo XAML e código que usam vinculação de dados.

  • Atributos d:DesignHeight e d:DesignWidth: Esses atributos às vezes são aplicados à raiz de um arquivo XAML que o Visual Studio ou outra superfície de designer XAML cria para você. Por exemplo, esses atributos são definidos na raiz UserControl do XAML que é criado se você adicionar um novo UserControl ao seu projeto de aplicativo. Esses atributos facilitam o design da composição do conteúdo XAML, para que você tenha alguma antecipação das restrições de layout que podem existir quando o conteúdo XAML for usado para uma instância de controle ou outra parte de uma página de interface do usuário maior.

    Observação Se você estiver migrando XAML do Microsoft Silverlight, poderá ter esses atributos em elementos raiz que representam uma página inteira da interface do usuário. Nesse caso, convém remover os atributos. Outros recursos dos designers XAML, como o simulador, provavelmente são mais úteis para projetar layouts de página que lidam bem com dimensionamento e estados de exibição do que um layout de página de tamanho fixo usando d:DesignHeight e d:DesignWidth.

  • d:DataContext atributo: Pode definir este atributo na raiz de uma página ou num controlo para substituir qualquer DataContext explícito ou herdado que o objeto tenha.

  • Atributo d:DesignSource: Especifica uma fonte de dados em tempo de design para um CollectionViewSource, substituindo Source.

  • Extensões de marcação d:DesignInstance e d:DesignData: Essas extensões de marcação são usadas para fornecer os recursos de dados em tempo de design para d:DataContext ou d:DesignSource. Não iremos documentar exaustivamente como utilizar recursos de dados em tempo de design aqui. Para obter mais informações, consulte Design-Time Atributos. Para alguns exemplos de uso, consulte Dados de exemplo na superfície de design e para prototipagem.

MC: (http://schemas.openxmlformats.org/markup-compatibility/2006)

" mc:" indica e suporta um modo de compatibilidade de marcação para leitura de XAML. Normalmente, o prefixo "d:" está associado ao atributo mc:Ignorable. Essa técnica permite que os analisadores XAML em tempo de execução ignorem os atributos de design em "d:".

Local: e frequentes:

"local:" é um prefixo que geralmente é mapeado para você dentro das páginas XAML para um projeto de aplicativo UWP modelado. Ele é mapeado para se referir ao mesmo namespace criado para conter o atributo x:Class e o código para todos os arquivos XAML, incluindo app.xaml. Contanto que você defina quaisquer classes personalizadas que deseja usar em XAML nesse mesmo namespace, você pode usar o prefixo local: para se referir aos seus tipos personalizados em XAML. Um prefixo relacionado que vem de um projeto de aplicativo UWP modelo é comum:. Esse prefixo refere-se a um namespace "Comum" aninhado que contém classes de utilitários, como conversores e comandos, e as definições podem ser encontradas na pasta Common na exibição Solution Explorer.

VSM:

Não utilizar. "vsm:" é um prefixo que às vezes é visto em modelos XAML mais antigos importados de outras tecnologias da Microsoft. O namespace abordou originalmente um problema de ferramentas legado relacionado ao namespace. Você deve excluir as definições de namespace XAML para "vsm:" em qualquer XAML que utilizar para o Windows Runtime. Além disso, altere quaisquer usos de prefixo para VisualState, VisualStateGroup e objetos relacionados para usar o namespace XAML padrão. Para saber mais sobre a migração XAML, veja Migrando XAML/código do Silverlight ou WPF para um aplicativo do Tempo de Execução do Windows.

Mapeando tipos personalizados para namespaces e prefixos XAML

Você pode mapear um namespace XAML para poder usar XAML para acessar seus próprios tipos personalizados. Em outras palavras, você está mapeando um namespace de código como ele existe em uma representação de código que define o tipo personalizado e atribuindo-lhe um namespace XAML junto com um prefixo para uso. Os tipos personalizados para XAML podem ser definidos em uma linguagem Microsoft .NET (C# ou Microsoft Visual Basic) ou em C++. O mapeamento é feito definindo um prefixo xmlns . Por exemplo, xmlns:myTypes define um novo namespace XAML que é acessado prefixando todos os usos com o token myTypes:.

Uma definição xmlns inclui um valor, bem como a nomenclatura do prefixo. O valor é uma cadeia de caracteres que se encontra entre aspas, após o símbolo de igual. Uma convenção XML comum é associar o namespace XML a um URI (Uniform Resource Identifier), para que haja uma convenção para exclusividade e identificação. Você também vê essa convenção para o namespace XAML padrão e o namespace da linguagem XAML, bem como para alguns namespaces XAML menos usados que são utilizados pelo Windows Runtime XAML. Mas para um namespace XAML que mapeia tipos personalizados, em vez de especificar um URI, você começa a definição de prefixo com o token "using:". Após o token "using:", você nomeia o namespace do código.

Por exemplo, para mapear um prefixo "custom1" que permite fazer referência a um namespace "CustomClasses" e usar classes desse namespace ou assembly como elementos de objeto em XAML, sua página XAML deve incluir o seguinte mapeamento no elemento raiz: xmlns:custom1="using:CustomClasses"

Classes parciais do mesmo escopo de página não precisam ser mapeadas. Por exemplo, você não precisa de prefixos para fazer referência a nenhum manipulador de eventos definido para manipular eventos da definição de interface do usuário XAML de sua página. Além disso, muitas das páginas XAML iniciais dos projetos gerados pelo Visual Studio para um aplicativo Windows Runtime já mapeiam um prefixo "local:", que faz referência ao namespace padrão especificado pelo projeto e ao namespace usado por definições de classe parciais.

Regras de linguagem CLR

Se você estiver escrevendo seu código de suporte em uma linguagem .NET (C# ou Microsoft Visual Basic), você pode estar usando convenções que usam um ponto (".") como parte de nomes de namespace para criar uma hierarquia conceitual de namespaces de código. Se sua definição de namespace contiver um ponto, o ponto deverá fazer parte do valor especificado após o token "using:".

Se o arquivo code-behind ou o arquivo de definição de código for um arquivo C++, há certas convenções que ainda seguem o formulário de linguagem CLR (Common Language Runtime), para que não haja diferença na sintaxe XAML. Se você declarar namespaces aninhados em C++, o separador entre as sucessivas cadeias de caracteres de namespace aninhadas deverá ser "." em vez de "::" quando você especificar o valor que segue o token "using:".

Não use tipos aninhados (como aninhar uma enumeração dentro de uma classe) ao definir seu código para uso com XAML. Os tipos aninhados não podem ser avaliados. Não há como o analisador XAML distinguir que um ponto é parte do nome do tipo aninhado em vez de parte do nome do namespace.

Tipos e assemblies personalizados

O nome do assembly que define os tipos de suporte para um namespace XAML não é especificado no mapeamento. A lógica para a qual os assemblies estão disponíveis é controlada no nível de definição do aplicativo e faz parte da implantação básica do aplicativo e dos princípios de segurança. Declare qualquer assembly que pretenda incluir como fonte de definição de código para XAML como um assembly dependente nas definições do projeto. Para obter mais informações, consulte Criando componentes do Tempo de Execução do Windows em C# e Visual Basic.

Se você estiver fazendo referência a tipos personalizados a partir da definição de aplicativo ou definições de página do aplicativo principal, esses tipos estarão disponíveis sem configuração de assembly dependente adicional, mas você ainda deverá mapear o namespace de código que contém esses tipos. Uma convenção comum é mapear o prefixo "local" para o namespace de código padrão de qualquer página XAML. Essa convenção geralmente é incluída na inicialização de modelos de projeto para projetos XAML.

Propriedades anexadas

Se você estiver fazendo referência a propriedades anexadas, a parte do tipo proprietário do nome da propriedade anexada deverá estar no namespace XAML padrão ou ser prefixada. É raro prefixar atributos separadamente de seus elementos, mas este é um caso em que às vezes é necessário, particularmente para uma propriedade anexada personalizada. Para saber mais, veja Propriedades anexadas personalizadas.

  • Last updated on