Limitaciones en la serialización de XamlWriter.Save
Actualización: noviembre 2007
El método API Save se puede utilizar para serializar el contenido de una aplicación de Windows Presentation Foundation (WPF) como un archivo Lenguaje de marcado de aplicaciones extensible (XAML). Sin embargo, existen algunas limitaciones notables relativas a qué se serializa exactamente. En este tema se documentan estas limitaciones y algunas consideraciones generales.
Este tema contiene las secciones siguientes.
- Representación en tiempo de ejecución, no en tiempo de diseño
- Autonomía de la serialización
- Eliminación de las referencias a extensiones
- No se conserva el control de eventos
- Escenarios realistas para el uso de XAMLWriter.Save
Representación en tiempo de ejecución, no en tiempo de diseño
La filosofía básica de lo que se serializada mediante una llamada a Save es que el resultado será una representación del objeto serializado en tiempo de ejecución. Muchas propiedades en tiempo de diseño del archivo XAML original pueden haberse optimizado o perdido para cuando el marcado XAML se carga como objetos en memoria, y no se conservan cuando se llama a Save para realizar la serialización. El resultado serializado es una representación efectiva del árbol lógico construido de la aplicación, pero no necesariamente del XAML original que lo generó. Estos problemas hace que sea sumamente difícil utilizar la serialización de Save como parte de una superficie de diseño XAML extensa.
Autonomía de la serialización
El resultado serializado de Save es autónomo; todo lo que se serializa está contenido dentro de una sola página XAML, con un elemento raíz único, sin referencia externa alguna a excepción de los URIs. Por ejemplo, si en la página se hace referencia a recursos de los recursos de la aplicación, éstos aparecerán como si se tratara de un componente de la página serializada.
Eliminación de las referencias a extensiones
El proceso de serialización eliminará las referencias comunes a los objetos realizadas por diversos formatos de extensión de marcado, tales como StaticResource o Binding. Estas referencias ya se han eliminado al crear los objetos en memoria en el tiempo de ejecución de la aplicación, y la lógica de Save no repite el XAML original para restaurar estas referencias en el resultado serializado. Este hecho inmoviliza potencialmente todos los valores obtenidos de los recursos o enlazados a datos en el último valor utilizado por la representación en tiempo de ejecución, y únicamente se dispone de una capacidad limitada o indirecta para distinguir este valor de cualquier otro establecido localmente. Las imágenes también se serializan como referencias a objeto a las imágenes tal cual existen en el proyecto, en lugar de cómo referencias originales del código fuente, con lo que se pierden los nombre de archivo y los URI a los que se hiciera referencia originalmente. Incluso los recursos declarados dentro de la propia página aparecen serializados en el punto donde se hizo referencia a ellos, en lugar de conservarse como una clave de una colección de recursos.
No se conserva el control de eventos
Cuando se serializan controladores de eventos que se agregan mediante XAML, éstos no se conservan. El marcado XAML sin código subyacente (y sin el mecanismo relacionado x:Code) no dispone de ninguna manera de serializar la lógica de procedimiento en tiempo de ejecución. Dado que la serialización es autónoma y se limita al árbol lógico, no existe ningún medio para almacenar controladores de eventos. Como resultado, los atributos de controladores de eventos, tanto el propio atributo como el valor de cadena que da nombre al controlador, se quitan del XAML de salida.
Escenarios realistas para el uso de XAMLWriter.Save
Aunque las limitaciones que hemos enumerado son bastante importantes, existen varios escenarios en los que es adecuado utilizar Save para la serialización.
Salida vectorial o gráfica: la salida del área representada se puede utilizar para reproducir el mismo vector o gráfico al volver a cargarla.
Documentos de texto enriquecido y dinámicos: el texto, el formato de todos los elementos y la contención de elementos en su seno se conservan en la salida. Esto puede ser útil para los mecanismos afines a la funcionalidad del portapapeles.
Conservar datos de objetos comerciales: si ha almacenado datos en elementos personalizados, tales como datos XML, los objetos comerciales se pueden perpetuar mediante la serialización siempre que sigan determinadas reglas básicas de XAML, como proporcionar constructores personalizados y conversión para valores de propiedades por referencia.