OBJETO WEB PANEL 246

Transcripción

1 OBJETO WEB PANEL 246

2 Características Permiten definir consultas interactivas a la base de datos. Son flexibles por lo que se prestan para múltiples usos. Los web panels son objetos GeneXus que permiten al usuario en tiempo de ejecución, realizar interactivamente consultas a la base de datos a través de una pantalla. El término interactivamente se refiere a que el usuario podrá ingresar en la pantalla de un web panel una y otra vez distintos valores de filtros, y consultar a continuación los datos que concuerden con los mismos. Además, sobre los datos consultados, el usuario podrá realizar distintas acciones, como veremos. Los web panels no permiten la actualización de la base de datos, sino sólo su consulta 1. El objetivo primordial de este objeto GeneXus es la definición de consultas interactivas a la base de datos, sin embargo se trata de un objeto muy flexible por lo que se presta para diversos usos. En este capítulo estudiaremos algunos detalles de este tipo de objeto A menos que se utilicen en combinación con los business components (estudiados más adelante) 247

3 Elementos Algunos de ellos son: Web Form Reglas Condiciones Subrutinas Eventos Propiedades Ayuda Documentación Los elementos de los web panels son: Web Form: Cada web panel contiene un form Web, el cual debe ser diseñado por el analista agregándole variables, atributos, así como otros controles, para que el usuario pueda interactuar con el mismo. Reglas: Las reglas de un web panel permiten definir ciertos comportamientos puntuales de dicho objeto. Por ejemplo, declarar qué parámetros recibe, definir qué variables no queremos que sean aceptadas en el form sino utilizadas para desplegar información, etc. Condiciones: Es para definir las condiciones que deben cumplir los datos a ser recuperados (filtros). Subrutinas: Son rutinas locales al web panel. Eventos: Los web panels emplean la programación orientada a eventos. Este tipo de programación permite definir código ocioso, que se activa en respuesta a ciertas acciones provocadas por el usuario o por el sistema. En esta sección de un web panel es donde se define el código ocioso asociado a los eventos que pueden ocurrir durante la ejecución del web panel. Propiedades: Son características a ser configuradas para definir ciertos detalles referentes al comportamiento general del web panel. Ayuda: Permite la inclusión de texto de ayuda, que los usuarios podrán consultar en tiempo de ejecución del web panel. Documentación: Permite la inclusión de texto técnico como documentación para los desarrolladores. 248

4 Clasificación de web panels Web panels de Entrada Web panels de Salida Web panels Mixtos Todo web panel tiene un form asociado, y en el mismo, contrariamente al comportamiento del form de una transacción, los atributos que se incluyan serán de salida, y las variables que se incluyan serán de entrada. Es fácil de comprender que el objetivo del form de un web panel es exactamente el contrario al objetivo del form de una transacción, ya que: a través del form de una transacción se ingresan los valores de los atributos en la base de datos. a través del form de un web panel, se consultan / recuperan los valores de los atributos de la base de datos. Es por esto que los atributos son de entrada en las transacciones y de salida en los web panels. Y en lo que respecta a las variables, las mismas son de salida en las transacciones y de entrada en los web panels. La siguiente clasificación describe los distintos usos posibles de los web panels: Web panel de entrada: le damos este nombre a un web panel que tiene la única función de aceptar valores digitados por el usuario (esto significa que su form contendrá únicamente variables). Web panel de salida: le damos este nombre a un web panel que tiene la única función de mostrar información (esto significa que su form contendrá únicamente atributos, pudiendo también contener variables a las cuales se les haya cambiado el comportamiento por defecto de ser de entrada, definiéndolas de salida y cargándoles valores explícitamente). Web panel mixto: le damos este nombre a un web panel que permite tanto ingresar valores como mostrar información (en este caso su form contendrá tanto variables como atributos, o bien sólo variables, algunas con el comportamiento por defecto de ser de entrada y otras definidas explícitamente de salida y cargándoles valores). Vale aclarar que esta clasificación es independiente de la herramienta; es decir, GeneXus internamente no clasifica a los web panels. 249

5 Web panel de Entrada Event Enter Las variables adquieren el valor digitado luego de presionar algún botón. Event Enter RList.call( &NombreClienteInicial, &NombreClienteFinal ) endevent Denominamos web panels de entrada a aquellos web panels cuya única función es que el usuario realice ingresos de valores por medio de los mismos. Por lo tanto, sus forms contendrán solamente variables. Por ejemplo, un web panel de entrada puede contener dos variables &NombreClienteInicial y &NombreClienteFinal como se muestra arriba. En tiempo de ejecución, el usuario podrá ingresar valores en las variables &NombreClienteInicial y &NombreClienteFinal dado que en los web panels las variables son por defecto de entrada. En el evento Enter del web panel (asociado al botón Confirm), se invocará a un reporte, al cual se le pasarán por parámetro las variables &NombreClienteInicial y &NombreClienteFinal para que el reporte liste todos los clientes cuyos nombres se encuentren en el rango solicitado: Event Enter RListClienteRange.call( &NombreClienteInicial, &NombreClienteFinal ) EndEvent // Enter De modo que la definición de este web panel de entrada es para que el usuario ingrese el rango de clientes a listar, y al seleccionar el botón Confirm, se ejecute el reporte correspondiente. 250

6 Web panel de Salida tabla base: CLIENTE Regla: parm(in:clienteid); Denominamos web panels de salida a aquellos web panels cuya única función es exhibir datos. Para que un web panel únicamente muestre datos, su form debe contener solamente atributos, ya que los atributos en los forms de web panels son indefectiblemente de salida 1. Otra posibilidad es incluir en el form variables, pero habrá que cambiarles su comportamiento por defecto de ser de entrada, a ser de salida, y cargarles valores explícitamente 2. El web panel mostrado arriba ha sido creado para exhibir los datos de un cliente. Se necesita invocarlo desde otro objeto, pasándole por parámetro el código del cliente del cual se quiere mostrar la información. Para resolver esto, una vez creado el web panel Ver Datos del Cliente : se han agregado los atributos que se desean visualizar en su form se ha definido la regla: Parm(in: ClienteId); en la sección de reglas del objeto Tan sólo definiendo esto obtendremos el comportamiento deseado. Qué concluirá GeneXus acerca de este web panel, cuando lo especifiquemos? Primeramente GeneXus observará que los atributos incluidos en el form pertenecen a las tablas CLIENTE y PAIS respectivamente. El siguiente diagrama de Bachman explicita la relación entre ambas tablas: CLIENTE PAIS Al contrario de lo que sucede con los atributos en las transacciones (salvo los inferidos o los que tienen regla noaccept o propiedad Enabled deshabilitada). 2 El comportamiento por defecto de las variables también es opuesto entre Web Panels y Transacciones. 251

