Espacios de nombres XAML y asignación de espacios de nombres
En este tema se explican las asignaciones del espacio de nombres XML/XAML (xmlns), tal como se encuentra en el elemento raíz de la mayoría de los archivos XAML. También se describe cómo generar asignaciones similares para los tipos y ensamblados personalizados.
Cómo se relacionan los espacios de nombres XAML con las bibliotecas de tipos y definición de código
Tanto en su propósito general como para su aplicación en la programación de aplicaciones de Windows Runtime, XAML se usa para declarar objetos, propiedades de esos objetos y relaciones de propiedad de objeto expresadas como jerarquías. Los objetos que declaras en XAML están respaldados por bibliotecas de tipos u otras representaciones definidas por otras técnicas de programación y lenguajes. Estas bibliotecas pueden ser:
- Conjunto integrado de objetos para Windows Runtime. Se trata de un conjunto fijo de objetos y el acceso a estos objetos desde XAML usa la lógica interna de asignación de tipos y activación.
- Bibliotecas distribuidas proporcionadas por Microsoft o por terceros.
- Bibliotecas que representan la definición de un control de terceros que la aplicación incorpora y el paquete redistribuye.
- Su propia biblioteca, que forma parte del proyecto y que contiene algunas o todas las definiciones de código de usuario.
La información de tipo de respaldo está asociada a definiciones de espacio de nombres XAML concretas. Los marcos XAML, como Windows Runtime, pueden agregar varios ensamblados y varios espacios de nombres de código para asignarlos a un único espacio de nombres XAML. Esto permite el concepto de vocabulario XAML que cubre un marco de programación o tecnología más grande. Un vocabulario XAML puede ser bastante extenso; por ejemplo, la mayoría de los XAML documentados para las aplicaciones de Windows Runtime en esta referencia constituyen un único vocabulario XAML. Un vocabulario XAML también es extensible: lo amplía agregando tipos a las definiciones de código de respaldo, asegurándose de incluir los tipos en los espacios de nombres de código que ya se usan como orígenes de espacios de nombres asignados para el vocabulario XAML.
Un procesador XAML puede buscar tipos y miembros de los ensamblados de respaldo asociados a ese espacio de nombres XAML cuando crea una representación de objeto en tiempo de ejecución. Este es el motivo por el que XAML es útil como una manera de formalizar e intercambiar definiciones de comportamiento de construcción de objetos, y por qué XAML se usa como técnica de definición de interfaz de usuario para una aplicación para UWP.
Espacios de nombres XAML en uso típico de marcado XAML
Un archivo XAML casi siempre declara un espacio de nombres XAML predeterminado en su elemento raíz. El espacio de nombres XAML predeterminado define qué elementos puedes declarar sin calificarlos por un prefijo. Por ejemplo, si declaras un elemento <Balloon />, un analizador XAML esperará que exista un elemento Balloon y sea válido en el espacio de nombres XAML predeterminado. Por el contrario, si Globo no está en el espacio de nombres XAML predeterminado definido, debe calificar ese nombre de elemento con un prefijo, por ejemplo <party:Balloon />. El prefijo indica que el elemento existe en un espacio de nombres XAML diferente que el espacio de nombres predeterminado y debes asignar un espacio de nombres XAML al prefijo para poder usar este elemento. Los espacios de nombres XAML se aplican al elemento específico en el que se declaran y también a cualquier elemento contenido por ese elemento en la estructura XAML. Por este motivo, los espacios de nombres XAML casi siempre se declaran en elementos raíz de un archivo XAML para aprovechar esta herencia.
Declaraciones de espacio de nombres XAML de lenguaje XAML y predeterminadas
Dentro del elemento raíz de la mayoría de los archivos XAML, hay dos declaraciones xmlns . La primera declaración asigna un espacio de nombres XAML como valor predeterminado: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
Este es el mismo identificador de espacio de nombres XAML que se usa en varias tecnologías de Microsoft predecesoras que también usan XAML como formato de marcado de definición de interfaz de usuario. El uso del mismo identificador es deliberado y resulta útil al migrar la interfaz de usuario definida previamente a una aplicación de Windows Runtime mediante C++, C# o Visual Basic.
La segunda declaración asigna un espacio de nombres XAML independiente para los elementos de lenguaje definidos por XAML, asignándolo (normalmente) al prefijo "x:": xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Este valor xmlns y el prefijo "x:" al que se asigna también es idéntico a las definiciones usadas en varias tecnologías predecesoras de Microsoft que usan XAML.
La relación entre estas declaraciones es que XAML es una definición de lenguaje y Windows Runtime es una implementación que usa XAML como lenguaje y define un vocabulario específico en el que se hace referencia a sus tipos en XAML.
El lenguaje XAML especifica determinados elementos de lenguaje y cada uno de ellos debe ser accesible a través de implementaciones de procesador XAML que funcionan con el espacio de nombres XAML. La convención de asignación "x:" para el espacio de nombres XAML del lenguaje XAML va seguida de plantillas de proyecto, código de ejemplo y documentación para las características del lenguaje. El espacio de nombres del lenguaje XAML define varias características usadas habitualmente que son necesarias incluso para aplicaciones básicas de Windows Runtime con C++, C#o Visual Basic. Por ejemplo, para unir cualquier código subyacente a un archivo XAML a través de una clase parcial, debes asignar un nombre a esa clase como atributo x:Class en el elemento raíz del archivo XAML correspondiente. O bien, cualquier elemento tal como se define en una página XAML como un recurso con claves en una referencia de recursos ResourceDictionary y XAML debe tener el atributo x:Key establecido en el elemento de objeto en cuestión.
Espacios de nombres de código que se asignan al espacio de nombres XAML predeterminado
A continuación se muestra una lista de espacios de nombres de código que se asignan actualmente al espacio de nombres XAML predeterminado.
- 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
Otros espacios de nombres XAML
Además del espacio de nombres predeterminado y el espacio de nombres XAML del lenguaje XAML "x:", también puedes ver otros espacios de nombres XAML asignados en el XAML predeterminado inicial para las aplicaciones según lo generado por Microsoft Visual Studio.
d: (http://schemas.microsoft.com/expression/blend/2008)
El espacio de nombres XAML "d:" está diseñado para la compatibilidad del diseñador, específicamente la compatibilidad con el diseñador en las superficies de diseño XAML de Microsoft Visual Studio. El espacio de nombres XAML" d:" permite atributos de diseñador o tiempo de diseño en elementos XAML. Estos atributos de diseñador afectan solo a los aspectos de diseño de cómo se comporta XAML. Los atributos del diseñador se omiten cuando el analizador XAML de Windows Runtime carga el mismo XAML cuando se ejecuta una aplicación. Por lo general, los atributos del diseñador son válidos en cualquier elemento XAML, pero en la práctica solo hay determinados escenarios en los que aplicar un atributo de diseñador es adecuado. En concreto, muchos de los atributos del diseñador están diseñados para proporcionar una mejor experiencia para interactuar con contextos de datos y orígenes de datos mientras desarrollas XAML y código que usan el enlace de datos.
- atributos d:DesignHeight y d:DesignWidth: estos atributos se aplican a veces a la raíz de un archivo XAML que visual Studio u otra superficie del diseñador XAML crea automáticamente. Por ejemplo, estos atributos se establecen en la raíz UserControl del XAML que se crea si agregas un nuevo UserControl al proyecto de la aplicación. Estos atributos facilitan el diseño de la composición del contenido XAML, de modo que tengas cierta anticipación de las restricciones de diseño que pueden existir una vez que se usa el contenido XAML para una instancia de control u otra parte de una página de interfaz de usuario más grande.
Nota Si vas a migrar XAML desde Microsoft Silverlight, es posible que tengas estos atributos en los elementos raíz que representan una página completa de la interfaz de usuario. Es posible que quiera quitar los atributos en este caso. Es probable que otras características de los diseñadores XAML, como el simulador, sean más útiles para diseñar diseños de página que controle bien el escalado y los estados de vista que es un diseño de página de tamaño fijo mediante d:DesignHeight y d:DesignWidth.
- Atributo d:DataContext: puede establecer este atributo en una raíz de página o en un control para invalidar cualquier dataContext explícito o heredado que tenga el objeto de otro modo.
- Atributo d:DesignSource: especifica un origen de datos en tiempo de diseño para un CollectionViewSource, reemplazando source.
- extensiones de marcado d:DesignInstance y d:DesignData: estas extensiones de marcado se usan para proporcionar los recursos de datos en tiempo de diseño para d:DataContext o d:DesignSource. Aquí no documentaremos completamente cómo usar recursos de datos en tiempo de diseño. Para obtener más información, consulta Atributos en tiempo de diseño. Para obtener algunos ejemplos de uso, consulte Datos de ejemplo en la superficie de diseño y para la creación de prototipos.
mc: (http://schemas.openxmlformats.org/markup-compatibility/2006)
" mc:" indica y admite un modo de compatibilidad de marcado para leer XAML. Normalmente, el prefijo "d:" está asociado al atributo mc:Ignoreable. Esta técnica permite que los analizadores XAML en tiempo de ejecución omitan los atributos de diseño en "d:".
local: y común:
"local:" es un prefijo que se asigna a menudo dentro de las páginas XAML para un proyecto de aplicación para UWP con plantilla. Se asigna para hacer referencia al mismo espacio de nombres que se crea para contener el atributo x:Class y el código de todos los archivos XAML, incluidos app.xaml. Siempre que definas cualquier clase personalizada que quieras usar en XAML en este mismo espacio de nombres, puedes usar el prefijo local: para hacer referencia a los tipos personalizados en XAML. Un prefijo relacionado que procede de un proyecto de aplicación para UWP con plantilla es común:. Este prefijo hace referencia a un espacio de nombres "Común" anidado que contiene clases de utilidad como convertidores y comandos, y puede encontrar las definiciones en la carpeta Common en la vista Explorador de soluciones.
vsm:
No utilice. "vsm:" es un prefijo que a veces se ve en plantillas XAML anteriores importadas de otras tecnologías de Microsoft. El espacio de nombres ha solucionado originalmente un problema de herramientas de espacio de nombres heredado. Debes eliminar definiciones de espacio de nombres XAML para "vsm:" en cualquier XAML que uses para Windows Runtime y cambiar los usos de prefijos para VisualState, VisualStateGroup y objetos relacionados para usar el espacio de nombres XAML predeterminado en su lugar. Para obtener más información sobre la migración de XAML, consulta Migración de XAML/código de Silverlight o WPF a una aplicación de Windows Runtime.
Asignación de tipos personalizados a espacios de nombres y prefijos XAML
Puedes asignar un espacio de nombres XAML para que puedas usar XAML para acceder a tus propios tipos personalizados. En otras palabras, se asigna un espacio de nombres de código tal como existe en una representación de código que define el tipo personalizado y se le asigna un espacio de nombres XAML junto con un prefijo para su uso. Los tipos personalizados para XAML se pueden definir en un lenguaje Microsoft .NET (C# o Microsoft Visual Basic) o en C++. La asignación se realiza definiendo un prefijo xmlns . Por ejemplo, xmlns:myTypes define un nuevo espacio de nombres XAML al que se accede mediante el prefijo de todos los usos con el token myTypes:.
Una definición xmlns incluye un valor, así como la nomenclatura del prefijo. El valor es una cadena que va entre comillas, después de un signo igual. Una convención XML común consiste en asociar el espacio de nombres XML con un identificador uniforme de recursos (URI), de modo que exista una convención para la unicidad y la identificación. También ves esta convención para el espacio de nombres XAML predeterminado y el espacio de nombres XAML del lenguaje XAML, así como para algunos espacios de nombres XAML menos usados que usa Windows Runtime XAML. Pero para un espacio de nombres XAML que asigna tipos personalizados, en lugar de especificar un URI, comienza la definición de prefijo con el token "using:". Después del token "using:", se asigna el nombre al espacio de nombres de código.
Por ejemplo, para asignar un prefijo "custom1" que te permite hacer referencia a un espacio de nombres "CustomClasses" y usar clases de ese espacio de nombres o ensamblado como elementos de objeto en XAML, la página XAML debe incluir la siguiente asignación en el elemento raíz: xmlns:custom1="using:CustomClasses"
No es necesario asignar clases parciales del mismo ámbito de página. Por ejemplo, no necesita prefijos para hacer referencia a ningún controlador de eventos que haya definido para controlar eventos desde la definición de la interfaz de usuario XAML de la página. Además, muchas de las páginas XAML iniciales de los proyectos generados por Visual Studio para una aplicación de Windows Runtime mediante C++, C# o Visual Basic ya asignan un prefijo "local:", que hace referencia al espacio de nombres predeterminado especificado por el proyecto y el espacio de nombres usado por definiciones de clase parciales.
Reglas del lenguaje CLR
Si va a escribir el código de respaldo en un lenguaje .NET (C# o Microsoft Visual Basic), es posible que esté usando convenciones que usen un punto (".") como parte de los nombres de espacio de nombres para crear una jerarquía conceptual de espacios de nombres de código. Si la definición del espacio de nombres contiene un punto, el punto debe formar parte del valor que especifique después del token "using:".
Si el archivo de código subyacente o el archivo de definición de código es un archivo de C++, hay ciertas convenciones que siguen el formato del lenguaje Common Language Runtime (CLR), por lo que no hay ninguna diferencia en la sintaxis XAML. Si declara espacios de nombres anidados en C++, el separador entre las cadenas de espacio de nombres anidadas sucesivas debe ser "." en lugar de "::" al especificar el valor que sigue al token "using:".
No uses tipos anidados (como anidar una enumeración dentro de una clase) cuando definas el código para usarlo con XAML. No se pueden evaluar los tipos anidados. No hay forma de que el analizador XAML distinga que un punto forma parte del nombre de tipo anidado en lugar de formar parte del nombre del espacio de nombres.
Tipos y ensamblados personalizados
El nombre del ensamblado que define los tipos de respaldo de un espacio de nombres XAML no se especifica en la asignación. La lógica para la que los ensamblados están disponibles se controla en el nivel de definición de la aplicación y forma parte de los principios básicos de implementación y seguridad de la aplicación. Declare cualquier ensamblado que quiera incluir como origen de definición de código para XAML como un ensamblado dependiente en la configuración del proyecto. Para obtener más información, consulta Crear componentes de Windows Runtime en C# y Visual Basic.
Si hace referencia a tipos personalizados desde la definición de aplicación o las definiciones de página de la aplicación principal, esos tipos están disponibles sin una configuración de ensamblado dependiente adicional, pero todavía debe asignar el espacio de nombres de código que contiene esos tipos. Una convención común consiste en asignar el prefijo "local" para el espacio de nombres de código predeterminado de cualquier página XAML determinada. Esta convención suele incluirse en el inicio de plantillas de proyecto para proyectos XAML.
Propiedades adjuntas
Si haces referencia a propiedades adjuntas, la parte del tipo de propietario del nombre de propiedad adjunta debe estar en el espacio de nombres XAML predeterminado o tener el prefijo. Es raro prefijar atributos por separado de sus elementos, pero este es un caso en el que a veces es necesario, especialmente para una propiedad adjunta personalizada. Para obtener más información, consulta Propiedades adjuntas personalizadas.