PIS 2007 – GRUPO 03

2 Introducción a MoGeFI MoGeFI Motivación. Transformar formularios definidos en un formato específico a otras tecnologías explotando el potencial visual que cada una tenga.

3 Introducción a MoGeFI Potencialidad del sistema.  Diseñar de forma sencilla un formulario una única vez y portarlo a las tecnologías que se necesite.  Evitar programación repetitiva necesaria en la mayoría de los formularios.  Personas sin conocimientos de programación pueden cooperar en el desarrollo de los sistemas de información. Ej: Contadores en aplicaciones bancarias.

4 Requisitos Principales(I) Entrada  InfoPath  Formato propietario Salida  Silverlight  Windows Presentation Foundation  Ajax + HTML  La tecnología de salida debe seleccionable y el sistema debe ser extensible a nuevas tecnologías.  Aspecto visual independiente del comportamiento del formulario.

5 Requisitos Principales(II)  Controles Browser Enable.  Funciones, validaciones, reglas.  Manejo de conexión de datos, principalmente web service con soporte para envio y recepción de datos.

6 Formato de Salida (I) SilverLight Centrar el Desarrollo en un formato de salida sin dejar de lado futuras extensiones.  Primera aproximación  Interés por parte del cliente  Dificultades :  Poca madurez de la tecnología  Necesidad de diseñar controles  Version actual ALPHA 1.1  Version anterior 1.0 sin C#

7  Formato seleccionado para el producto.  Caracteristicas : Madurez. Diseño y Comportamiento independientes. Librerias existentes. Gran cantidad de documentación disponible. Herramienta visual para el desarrollo (Blend 2). Windows Presentation Foundation Formato de Salida (II)

8 Propuesta de Alcance Controles : TextBox. CheckBox. Button. DropDownList Box. Date Picker. Section. Repeating Table. Layouts : Table y Table with Title Otros : Texto fuera de controles. Image. Validaciones, funciones, reglas. Log del proceso Conexión con webservice Estilos visuales.

9 Alcance COMPLETAMENTE implementado. Alcance Logrado EXTRAS :  Agregar Estilos.  Previsualización del Estilo seleccionado.  Acciones de Reglas :  Mostrar Mensaje (PopUp).

10 Proceso de Generación ProcessController InputParserMetaDataContainerFormCreator Se parsea el formulario infopath Se almacena en MetaDataContainer la información del formulario previamente parseado Se invoca a FormCreator para que genere el formulario a partir de lo almacenado MetaData Se obtiene la información del formulario. Se genera el formulario en WPF

11 Arquitectura (I) Parseo (InputParser) independiente de la generación de código (FormCreator)

12 Extensibilidad de FormCreator Arquitectura (II) Soporte para nuevas tecnologías.

13 FormCreator Solución WPF Crean 2 archivos:.xaml ( diseño ).cs ( codeBehind ) Code Behind utiliza Subsistema WPFBehaviorCore Se copia el archivo: *.xaml ( Resource Dictionary – Estilo visual) Arquitectura (III)

14 WPFBehaviorCore Debe ser incluido en el proyecto que use al formulario generado. No es generado cada vez que se genera un formulario con MoGeFi. Rige el comportamiento del formulario en tiempo de ejecución. Ejecuta funciones, reglas, validaciones, etc. Simplifica el código generado por FormCreator dejándole únicamente la responsabilidad de inicializar los componentes del formulario. Solución WPF

15 Estilos(I) Los formularios generados pueden tener un estilo aplicado para enriquecer visualmente la experiencia del usuario que lo utilice. El estilo es independiente del formulario InfoPath, por lo tanto para cambiarlo basta con generar el formulario nuevamente con MoGeFI con el estilo deseado. El sistema provee la capacidad de agregar estilos a futuro desde la interfaz gráfica. Permite que un diseñador pueda generar un estilo para los formularios sin preocuparse por el comportamiento pues ya está realizado en WPFBehaviorCore

16 Estilos(II) Ejemplos de formularios generados con los estilos disponibles: Sin Estilo G03Style RedBallStyle

MenorMarginal Verificación (I)  Ningún error grave encontrado quedó sin corregir.  Aplicación cumple con los estándares de correctitud definidos.

18 Incidencias Importantes Las repeating tables sólo soportan controles básicos en su interior, y no estructuras como tablas u otras repeating tables. No se puede cambiar el tipo de control a partir del origen de datos Los campos checkbox sólo soportan valores TRUE/FALSE Soporte para internacionalización limitado a regiones con comas como separadores de dígitos decimales Verificación (II)

19 Evaluación del Producto (I)  Fortalezas: Amplio nivel de funcionalidades soportadas para el formulario generado. Todas las funcionalidades necesarias para que el formulario sea auto contenido fueron implementadas. Facilidad de uso. Extensible en formato de entrada y salida. GUI fácilmente reemplazable: invocar subSistema con los parámetros necesarios. Ejemplo : generación en masa de formularios por consola.

20 Evaluación del Producto (II)  Debilidades y limitaciones: Falta de chequeos en el formulario de entrada: El sistema no puede ser extendido sin recompilar Se debe seguir un formato de comunicación con Web Service No es posible modificar el valor de Date Picker a través de funciones y validaciones  No se prevee comportamiento si el formulario es modificado por fuera de InfoPath  No se chequean ciclos infinitos que permite InfoPath

21 Evaluación del Producto (III)  Mejoras y extensiones: Completar el set de controles de InfoPath Ampliar formato de comunicación con Web Services Previsualización del formulario Ampliar formatos de entrada Ampliar formatos de salida: Silverlight y HTML+AJAX  Posibilidad de elección de tecnología mediante Reflection

22 Demo