7 Teniendo en cuenta la relación entre las tablas involucradas, GeneXus descubrirá que deberá recorrer la tabla CLIENTE y acceder a la tabla PAIS por el concepto de tabla extendida. La tabla PAIS no podrá ser elegida para ser recorrida porque su tabla extendida no incluye a la tabla CLIENTE. Así es que GeneXus determinará un for each asociado al web panel, en este caso con tabla base CLIENTE; nosotros no escribimos el for each, pero GeneXus lo infiere automáticamente. A su vez, como en la regla parm definida en el web panel se recibe un atributo, el mismo actuará como filtro por condición de igualdad. Es decir, que al ejecutarse la recorrida de la tabla CLIENTE (accediendo a la tabla PAIS para traer el nombre de país), se filtrará por el código de cliente recibido por parámetro. Concluyendo, se recorrerá la tabla CLIENTE, con condición de filtro por el cliente recibido en la regla parm y se mostrarán los datos en la pantalla. El nombre del país del cliente (PaisNombre) se inferirá por el concepto de tabla extendida y se mostrará también en la pantalla. Decimos que este web panel tiene tabla base, y la misma es CLIENTE. Esto significa que el web panel tiene un for each implícito / automático asociado, cuya tabla base es CLIENTE. 252

8 Web panel de Salida grid: Se cargan los registros de la base de datos correspondientes en archivo temporal Regla: parm(in:clienteid); tabla base: FACTURA Este web panel ha sido creado para mostrar las facturas de determinado cliente. Se necesita desde otro objeto, invocar a éste, pasándole por parámetro el código del cliente del cual se quieren mostrar sus facturas. Para resolver esto, una vez creado el web panel Ver Facturas Cliente : se han agregado los atributos que deseamos visualizar en su form (utilizando el control grid para mostrar las N facturas del cliente en cuestión) se ha definido la regla: Parm(in: ClienteId); en la sección de reglas del objeto Este web panel, a diferencia del anterior no es plano, pero continúa siendo un web panel de salida, ya que lo único que hace es mostrar datos de la base de datos, sin permitir que el usuario ingrese nada. Cuando se incluye un grid en un form, se está indicando que se va a mostrar una cantidad indefinida de datos (en este caso, facturas). Dado que en este web panel hay involucrados atributos de las tablas CLIENTE y FACTURA y que la relación entre ambas tablas es: FACTURA CLIENTE GeneXus determinará que recorrerá la tabla FACTURA y accederá a la tabla CLIENTE por el concepto de tabla extendida. La tabla CLIENTE no podrá ser elegida para ser recorrida porque en su tabla extendida no se encuentra la tabla FACTURA. De modo que GeneXus determinará un for each implícito asociado al web panel, con tabla base FACTURA, accediendo a la tabla CLIENTE por el concepto de tabla extendida. Como en la regla parm definida en el web panel, se recibe un atributo, el mismo actuará como filtro por igualdad. Es decir, que al ejecutarse la recorrida a la tabla FACTURA accediendo a la tabla CLIENTE, se filtrará por el código de cliente recibido por parámetro. Decimos que este web panel tiene tabla base, y la misma es FACTURA. Esto significa que el web panel tiene un for each implícito/automático asociado, cuya tabla base es FACTURA. 253

9 Web panel Mixto: Work With Event Enter Evento Usuario Las variables adquieren el valor digitado luego de presionar algún botón Tabla Base: CLIENTE generales versus particulares Los web panels no tienen por qué ser sólo de entrada o sólo de salida. El web panel que se muestra arriba es de entrada/salida (mixto), su form contiene tanto variables como atributos. La funcionalidad de este web panel es cargar en el grid los datos de todos los clientes cuyos nombres cumplan con la condición de filtro especificada. La idea es digitar sobre la variable &ClienteNombre el valor de filtro deseado, y a continuación presionar el botón Buscar para que se ejecute la consulta en el servidor y el resultado de la misma sea cargado en la página. El evento asociado al botón Buscar puede ser el Evento Enter (evento del sistema) ó cualquier evento definido por el usuario (volveremos sobre esto más adelante). Las condiciones de filtro pueden definirse de dos maneras posibles: A nivel de un grid en particular (botón derecho sobre el grid/conditions): de hacerlo así, se tratará de condiciones particulares para ese grid (las que se muestran arriba). A nivel de todo el web panel (en la sección Conditions del objeto): de hacerlo así, se tratará de condiciones globales, es decir que aplicarán a todos los grids del web panel en los que tenga sentido aplicarlas (más adelante veremos web panels con múltiples grids). En el web panel del ejemplo tenemos un sólo grid, por lo cual ambas opciones serían equivalentes desde el punto de vista lógico. Sin embargo es recomendable escribir las condiciones a nivel del grid ya que en un futuro podrán agregarse más grids al web panel. Además teniendo las condiciones a nivel del grid se optimiza al momento de la especificación (ya que en caso contrario, GeneXus deberá estudiar para cada grid si aplicar las condiciones generales a ese grid particular o no). Qué lógica inferirá GeneXus al momento de la especificación del Web Panel? Como los atributos involucrados en el web panel pertenecen algunos a la tabla CLIENTE y otros a la tabla PAIS, y en la tabla extendida de CLIENTE está la tabla PAIS, GeneXus determinará que la tabla a recorrer es CLIENTE y que accederá por su extendida a la tabla PAIS para cargar el valor del atributo PaisNombre. Es decir, GeneXus determinará un for each implícito asociado al web panel, con tabla base CLIENTE. Las condiciones definidas antes (a nivel de grid) se incluirán en el for each implícito (como cláusulas where), de modo tal que al ejecutarse la consulta, se recorrerá la tabla CLIENTE, filtrando por dichas condiciones. Es importante considerar que tanto en las condiciones globales del web panel, como en las condiciones locales a un grid de un web panel, es posible utilizar la cláusula when al igual que cuando se definen filtros en los objetos reportes y procedimientos. 254

