Compartilhar via

Namespaces XAML e mapeamento de namespace

Este tópico explica os mapeamentos XML/XAML namespace (xmlns), conforme encontrado 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ção de código

Tanto em sua finalidade geral quanto em seu aplicativo para a programação de aplicativos do Windows Runtime, o XAML é usado para declarar objetos, propriedades desses objetos e relações de propriedade de objeto 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:

  • Conjunto de objetos interno para o Windows Runtime. Esse é um conjunto fixo de objetos e acessar esses objetos a partir do XAML usa a lógica interna de mapeamento de tipos e 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 de tipo de backup estão associadas a definições de namespace XAML específicas. Estruturas XAML, como o Windows Runtime, 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 maioria dos XAML documentados para aplicativos do Windows Runtime nessa referência constitui um único vocabulário XAML. Um vocabulário XAML também é extensível: estenda-o adicionando tipos às definições de código de backup, 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 localizar tipos e membros dos assemblies subjacentes 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 do Windows Runtime.

Uso típico de namespaces XAML na 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 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 para a linguagem padrão e XAML

Dentro do elemento raiz da maioria dos arquivos XAML, há duas declarações xmlns . A primeira declaração mapeia um namespace XAML como o 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 Windows Runtime 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 XAML é uma definição de linguagem, e o Windows Runtime é uma implementação que usa XAML como 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 estar acessível por meio de implementações de processador XAML que funcionam 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 documentação para recursos de linguagem. O namespace de linguagem XAML define vários recursos comumente usados que são necessários até mesmo para aplicativos básicos do Windows Runtime. 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 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 associados ao namespace XAML padrão

Veja a seguir uma lista de namespaces de código mapeados no momento 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 suporte ao designer nas superfícies de design XAML do Microsoft Visual Studio. O namespace XAML " d:" permite 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 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 certos cenários em que a aplicação de um atributo de designer por conta própria é apropriada. Em particular, muitos dos atributos de 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 do 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, de modo que você tenha alguma antecipação das restrições de layout que podem existir uma vez que o conteúdo XAML seja usado para uma instância de controle ou outra parte de uma página de interface do usuário maior.

    Nota Se você estiver migrando o 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 estados de dimensionamento e 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 na raiz da página ou em um controle para substituir qualquer DataContext explícito ou herdado que o objeto de outra forma teria.

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

  • d:DesignInstance e d:DesignData markup extensions: 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 projeto aqui. Para obter mais informações, consulte Design-Time Atributos. Para obter alguns exemplos de uso, consulte Dados de exemplo na superfície de design e para protótipos.

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

" mc:" indica e dá suporte a um modo de compatibilidade de marcação para ler 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 comum:

"local:" é um prefixo que geralmente é mapeado para você dentro das páginas XAML para um projeto de aplicativo UWP com modelo padrão. 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 no XAML nesse mesmo namespace, você pode usar o prefixo local: para se referir aos seus tipos personalizados em XAML. Um prefixo relacionado proveniente 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 usar. "vsm:" é um prefixo que às vezes é visto em modelos XAML mais antigos importados de outras tecnologias da Microsoft. O namespace foi originalmente criado para resolver um problema relacionado a ferramentas de namespace legadas. Você deve excluir definições de namespace XAML para "vsm:" em qualquer XAML que você use para o Windows Runtime e, em vez disso, modificar o uso de prefixos para VisualState, VisualStateGroup e objetos relacionados para usarem o namespace XAML padrão. Para obter mais informações sobre a migração XAML, consulte Migrando o Silverlight ou o XAML/código do WPF para um aplicativo do Windows Runtime.

Mapeamento de 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-lhe um namespace XAML junto com um prefixo para uso. 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 de 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), de modo 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:", defina o namespace do seu 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 no 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 referenciar os manipuladores de eventos definidos para lidar com eventos da definição da interface do usuário XAML da página. Além disso, muitas das páginas XAML iniciais de projetos gerados pelo Visual Studio para um aplicativo do 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 parciais de classe.

Regras de 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 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), de modo 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 utilize tipos aninhados (como a colocação de uma enumeração dentro de uma classe) ao definir seu código para uso com XAML. 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 e não do nome do namespace.

Tipos e assemblies personalizados

O nome do assembly que define os tipos de backup 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 Windows Runtime em C# e Visual Basic.

Se você estiver fazendo referência a tipos personalizados nas definições do aplicativo primário ou nas definições de página, esses tipos estarão disponíveis sem necessidade de configuração adicional de assembleia dependente, mas você ainda precisa mapear o namespace do 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 fornecida. Essa convenção geralmente é incluída nos modelos de projeto iniciais 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.

  • Last updated on