Compartilhar 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 a definição de código e as bibliotecas de tipos

Tanto em sua finalidade geral quanto em 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 que você declara 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 interno de objetos para o Tempo de Execução do Windows. Esse é um conjunto fixo de objetos, e o acesso a esses objetos do XAML usa o mapeamento de tipo interno e a 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 definições de código do usuário.

As informações do tipo de suporte estão associadas a definições de namespace XAML específicas. Estruturas XAML, como o Tempo de Execução do Windows, podem agregar vários assemblies e vários namespaces de código para mapear para um único namespace XAML. Isso permite 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 maior parte do XAML documentado 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 pesquisar tipos e membros dos assemblies de suporte associados a esse namespace XAML ao criar 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 UWP.

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 Balloon 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 a parte do 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"

Esse é o mesmo identificador de namespace XAML usado em várias tecnologias predecessoras 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 usando 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 predecessoras da Microsoft que usam XAML.

A relação entre essas declarações é que o 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 em que 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 dos 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 em C++, C# ou Visual Basic. 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 em uma página XAML como um recurso com chave em um ResourceDictionary e referências de recurso XAML, deve ter o atributo x:Key definido no elemento de objeto em questão.

Namespaces de código que são mapeados para o namespace XAML padrão

Veja a seguir uma lista de namespaces de código que estão mapeados atualmente 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 de 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 designer nas superfícies de design XAML do Microsoft Visual Studio. O namespace XAML "d:" habilita atributos de designer ou tempo de design em elementos XAML. Esses atributos de designer afetam apenas os aspectos de design de como o XAML se comporta. Os atributos do designer são ignorados quando o mesmo XAML é carregado pelo analisador XAML do Tempo de Execução do Windows 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 a aplicação de um atributo de designer por conta própria é apropriada. 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 associaçã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 é 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. Talvez você queira remover os atributos nesse caso. Outros recursos dos designers XAML, como o simulador, provavelmente são mais úteis para criar layouts de página que lidam bem com o dimensionamento e os estados de exibição do que um layout de página de tamanho fixo usando d:DesignHeight e d:DesignWidth.

  • Atributo d:DataContext: você pode definir esse atributo em uma raiz de página ou em um controle para substituir qualquer DataContext explícito ou herdado que o objeto tenha de outra forma.
  • d:DesignSource atributo: especifica uma fonte de dados de 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 documentaremos totalmente como usar recursos de dados em tempo de design aqui. Para obter mais informações, consulte Atributos de tempo de design. Para obter 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 dá suporte a 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 de tempo de execução ignorem os atributos de design em "d:".

local: e comum:

"local:" é um prefixo que geralmente é mapeado para você nas páginas XAML para um projeto de aplicativo UWP de modelo. 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 as 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ário, como conversores e comandos, e você pode encontrar as definições na pasta Comum no modo de exibição Gerenciador de Soluções.

VSM:

Não use. "vsm:" é um prefixo que às vezes é visto em modelos XAML mais antigos importados de outras tecnologias da Microsoft. O namespace originalmente abordou um problema de ferramentas de namespace herdado. Você deve excluir as definições de namespace XAML para "vsm:" em qualquer XAML usado para o Tempo de Execução do Windows e alterar todos os usos de prefixo para VisualState, VisualStateGroup e objetos relacionados para usar o namespace XAML padrão. Para obter mais informações sobre a migração XAML, consulte Migrando o código XAML do Silverlight ou do 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 que possa 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 a ele 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 de xmlns inclui um valor, bem como a nomenclatura do prefixo. O valor é uma cadeia de caracteres que fica entre aspas, seguindo um sinal 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 XAML da linguagem XAML, bem como para alguns namespaces XAML menos usados que são usados pelo XAML do Windows Runtime. 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 da interface do usuário XAML da sua página. Além disso, muitas das páginas XAML iniciais de projetos gerados pelo Visual Studio para um aplicativo do Tempo de Execução do Windows usando C++, C# ou Visual Basic já mapeiam um prefixo "local:", que faz referência ao namespace padrão especificado pelo projeto e ao namespace usado por definições parciais de classe.

Regras da linguagem CLR

Se você estiver escrevendo seu código de backup em uma linguagem .NET (C# ou Microsoft Visual Basic), poderá 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 a 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á determinadas 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 cadeias de caracteres de namespace aninhadas sucessivas 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 faz 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 dos princípios básicos de implantação e segurança do aplicativo. Declare qualquer assembly que você deseja incluir como uma fonte de definição de código para XAML como um assembly dependente nas configuraçõ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 da definição de aplicativo ou das 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 esse é um caso em que às vezes é necessário, especialmente para uma propriedade anexada personalizada. Para obter mais informações, consulte Propriedades anexadas personalizadas.