10 Web panel con tabla base? Decimos que un web panel es con tabla base cuando GeneXus puede determinar un for each implícito asociado a él. Es decir, si bien el analista no escribe un for each explícitamente en el web panel para efectuar la consulta, GeneXus lo determina automáticamente (por eso lo llamamos: for each implícito). Tabla base del for each implícito = Tabla base del web panel. Un Web Panel es sin tabla base cuando GeneXus no puede determinar una tabla de la base de datos a recorrer para mostrar la información que se presenta en el form. En este caso en el form solamente aparecen variables (y no atributos). Un web panel es con tabla base cuando de los atributos que aparecen, GeneXus puede determinar una tabla de la base de datos a recorrer para, recuperando sus registros, mostrar la información que aparece en los atributos del web panel. De este modo, es como si hubiéramos escrito un for each para navegar esa tabla base y trabajar con algunos atributos de la misma, y de la extendida. Si en el Web Panel no aparecieran atributos, sino solo variables, evidentemente GeneXus no podrá determinar una tabla a ser navegada. En este caso el web panel será sin tabla base. 255

11 Orden de los datos a recuperar Botón derecho sobre el grid: Para definir que una consulta se efectúe ordenando por ciertos atributos, y por ende que los datos extraídos de la consulta se muestren ordenados con dicho criterio, se debe hacer clic con el botón derecho del mouse sobre el grid, y seleccionar el ítem Order del menú pop up que se muestra arriba. A continuación, se presentará el diálogo para que se ingresen los atributos por los que se desea ordenar. Definir esto es equivalente a definir la cláusula order en el comando for each, y se aplica todo lo visto en dicho tema: desde que para ordenar en forma descendente por un atributo se debe encerrar el atributo entre paréntesis (), la creación de índices temporales cuando no exista un índice físico correspondiente a los atributos de ordenamiento, así como la posibilidad de utilizar la cláusula when para condicionar la aplicación de ese order. En nuestro web panel Trabajar Con Clientes ClienteNombre. ordenamos los clientes que se listan en el grid por El poder definir order para un grid permite entre otras cosas optimizar la consulta, cuando se establecen condiciones de filtro. Así, si en las conditions generales y/o las del grid particular, siendo la tabla base CLIENTE establecemos los filtros, teniendo dos variables ingresadas por el usuario: ClienteNombre >= &clientenombreinicio; ClienteNombre <= &clientenombrefin; Entonces, de no especificar un orden por ClienteNombre, se deberá recorrer toda la tabla, de principio a fin, para cargar los registros que cumplan con las condiciones. Especificando un order optimizamos la consulta. Nota: Solamente si el form del web panel no tiene ningún grid (atributos sueltos), y se necesita definir un orden específico para la consulta, se contará con la posibilidad de definir en la sección de reglas del web panel, la regla de sintaxis: order(att1, att2, attn); siendo att1, att2, attn: la lista de atributos que define el orden de la consulta. 256

12 Eventos en web panels En los web panels se utiliza la programación dirigida por eventos. Eventos disponibles en web panels: Evento Start EventoRefresh Evento Load Evento Enter Eventos de Usuario Evento Click asociado a control Dado que la programación de los Web Panels está dirigida por eventos, para poder programar adecuadamente un objeto de este tipo es necesario conocer los eventos existentes y el momento y orden en que éstos se disparan. 257

13 Evento Start Es un evento del sistema, que ocurre automáticamente siempre que se hace Get o Post y es el primer evento que se ejecuta. No se conocen valores de atributos, salvo los recibidos por parámetro. Esto se debe a que aún no se ha efectuado la consulta. Ejemplo: se puede utilizar para que un control del form no aparezca visible, para cargar un bitmap, para asociarle un Link a otro control, etc.: Event Start &var.visible = 0 &Update = LoadBitmap("images/edit.gif") newcontrol.link = Link(TCliente) endevent En el ejemplo, tendremos 3 controles en el form: la variable de nombre var, la de nombre Update de tipo Bitmap y un control de nombre newcontrol que puede ser, por ejemplo, un control imagen. En el evento Start se le asigna a la propiedad Visible del control variable &var el valor 0, indicando que no deberá verse en el form. A su vez, a la variable de tipo bitmap, &Update, se le carga la imagen que contendrá, y al control que suponemos imagen, newcontrol, se le define la propiedad Link, de manera tal que cuando el usuario haga clic sobre el control, se invocará a la transacción Cliente. 258

14 Evento Refresh El evento Refresh es un evento del sistema Se ejecuta cada vez que se realiza un Get o Post. Provoca que se ejecute la consulta a la base de datos. Es decir, al ocurrir el evento Refresh, se ejecuta lo codificado en dicho evento, y a continuación se ejecuta la consulta a la base de datos. Viene seguido siempre del evento Load. 259

