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

InfoPathFormato propietario

Salida SilverlightWindows 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íaNecesidad de diseñar controlesVersion actual ALPHA 1.1Version 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 procesoConexió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

InputParser

MetaDataContainer

FormCreator

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: <nombre_formulario>.xaml ( diseño ) <nombre_formulario>.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

17

283131

23

3135

4 4

Menor Marginal

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