Migración Win a Web Cada vez más, el uso masivo de Internet propicia el desarrollo de aplicaciones de mayor versatilidad y complejidad para el ambiente Web. Es por esto que está surgiendo la necesidad de aplicar una reingeniería a las aplicaciones existentes y también, en muchos casos, la necesidad de desarrollar nuevas aplicaciones para Internet. Existen varias diferencias entre los ambientes GUI (aplicaciones con Interfaz de Usuario Gráfica) y Web, las que deberán considerarse en la conversion de la KB. La migración no debería verse como una conversión objeto a objeto sino que normalmente es una modernización de la aplicación usando otras herramientas tales como Patterns, GXportal, GXflow, Reporting, etc.. 295
Aplicaciones GUI: Comparación GUI Web Introducción Compuestas por uno o varios programas GeneXus, utilizando objetos de tipo: Transacción, Work Panel, Procedimientos y Reportes Aplicaciones (Full) Web Las que la interfaz de usuario es únicamente realizada utilizando los siguientes objetos: Web Panels, Transacciones Web, Procedimientos (call protocol: HTTP), ejecutados desde un browser. Aplicaciones con Interfaz de Usuario Gráfica Las aplicaciones con Interfaz de Usuario Grafica (GUI) están compuestas por uno o varios programas GeneXus que utilizan objetos de tipo: Transacción, Work Panel, Procedimientos y Reportes. Aplicaciones Web Se entenderá por aplicaciones Full Web a aquellas aplicaciones en las que la interfaz del usuario es únicamente realizada utilizando el lenguaje HTML y son accedidas desde un browser. En GeneXus estas aplicaciones se implementan con objetos Web como ser: Web Panels,Transacciones Web o Procedimientos (call protocol: HTTP). 296
Comprender: Objetivos Funcionamiento de la interfaz Web Manejo de Integridad Transaccional en Aplicaciones Web Para crear o migrar aplicaciones Web, tener en cuenta: Requerimientos y proceso de instalación de la aplicación final, en uno o más servidores. Diseño gráfico (se puede tercerizar a especialistas) Manejo de las LUW (Unidades de Trabajo Lógica en Transacciones) Otras características que veremos a continuación 297
Work Panels a Web Panels: Tener en cuenta el disparo de Eventos Filtros Comando Refresh Cuando se ejecuta un Web Panel por primera vez, se ejecuta un GET de la página ( ver disparo de eventos en GET). Cuando se ejecuta algún evento de usuario, se vuelven a ejecutar todos los eventos (Start, Refresh, Load), siguiendo un orden establecido (ver disparo de eventos en POST). Si se vuelve desde un Web Panel a otro con return (o se vuelve invocándolo mediante un CALL o link), se ejecutan los eventos del Web Panel llamado siguiendo el orden para el disparo de eventos en el GET explicado anteriormente. Esto tiene como consecuencia lo siguiente: 1.- Filtros ingresados en un Web Panel A se pierdan cuando se llama a otro Web Panel ( B ) y se vuelve hacia A nuevamente, por lo cual, se deben guardar los filtros en la sesión como se explicara más adelante. 2.- Se deriva también de la diferencia en el comportamiento del disparo de eventos, que no es necesario forzar un Refresh del Web Panel A si un cambio en B (llamado por A ) produce un cambio en A, puesto que en la ejecución de A se re-disparan los eventos, incluido el evento Refresh. 3.- Si se tiene un Web Panel en donde mediante un evento de usuario se realiza un cambio en una tabla de la base de datos (llamando a un procedimiento por ejemplo) y dicho Web Panel tiene un grid que navega por la misma tabla, no es necesario hacer grid.refresh o grid.load, puesto que la carga del grid se realiza a causa de la ejecución de los eventos del POST (Start, Refresh, Load). 298
Work Panel Trabajar con. Posibilidad de generarlo automáticamente aplicando el Pattern WorkWith. Procesamiento de varias filas en grid For Each Selected Line Persistencia de Filtros. Work Panel Trabajar Con Es muy común el uso de Web Panels del estilo Trabajar con donde se despliega un grid con registros y una cantidad de opciones aplicables a cada una de las líneas del mismo. Manejo de opciones La primera opción es implementarlo con el Pattern WorkWith. También existen otras alternativas para implementar el Web Panel: 1. Agregar en el grid una variable de tipo Combobox y programar las diferentes acciones en el evento Click de la misma. 2. Definir una imagen o un text block en el grid por cada una de las opciones y programar la acción en el evento click. 3. Si se utiliza un grid Free Style, puede utilizarse en lugar de una imagen con el evento click, un botón para cada una de las opciones. 4. Configurar la propiedad AllowSelection del grid. Para profundizar en el tema de grids, ver Capítulo Grids. Filtros Si un Web Panel Trabajar con tiene variables que se aplican como filtro a los registros desplegados en el grid, al seleccionar un registro y llamar a otro objeto (por ej. Transacción Web) que tiene un Return, se vuelve al Web Panel Trabajar con pero se pierden los valores ingresados en los filtros. Para poder mantener el comportamiento de los Work Panels Trabajar con se deberían utilizar cookies o websessions que almacenen los filtros ingresados. 299
Procesamiento De Varias Filas En Grid - For Each Selected Line En Web Panels, no existe la forma de seleccionar con el mouse varias líneas del grid. Para implementar la selección múltiple, se debe definir una variable en el grid y asignarle un valor a cada una de las líneas que se quieren procesar. Luego, se debe usar el comando For each line para procesar cada una de las líneas y filtrar por las que estén seleccionadas (&valor = X). Debe considerarse que se puede utilizar únicamente para invocar a objetos sin interfaz. Si se invoca a otro Web Panel, solamente se ejecuta para el último registro del grid. Para la selección de una línea se cuenta con la propiedad AllowSelection. Si se realiza una invocación a objetos con interfaz desde un loop, solo se invocará una vez a dicho objeto, y la llamada corresponderá a la última recorrida del loop. Por ejemplo, se desea llamar desde un evento de usuario que recorre un grid a una Transacción para actualizar los elementos del grid: Event Update For each line in CustomerGrid TCustomer.call(CustomerId, UPD ) //Customer es la Transacción de clientes EndFor EndEvent Dicho código no es correcto, porque el comportamiento no es el mismo que para Work Panels, y deberá recodificarse con algunas de las opciones vistas anteriormente para implementar un Work With.
Transacciones: Disparo de reglas y fórmulas. Disparo de Eventos. Integridad Transaccional: Manejo de LUW Hay diferencias en el orden del disparo de eventos (para profundizar en el tema ver Capítulo Transacciones). Las reglas de las Transacciones comprenden reglas de negocio ( el saldo del cliente no puede ser negativo ), y reglas de "flujo" (llamadas a objetos con interfaz). Las reglas de negocio en general no requieren de conversión, mientras que el resto de las reglas (las que implican llamadas a objetos con interfaz) deben convertirse. Integridad Transaccional: Manejo de LUW Una opción es usar Business Components en el form e ir guardando en una session la información hasta que llegue el momento de hacer el commit en el cual se debe levantar la información de la session. La otra opción es usar tablas temporales o actualizaciones lógicas y no físicas. (Ver Capítulo Transacciones para profundizar en el tema). 301
Uso de Tab Dialogs y menús. Master Pages, WebComponents y Estilos Uso De Tab Dialogs En las aplicaciones GUI, se pueden definir tab dialogs para organizar los datos del form en varias secciones. Igualmente, en aplicaciones GUI se puede usar objetos menú y menúbar. En las aplicaciones Web, podemos usar "User Controls" que permiten simular estos tabs, menús y cualquier tipo de control. Master Pages, Webcomponents y Estilos Los styles en Win se usan con dos propósitos: a. Definir un estándar para el form, manteniendo dinamismo (básicamente del Style Area) b. Inicializar los objetos con algunas partes predefinidas (variables, código de eventos, propiedades, etc.). En Web, los styles solo sirven para inicializar los objetos, pero no se mantiene el vínculo luego, por lo cual no hay dinamismo con los cambios realizados en el Style. Con el mismo propósito de los estilos en Win (mantener el dinamismo, primordialmente en cuanto a la lógica de los objetos); en Web se usan Web Components para centralizar en un solo objeto la implementación de una cierta funcionalidad, y reducir el impacto del mantenimiento y de los cambios. Asimismo, se usan las Master Pages para optimizar la reutilización de código y agilizar el mantenimiento. Es decir, en Web no se tendrán N objetos basados en un estilo, sino que se tiende a tener un solo objeto que implementa cierta funcionalidad y es reutilizado en el resto de los objetos. En cuanto al diseño estético de la aplicación puede tercerizarse a especialistas y se recomienda por motivos de performance de la aplicación final, y facilidad de mantenimiento de la misma el uso de la tecnología CSS a través de GeneXus Themes. El uso de los Themes asegura que el diseño estético de la aplicación esté centralizado en un solo objeto. 302
Persistencia de estado Invocación a Objetos GeneXus y parámetros Persistencia de estado: En los Web Panels no hay noción de estado, en el sentido en que luego de ejecutado un evento que asigna valores a variables, debe persistir el valor de esas variables para poder recuperarlas en otro evento. Una de las maneras de hacerlo es teniendo esas variables (hidden) en el form. Si por ejemplo se tiene un evento que usa una variable cargada por otro evento disparado anteriormente (en el mismo Web Panel), la variable tiene que estar en el form y ubicada después del control que la carga. El funcionamiento de esto está basado en el orden de disparo de los eventos. (Ver Capítulo Web Panels, orden de disparo de los eventos). Otra manera de hacerlo es guardando la información en variables de sesión. Invocación a objetos: 1. no se puede llamar a objetos con interfaz dentro de un loop. 2. cuando se vuelve de un objeto invocado se vuelve a ejecutar los eventos (GET) del llamador. 3. no se puede pasar por parámetros a objetos con interfaz (Web Panels, Web Transactions, Procedimientos HTTP): colecciones, SDTs, o arrays. Se debe usar sesiones en caso de querer almacenar dicha información. Por ejemplo, una técnica usada es que luego de almacenar la información en el SDT o collection se usa el método TOXML para pasar dicha información a un string y poder almacenarla en la sesión, y luego FROMXML para hacer el proceso inverso. En Web Panels no hay parámetros de retorno. 303
Interacción con el usuario en Web Objects: Los programas no pueden quedar esperando por una respuesta: Tener en cuenta que el programa está ejecutando en el servidor! Cómo se haría entonces? Un Web Panel que solicite la información. Mediante Javascripts: 304
Reportes Impresión local vs Impresión en el servidor Impresión gráfica: reportes PDF Las posibilidades de impresión dentro de lo que es modo gráfico, son en general, formato PDF o reportes gráficos usando la herramienta ReportViewer. El uso de cualquiera de estas variantes depende de la plataforma y la interfaz usada. En interfaz GUI Windows, es válido el uso del ReportViewer. En interfaz GUI linux no lo es, debido a que la implementación del Report.Viewer está basada en dlls para su funcionamiento. En interfaz Web tampoco es válido el uso de dicha herramienta, porque no es posible ejecutar el ReportViewer dentro del browser (es una aplicación GUI). En plataforma Web, los reportes mayoritariamente usados, son los reportes gráficos en formato PDF, que se despliegan en el browser del cliente, dentro del cual ejecuta el Acrobat Reader. Este tipo de reportes se puede imprimir directamente en la impresora del cliente, sin necesidad de interacción alguna por parte del usuario final. Por más información, referirse a: http://wiki.gxtechnical.com/commwiki/servlet/hwikibypageid?4042 305