15 Evento Load Cada vez que se ejecute el evento Refresh en un web panel, seguidamente se ejecutará el evento Load. La cantidad de veces que el evento Load será ejecutado, dependerá de si el web panel tiene tabla base o no la tiene: Tiene tabla base: Cuando aparecen atributos que le permiten automáticamente determinar que se desea navegar una tabla determinada de la base de datos El evento Load se ejecutará N veces No tiene tabla base: Cuando no ocurre lo anterior (en el form solo hay variables) El evento Load se ejecutará solamente una vez. Cuando el web panel es con tabla base, al producirse el evento Refresh se accede a la base de datos, a esa tabla base (la asociada al web panel), y se la recorre cargando los registros que cumplan las condiciones (conditions del grid y generales). Ocurrirá en ese proceso un evento Load por cada registro en el que se esté posicionado, inmediatamente antes de cargarlo. Esto nos permite realizar alguna operación que requiera de ese registro (y de su extendida), antes de efectivamente cargarlo en el grid. Inmediatamente luego de ejecutado el código asociado al evento Load, se cargará la línea del grid y se pasará el puntero al siguiente registro de la tabla base, para realizar lo mismo (evento Load, carga de la línea). Este proceso se repetirá hasta cargar todas las líneas del grid. Si un web panel es sin tabla base, GeneXus no puede determinar automáticamente una tabla de la base de datos a recorrer para mostrar la información que se presenta en el form. En este caso en el form solamente aparecen variables (y no atributos) y también ocurrirán los eventos Refresh y Load, sólo que el evento Load se ejecutará una única vez, dado que no se estará posicionado en ningún registro de ninguna tabla. 260

16 Evento Load en web panel con tabla base Luego del evento Refresh se ejecuta el evento Load N veces: una vez por cada registro de la tabla base leído para ser cargado en la línea del grid Por cada registro leído en la consulta efectuada a la base de datos, se disparará el evento Load (ejecutándose el código incluido en el mismo, y cargándose a continuación una línea en el grid con los datos asociados al registro). 261

17 Evento Load en web panel con tabla base: ejemplo Si en el grid que muestra los clientes que cumplen con las condiciones de filtro, quisiéramos agregar una columna al final, que marque que el cliente es moroso (deudor) si su saldo es mayor a $10.000, es decir, que en ejecución sobresalga su condición de moroso apareciendo un literal DEUDOR en ese caso, alcanza con agregar una variable &tipo al grid, de tipo Character(10) y cargarla en el evento Load del web panel como se muestra arriba. Para cada registro de la tabla base CLIENTE que se vaya a cargar como línea en el grid, se ejecutará el código del evento Load, cargándose en la columna &tipo el valor DEUDOR únicamente si el saldo de ese cliente que va a listarse supera los $ Luego, si para cada cliente del grid además de mostrar su nombre, país, sexo, saldo y tipo, queremos mostrar la cantidad de facturas que se le han emitido, alcanza con agregar una variable &cantidad al grid, e incluir en el código del evento Load, el for each para contar esas facturas. Observar que el for each definido en el evento Load estará anidado al for each implícito (el de la tabla base), por lo que se efectuará un join, recorriéndose solamente las facturas de ese cliente, el que se está cargando. 262

18 Evento Load en web panel sin tabla base En un web panel sin tabla base, el evento Load se ejecutará solamente una vez. Evento Refresh Evento Load Que el web panel no tenga tabla base, significa que no tiene un for each implícito asociado; por lo tanto, cuando se ejecute el evento Refresh, no comenzará a ejecutarse ninguna consulta; se ejecutará el código asociado al evento Refresh, y a continuación se ejecutará el código asociado al evento Load, una única vez. Aquí es donde tendremos que cargar el grid, consultando la base de datos con un for each explícito. A continuación vemos el código de este evento. 263

19 Evento Load en web panel sin tabla base: ejemplo Comando (que solo puede ir dentro de evento Load) para efectivamente cargar una línea con el valor que tengan las variables en ese momento. El objetivo del comando LOAD dentro del evento Load es cargar efectivamente una línea en el grid. Una vez que se hayan asignado valores a todas las variables que sean necesarias, y se desee agregar la línea al grid, deberá ejecutarse el comando LOAD. Solamente se puede especificar el comando LOAD dentro del evento Load del grid de un web panel y en ningún otro lado. Event Load for each &ClienteId = ClienteId &ClienteNombre = ClienteNombre &ClienteSexo = ClienteSexo &ClienteSaldo = ClienteSaldo if ClienteSaldo > &tipo = DEUDOR else &tipo = endif &cantidad = 0 for each defined by FacturaFecha &cantidad += 1 endfor Load /* LUEGO DE HABER CARGADO TODAS LAS VARIABLES CON LOS VALORES CORRESPONDIENTES A LA LÍNEA A SER CARGADA EN EL GRID, DEBEMOS INCLUIR EL COMANDO LOAD, EL CUAL AGREGARÁ EFECTIVAMENTE LA LÍNEA AL GRID. */ endfor Endevent Si en la codificación del evento Load definimos comandos For each y asignamos valores a las variables en las iteraciones pero no incluimos el comando LOAD, en tiempo de ejecución estaremos asignando una y otra vez valores a las variables, pero no se estarán agregado líneas en el grid (solamente quedará una línea en el grid con los últimos valores cargados en las variables). Por esta razón es muy importante no olvidar escribir este comando en el lugar apropiado. 264

20 Evento Enter Cuando se inserta un nuevo botón en el form de un Web Panel, por defecto aparece con el Caption Confirm y aparece asociado al evento del sistema Enter. El evento Enter puede asociarse a cualquier botón, atributo, imagen, text block, en la propiedad de los controles: OnClickEvent. De modo que si se necesita ejecutar acciones cuando el usuario final haga clic en el control asociado, en este evento deberán codificarse. 265

21 Eventos de usuario Además de los eventos ofrecidos por GeneXus, el analista puede definir eventos creados por él, llamados eventos de usuario. Cada evento de usuario debe asociarse a un control insertado en el form del web panel de los que soportan el OnClickEvent (botones, text blocks, imágenes, atributos) En tiempo de ejecución, el evento de usuario ocurrirá luego de que el usuario haga clic sobre el control asociado al mismo. Casi todos los controles que aparecen en el form brindan la posibilidad de disparar un evento cuando el usuario hace clic con el mouse sobre ellos (aparecen como hipervínculos en ejecución); se consigue de dos maneras distintas: 1. Editando las propiedades del control, y definiendo un evento de usuario en la propiedad OnClickEvent 2. Dándole un nombre al control y en la sección de Eventos programando: Event nombrecontrol.click Endevent Con esta última alternativa no tendremos que definir un evento de usuario, sino que estaremos programando el evento click del control. 266

