Arquitectura de modelo de edición

Artículo
10/07/2008

Actualización: noviembre 2007

La implementación en tiempo de diseño interactúa con los controles en tiempo de ejecución mediante una interfaz de programación denominada modelo de edición. Los objetos que se diseñan se denominan objetos modificables. En este tema se describen la arquitectura y uso del modelo de edición en Windows Presentation Foundation (WPF) Designer for Visual Studio.

Los controles se definen en Lenguaje de marcado de aplicaciones extensible (XAML). El XAML para los controles se actualiza mediante programación con el modelo de edición.

Modelo, contenedor y vista

El modelo de edición está compuesto por tres subunidades funcionales: un modelo, un contenedor público que abstrae el modelo y una vista que representa la interfaz de usuario del modelo. El modelo y la vista son independientes, pero el contenedor y el modelo están estrechamente relacionados. En la siguiente ilustración se muestra la relación entre las tres subunidades.

El entorno de diseño utiliza el tipo ModelItem para comunicarse con el modelo subyacente. Todos los cambios se realizan en los contenedores ModelItem, que afectan al modelo subyacente. Esto permite que el modelo sea simple. Los contenedores ModelItem administran las características complejas del diseñador, tales como la compatibilidad de transacciones, el seguimiento de las acciones de deshacer y las notificaciones de cambios.

Creación de instancias

Todas las características del diseñador que requieren la creación de nuevos objetos en la superficie de diseño utilizan la clase ModelFactory. Cada objeto del diseñador está contenido en una instancia de ModelItem. ModelFactory crea los elementos del modelo.

En el código siguiente se muestra una llamada ModelFactory típica.

ModelItem newButton = ModelFactory.CreateItem(_context, typeof(Button));

El método CreateItem siempre devuelve un tipo de datos de ModelItem. Éste es el tipo base para todos los elementos del modelo de edición de WPF Designer y representa una instancia del contenedor del tipo pasada al método CreateItem. El método CreateItem también requiere una instancia de un contexto de edición de WPF Designer (_context en el ejemplo de código anterior), que se utiliza para buscar otros servicios y dependencias en el diseñador.

La creación explícita de elementos a través del generador sólo es importante para los objetos que se van a colocar en la superficie de diseño que pueden tener inicializadores predeterminados. Este procedimiento no es necesario cuando simplemente esté estableciendo propiedades en valores.

Opciones de creación

En ocasiones tendrá que personalizar el comportamiento de la creación de objetos. Por ejemplo, un componente de conexión de base de datos puede elegir no consultar la base de datos en tiempo de diseño. Es posible que desee tener control sobre la creación de instancias la primera vez que se crea un componente.

En este caso, se arrastra un componente desde el Cuadro de herramientas o se pega desde el Portapapeles. Es posible que desee configurar previamente el componente con valores predeterminados utilizables. Estos valores predeterminados, si no se han modificado, se serializan en el XAML.

Puede pasar un conjunto opcional de marcadores al método CreateItem utilizando la enumeración CreateOptions. En la tabla siguiente se muestran los valores para esta enumeración y su uso.

Herramientas como la herramienta de creación utilizan el marcador InitializeDefaults para inicializar un conjunto de valores de propiedad preconfigurados. Por ejemplo, un objeto ContentControl puede proporcionar algún contenido predeterminado. Esto no sustituye a los valores predeterminados de propiedades especificados correctamente en el código de control en tiempo de ejecución.

Los valores establecidos con este marcador se mantienen en el XAML.

Este marcador no se debe utilizar en el código de análisis puesto que puede ser que el usuario haya quitado los valores predeterminados durante la modificación del objeto en el diseñador.

El método CreateItem enruta la llamada a CreateItem. Este método realiza varios pasos, que se describen en el siguiente diagrama de flujo.

Cambiar el elemento primario de un elemento a un nuevo contenedor

Además de crear nuevos elementos, otra tarea común del diseñador es cambiar el elemento primario de un elemento a otro. Esto se administra a través de una clase estática denominada ModelParent, que proporciona características comunes a la mayoría de los requisitos de relación jerárquica.

Buscar un objeto primario válido a partir de un desplazamiento de coordenadas o de un elemento inicial en la jerarquía en la que se va a buscar.
Decidir si un objeto determinado puede ser un elemento primario de un tipo determinado.
Cambiar el elemento primario de un objeto a otro. Este cambio también quita el elemento primario anterior del objeto. Esta eliminación ofrece al elemento primario anterior la oportunidad de limpiar cualquier dato que pueda residir en el elemento, por ejemplo, propiedades adjuntas.

La clase ModelParent funciona buscando una clase ParentAdapter para los objetos primarios actuales y propuestos. Si no existe ninguna clase ParentAdapter, un objeto no puede estar asignado a un elemento primario. La clase ParentAdapter define varias invalidaciones para casos comunes. Por ejemplo, muchas invalidaciones aceptan un objeto GestureData como parámetro. Este tipo de datos está disponible desde el mecanismo de comandos de WPF Designer cuando el código está administrando un comando de usuario. Proporciona información contextual común.

ParentAdapter permite a los contenedores realizar la eliminación inteligente de elementos primarios. Por ejemplo, si un objeto con un elemento primario del control Canvas se cambia a un elemento primario del control Grid, las propiedades adjuntas de control Canvas en el objeto se pueden quitar automáticamente.