22 Web panel "Trabajar Con Cliente Acciones sobre el cliente seleccionado Para que el web panel con el que venimos trabajando sea un verdadero trabajar con se le deben agregar acciones a ser efectuadas sobre los clientes: la posibilidad de insertar un nuevo registro (nuevo cliente), el modificar uno existente, o el eliminarlo (así como también poder simplemente visualizarlo ). Una forma de implementar esto es agregar los cuatro botones que aparecen arriba, en el form:. un botón que ofrezca insertar un cliente (Insert). un botón que ofrezca modificar un cliente (Update). un botón que ofrezca eliminar un cliente (Delete). un botón que ofrezca visualizar los datos de un cliente (View) Además debemos permitir la selección de una línea de la grilla para aplicarle alguna de las acciones definidas en los botones del form. Para ello, accedemos a las propiedades de la grilla con botón derecho sobre el control grid y configuramos la propiedad AllowSelection con el valor True como muestra la figura. Al hacerlo se nos habilitan tres propiedades más, que permiten especificar SelectionColor: el color que tendrá la línea cuando el usuario la seleccione (haciendo clic con el mouse sobre la misma); AllowHovering: la posibilidad de que cambie el color de las líneas cuando el usuario se desplaza con el mouse sobre ellas, y HoveringColor: el color que tendrá una línea cuando el mouse pasa sobre ella. Estas funcionalidades se implementan con código javascript que se envía al Browser al ejecutar el Web Panel. En la sección de eventos del web panel, definiremos el código asociado a estos botones. Lo veremos en la página siguiente. 267

23 Eventos de usuario en el web panel Trabajar Con Cliente Event Insert TCliente.call( INS, 0) Endevent Event Update TCliente.call( UPD, ClienteId) Endevent Event Delete TCliente.call( DLT, ClienteId) Endevent En las reglas de la transacción Cliente : Parm(&Mode, &ClienteId ); Variable del sistema Variable de usuario ClienteId = &ClienteId if not &ClienteId.IsEmpty(); Event View TCliente.call( DSP, ClienteId) Endevent La variable &Mode es del sistema y su tipo es Character(3). Tiene la particularidad de entender 4 valores: INS : este valor indica ejecutar la transacción en modo Insert UPD : este valor indica ejecutar la transacción en modo Update DLT : este valor indica ejecutar la transacción en modo Delete DSP : este valor indica ejecutar la transacción en modo Display Cuál es el resultado de recibir por parámetros en una transacción el modo de ejecución y la clave primaria? El permitir insertar, modificar o eliminar puntualmente una instancia y luego retornar al objeto llamador. Es por ello que en todos los eventos definidos en el Web Panel Trabajar Con Cliente estamos invocando a la transacción Cliente, pasándole dos valores por parámetro: un literal de 3 letras, que es el modo y el código de cliente correspondiente a la línea del grid que fue seleccionada (por ello necesitamos habilitar la selección de líneas del grid, mediante la propiedad AllowSelection que vimos antes). En definitiva la regla parm a definirse en la transacción "Cliente", es: parm(&mode, &ClienteId); Como se puede observar, no recibimos el código de cliente directamente en el atributo ClienteId, sino en una variable. Por qué? Si declaráramos el atributo ClienteId en vez de una variable, el valor que se recibiera en él actuaría automáticamente como filtro por igualdad. Sin embargo cuando invocamos a la transacción "Cliente" con los parámetros INS y 0, el modo INS indica que queremos que la transacción se ejecute en modo insert; y como en dicho caso no tenemos que enviar el código de cliente para instanciarlo, completamos el segundo parámetro con valor 0 (porque la cantidad y el tipo de datos- de los parámetros enviados, debe coincidir con la cantidad y el tipo de datos- de los parámetros recibidos). De modo que el valor 0 es para completar el parámetro simplemente, no para que se filtre por él tratando de instanciar un cliente de código 0. En los otros 3 casos en que se invoca a la transacción "Cliente" (con los parámetros UPD y ClienteId ; DLT y ClienteId ó DSP y ClienteId respectivamente) sí se quiere filtrar por el valor del código de cliente recibido; pero basta que haya un caso en el cual se invoque a la transacción y que no sirva filtrar por el valor recibido, para que no sirva recibir el parámetro en el atributo y esa es la razón por la cuál se está recibiendo en una variable. Si la clave primaria, ClienteId es autonumerada, entonces en ese caso sí podrá recibirse en atributo. Recuerde que a partir de la inclusión de la regla parm en un objeto, éste desaparece del Developer Menú, debido a que desde el mismo no es posible el envío de parámetros. 268

24 Web panels - Funcionamiento Esquema de trabajo en Internet: el servidor no sabe lo que se está haciendo en el Browser, hasta que se someta la página. Es decir, hasta que se dispare un evento (enter, de usuario, click). Orden de disparo de eventos: es diferente si se trata de la primera carga del web panel (Get) o si ya estaba cargado cuando se dispara un evento de usuario, enter, click (Post) Es importante entender que en Internet, cuando el usuario accede a una página del servidor Web para visualizarla, el Browser baja la página al cliente. Por lo tanto, no existe forma de detectar lo que realiza el usuario: el servidor Web volverá a tener el control cuando se dispare el evento ENTER o algún evento de usuario o click. En ese momento se envía (se somete, se hace un post) el resultado al servidor para continuar con su procesamiento. Es decir, una vez que el objeto web finaliza la ejecución en el servidor, no queda en memoria. Como consecuencia, la forma en que programamos este tipo de aplicaciones presenta algunas diferencias con respecto a lo acostumbrado en ambientes no web. Es por esta razón que es importante destacar el orden en que se disparan los eventos y el momento en que las variables adquieren el valor ingresado por el usuario. El orden de ejecución de los eventos en web panels es diferente si se trata de la primera llamada al mismo (GET) o si se disparó algún evento de usuario, enter o click (POST). 269

25 GET: Orden de disparo de eventos Al ejecutar un web panel por primera vez se disparan los siguientes eventos: Start Refresh Load La primera vez que se ejecuta el web panel (se conoce también como el momento en que se hace el GET de la página) los eventos que se disparan son los siguientes y en el siguiente orden: 1. Start 2. Refresh 3. Load Luego de esto, cuando el usuario haga clic sobre un control que tenga asociado el evento Enter o uno de usuario o click se ejecutará nuevamente el web panel y el orden de disparo de los eventos será diferente, como se indica en la siguiente página. 270

26 POST: Orden de disparo de eventos Resto de las ejecuciones del web panel: Start Lectura de variables en pantalla Evento Enter o de usuario (submit) Refresh Load En el resto de las ejecuciones del web panel, que ocurren cuando se presiona un botón, o se fuerza la ejecución del evento asociado a una imagen, text block, etc. (haciendo clic sobre el control que tiene asociado el evento de usuario o Enter o click) momento que se conoce también como el POST de la página, los eventos se dispararán en el siguiente orden: 1. Start (nuevamente se dispara el evento Start) 2. Lectura de las variables de la pantalla. Esto se realiza porque el usuario puede haberlas modificado (por ejemplo las variables de la parte fija del web panel que están involucradas en las conditions, como en el ejemplo que se presenta arriba, donde se quieren cargar en el grid los clientes cuyo nombre contenga el string cargado por el usuario en la variable &ClienteNombre) 3. Evento Enter o click o evento de usuario (código correspondiente al evento asociado al control que se presionó y produjo el POST). 4. Refresh 5. Load En el ejemplo no necesitamos codificar nada en el evento asociado al botón Buscar. Solo lo pusimos para poder enviar al servidor la variable con el valor que ingresó el usuario y que la página se refresque cargando en el grid los clientes que cumplan con el filtro que el usuario estableció mediante esa variable. 271

27 Web panels - Variables Variables: adquieren valor ingresado por el usuario luego de sometido evento (POST) Si en un evento se usa una variable que se carga en otro evento la variable debe estar en el form, y además debe estar después del control en el que se carga su valor. Ejemplo: Event Load &cont+=1 endevent Event Refresh &cont= 0 endevent Event Enter if &cont<5 endevent Relacionado con el orden de disparo de los eventos, es importante destacar el momento en que las variables adquieren los valores ingresados por el usuario: solamente lo harán después de presionar un botón 1 (que es cuando el servidor Web tiene el control del procesamiento). Por ejemplo, cualquier Link especificado en el evento Start a otro web panel con una variable que se ingresa en el form no va a tener ningún valor cuando se haga clic sobre el Link. (Ej: control.link = HWebPanelX.Link(&var). No se debe escribir esto en el start si la &var esta en el form, porque al momento de armarse el link no se tiene el valor de la variable) Si en un evento se usa una variable que se carga en otro evento, entonces esa variable debe estar presente en el form. Si no está en el form, la variable no tendrá valor cuando se disparen los eventos que la consultan (esto es por el orden en que ocurren los eventos). Además, deberá estar en el form después del control en el que se carga. Por ejemplo, si la variable se carga en el LOAD de un grid entonces la variable tiene que estar en pantalla después del grid. Ejemplo: web panel con grid que lista las facturas existentes, y queremos contar la cantidad de facturas que se listan en el grid. Para ello definimos una variable &cont que debemos incrementar cada vez que se carga una nueva línea, es decir, en el evento Load del grid. Para que la variable se cargue correctamente, deberá incluirse luego del grid, puesto que de lo contrario ya se habrá dibujado en la página, antes de que pueda ser cargada por el evento Load. Gracias a tenerla en el form, cuando el usuario presione el botón Confirm que consulta por el valor de la variable, la misma podrá tener el valor cargado antes por el Load. Recordemos que al presionar el botón Confirm se realizará un POST al servidor, y en él se dispararán Start, lectura de variables de pantalla (aquí se leerá el valor de &cont que había sido cargado antes por el evento Load), luego se disparará el evento Enter asociado al Confirm y dentro del mismo se consulta por el valor de la variable, que gracias a que fue enviada al servidor por estar en el form, tiene el valor que se había cargado antes. Luego se dispararán Refresh y Load. Observemos que aquí, cuando se dispare el Load, se incrementará la variable, por lo que deberemos resetearla antes de que se empiecen a cargar las líneas, porque de lo contrario mostrará el doble de las líneas que tenía antes. Dónde resetearla? Event Refresh &cont = 0 endevent O hacer clic sobre algún control del form que tenga un evento de usuario o click o Enter asociado (ya sea con la propiedad Link, o la propiedad OnClickEvent, o el evento click). 272

28 Ejemplo: Supongamos que tenemos un web panel donde en un sector del form se puede ingresar usuario y contraseña para loguearse al sistema. En el evento donde validamos el usuario y la contraseña (asociado a algún botón o text block), guardamos en una variable el código de usuario para poder utilizarlo en otro evento. Esto nos permitiría, por ejemplo, llamar a un objeto que permita visualizar los datos del usuario (por ejemplo un web panel de nombre DatosCliente, que recibirá por parámetro el identificador de cliente). En consecuencia, primero que nada, deberíamos programar lo siguiente en el evento donde validamos el usuario: Event Login For each Where ClienteUser = &ClienteUser If ClientePassword = &ClientePassword &ClienteId = ClienteId Mensaje.Caption = Bienvenido/a +trim(clientenombre) Else Mensaje.Caption = La contraseña ingresada no es correcta Endif When none Mensaje.Caption = El usuario ingresado no existe Endfor Endevent donde Mensaje es el nombre de un text block que dinámicamente (con la propiedad Caption) cambia de texto. Obsérvese que tenemos una tabla CLIENTE que contiene la info de usuario y password. Para realizar la llamada al web panel Datos del Cliente (DatosCliente), existen varias alternativas, una de las cuáles sería agregar un botón o una imagen con un evento click asociado (o definir un evento de usuario y asociárselo al control mediante la propiedad OnClickEvent), entonces el código seria el siguiente: Event Ver.clic // ver es el nombre de la imagen o botón. HDatosCliente.Call(&ClienteId) Endevent Repasemos entonces lo que ocurre: 1. En la primera ejecución se disparan los eventos: Start, Refresh y Load y podemos ingresar el usuario y password en las variables respectivas. 2. Cuando presionamos el botón o text block para validar el login, se dispara el evento Start, se leen las variables anteriores que están en pantalla, se ejecuta el código del evento Login, donde se asigna a la variable &ClienteId el código de cliente del usuario correspondiente. Luego ocurren Refresh y Load y la página se despliega en el Browser. 3. Ahora, ya estando logueados, cuando presionamos la imagen o botón con el evento click asociado, se dispara el evento Start, se leen las variables que están en pantalla, se ejecuta el evento click y ahí cuando redireccionamos al Web Panel DatosCliente, la variable &ClienteId no tiene valor alguno, ya que la misma se perdió luego de haber finalizado la ejecución del Web Panel en el punto 2. Es por esta razón que si queremos disponer del valor de la misma, deberíamos agregar la variable &ClienteId en el form y la ocultaríamos usando la propiedad Visible (por ejemplo en el evento Start). Event Start &ClienteId.Visible = 0 Endevent Entonces en este caso, cuando el Web Panel ejecute por segunda vez, se dispararán los eventos: 1. Start 2. Se leen las variables del form (en este momento se obtiene el valor de &ClienteId) 3. Se ejecuta el evento click, y por consiguiente se llama al Web Panel con el código de cliente correcto. Esto es porque no existe un concepto de memoria local para los web objects, por lo cual, si en un evento se usa una variable que se carga en otro evento, entonces esa variable debe estar presente en el form, de manera que, aprovechando el orden de disparo de los eventos en el POST, se obtenga el valor de la variable. 273

29 Definición de columnas ocultas en el grid de un web panel Al hacer botón derecho sobre el grid y seleccionar Columns: Editar las propiedades de la columna que se quiere ocultar: Hay veces que por motivos de presentación, no se desea incluir ciertos atributos o variables como columnas visibles de un grid, pero se necesita tener sus valores cargados en columnas ocultas. Por qué motivo se puede necesitar definir una columna oculta en el grid de un web panel? Un grid siempre tiene un archivo temporal asociado. Cuando en un Web Panel se ejecuta el evento Refresh, se comienza a ejecutar la consulta a la base de datos; a continuación por cada registro leído que cumpla con las condiciones de filtro definidas, se ejecuta el evento Load y se cargan los datos de dicho registro, en el archivo temporal asociado al grid. Qué datos de los registros se cargan en el archivo temporal? Es decir, qué columnas contendrá el archivo temporal? Una columna por cada atributo o variable mostrado en el grid, más una columna por cada atributo o variable declarado en el grid como columna oculta. A modo de ejemplo, si en un grid hay 2 columnas visibles con los atributos ClienteNombre y ClienteSaldo y ninguna columna oculta, el archivo temporal asociado al grid contendrá 2 columnas correspondientes a los atributos ClienteNombre y ClienteSaldo, respectivamente. Si además de esas 2 columnas visibles, se declara el atributo ClienteId como columna no visible en el grid, el archivo temporal asociado contendrá 3 columnas correspondientes a los atributos ClienteNombre, ClienteSaldo y ClienteId, respectivamente. Si en el grid sólo incluimos 2 columnas visibles con los atributos ClienteNombre y ClienteSaldo, en el caso en que necesitemos en un evento de usuario conocer el valor del atributo ClienteId correspondiente al cliente de cierta línea seleccionada (para escribir alguna sentencia utilizándolo), no lo tendremos. Para conocer en un evento de usuario el valor del atributo ClienteId correspondiente a cierta línea seleccionada, tendremos que incluirlo en el grid ya sea visible o no visible, pero debe estar presente. Como ejemplo, pensemos en nuestro Web Panel Trabajar Con Clientes : necesitábamos una vez que el usuario seleccionaba una línea, y presionaba el botón Update llamar a la transacción Cliente enviándole como parámetro el ClienteId seleccionado. En este caso necesitamos tener el ClienteId en el archivo temporal, ya sea que esté visible en el grid o no lo esté. Cómo ocultar una columna en un grid? Para ocultar una columna en un grid, debemos configurar la propiedad Visible del atributo o variable que se desea ocultar con valor False. Para ello, debemos hacer clic con el botón derecho del mouse sobre el grid y seleccionar las columnas (Columns) de la grilla; se abrirá el diálogo mostrado. Luego, habrá que posicionarse en el atributo o variable que se desee definir como columna oculta, y editar sus propiedades (Properties). Por último, se debe configurar la propiedad Visible de la columna con valor False. 274

30 De modo que el motivo por el cual podemos necesitar incluir un atributo o variable como columna oculta de un grid, es porque necesitemos conocer el valor de ese atributo o variable en un evento de usuario, pero no deseemos mostrarlo. Así como los eventos de usuario trabajan con los datos cargados en el archivo temporal asociado al grid, las condiciones de filtro en cambio, trabajan sobre la tabla física consultada y su tabla extendida; por lo tanto, al definir condiciones de filtro, se podrán referenciar atributos que pertenezcan a la tabla física que se consulta y su tabla extendida, sin la necesidad de que dichos atributos deban estar incluidos en el grid (ni visibles ni ocultos) ni en ninguna otra sección del web panel. Por ejemplo, piénsese en el ejemplo que ya presentamos antes: Event Load if ClienteSaldo > &tipo = 'DEUDOR' else &tipo = '' endif endevent Aquí surge la pregunta: como en este evento utilizamos el atributo ClienteSaldo para poder cargar adecuadamente la variable, es necesario colocarlo oculto en el grid? La respuesta es no. En el evento Load estamos posicionados en un registro de la tabla base. Tenemos a disposición todos los atributos de esta tabla base y de la extendida, sin necesidad de cargarlos luego en el grid. 275

31 Comando FOR EACH LINE GeneXus nos provee el comando For each line para recorrer las líneas de un grid en un web panel: for each line [in NombreGrid] Sentencia 1 Sentencia N endfor in NombreGrid: solamente es necesario explicitarlo cuando hay más de un grid en el form del web panel. Sentencia 1,, Sentencia N: sentencias a ejecutarse para cada línea recorrida del grid. 276

32 Comando FOR EACH LINE Ejemplo Event Borrar for each line if &dlt = S PBorrClientes.call(ClienteId) endif endfor Endevent A continuación, implementaremos un caso de selección múltiple, una operativa diferente a la presentada en el caso del web panel Trabajar Con Clientes, que permitía seleccionar una única línea por vez (selección simple). La operativa que pretendemos ofrecer en el web panel BorrClientes presentado arriba es la siguiente: luego de que el usuario haya ingresado un substring para filtrar los clientes y se haya cargado el grid con los clientes que cumplan dicho filtro, el usuario podrá marcar (con un clic del mouse) qué líneas (clientes) desea eliminar. En el ejemplo, hemos incluido en el grid del web panel BorrClientes", una variable de nombre &dlt (definida como check box), además de los atributos ClienteId, ClienteNombre, PaisId, PaisNombre y ClienteDireccion. De esta forma, el usuario seleccionará el check box en los clientes que desea eliminar. A su vez, tendríamos que tener un botón Borrar" y en el código del evento asociado a dicho botón deberíamos recorrer el grid y para cada línea seleccionada invocar a un procedimiento que haga la eliminación física de dicho cliente. A continuación incluimos el código del procedimiento BorrClientes que recibe en la regla parm el código del cliente a eliminar (ClienteId). Reglas: Parm(ClienteId); Source: for each defined by ClienteNombre Delete //se elimina el cliente recibido como parámetro Endfor 277

33 Variables en un grid Por defecto todas las variables de un grid son Read-Only For each line [in grid], evento click, OnClickEvent: modifica valor por defecto y todas las variables del grid pasan a ser de entrada. Propiedad: Read Only para que alguna sea de salida. Cómo desplegar datos en un grid Por defecto todo atributo y variable que está dentro de un grid se despliega en ejecución como texto, es decir que es únicamente de lectura y por consiguiente no puede ser modificado. Cómo aceptar datos en un grid Es posible aceptar datos en las variables de un grid dependiendo de la programación de los eventos existentes en el objeto: 1. Si dentro de un evento del web panel se está utilizando el comando For each line, todas las variables que están dentro del grid pasan a ser de entrada. Es posible indicar en este caso cuáles son las variables que no van a poder ser modificadas (Ver más abajo). 2. Si dentro de la fila hay algún control con un evento click asociado (ó evento de usuario especificado en la propiedad OnClickEvent). Cómo indicar que una variable no puede ser modificada 1. Para indicar que el valor de una variable en un grid no puede ser modificado, debemos configurar la propiedad Read Only de la variable con valor True. Para ello, debemos hacer clic con el botón derecho del mouse sobre el grid y seleccionar las columnas (Columns) de la grilla. Luego, habrá que posicionarse en la variable que se desee definir como de sólo lectura, y editar sus propiedades (Properties). Por último, se debe configurar la propiedad Read Only de la columna con valor True. 2. Utilizando la regla Noaccept() 278

34 Diferentes tipos de grilla/grid Grid estándar: datos repetitivos en formato fijo (línea, columna) Grid Freestyle: datos repetitivos en formato libre Se dispone de dos tipos de grilla: Grilla estándar: la que vimos hasta ahora, en Transacciones y Web Panels Grilla Freestyle Estas grillas, agregan potencia al diseño de aplicaciones web, permitiendo al desarrollador mayor libertad a la hora del diseño. 279

35 Grid estándar Propiedades: Establece si el grid se cargará o no por páginas (paginado). Indica cantidad de filas por página. 0 todas (no habrá paginado) Permite selección de línea del grid Los grids permiten trabajar con datos repetitivos en web panels y transacciones con form HTML. Las columnas de los grids pueden ser atributos, variables (incluyendo las de tipo bitmap), y siempre tendrán una primera fila que corresponderá a los títulos de las columnas. En ejecución, el grid será una tabla HTML. Para interiorizarse de cada una de las propiedades configurables de un grid, sugerimos acceder al Help de GeneXus. Aquí solo mencionaremos algunas como ejemplo: ControlName: Permite indicar el nombre del control. Siempre se le asigna un nombre por defecto. Class: Clase (del tema asociado al objeto) asociada al control. La propiedad Class solo se encuentra disponible si el control está en el form de un objeto que tiene un Tema asociado. BackColorStyle: Permite asignar un estilo al grid. Los estilos disponibles son: 1. None: el grid no tendrá un estilo particular, sino que tendrá el diseño del form o del control que lo contenga. 2. Header: permite especificar un color para el fondo de los títulos del grid y otro para las líneas del mismo. Las propiedades son LinesBackColor y TitleBackColor. 3. Report: permite especificar un color para el fondo de los títulos y alternar colores para las líneas pares e impares del grid. Las propiedades son LinesBackColor, LinesBackColorEven y TitleBackColor. 4. Uniform : permite especificar un único color para el fondo del grid(tanto el título como las líneas). Dependiendo del valor de la propiedad BackColorStyle, estarán disponibles otras propiedades adicionales relacionadas con la configuración de las líneas del grid. Rows: Esta propiedad permite al usuario indicar la cantidad de registros que va a cargar en el grid. Aplica únicamente a los grids que tienen tabla base. Si el valor de esta propiedad es 0, se despliegan tantas líneas como registros resulten de la consulta asociada. El valor por defecto de esta propiedad es 0. Collapsing: AllowCollapsing :True: Permite colapsar el grid en ejecución Collapsed :True: Arranca el grid colapsado. Selection: AllowSelection: True: Especifica que es posible seleccionar una línea en la grilla. SelectionColor: Seleccionar el color deseado al marcar la fila AllowHovering: True: Marca la fila cuando el mouse se posiciona sobre la misma. HoveringColor: Seleccionar el color deseado 280