1

Diseo de Aplicaciones

TABLA DE CONTENIDOSINTRODUCCIN: DISEO DE APLICACIONES

CAPITULO 1: DESARROLLO DE UNA APLICACIONDESARROLLO DE UNA APLICACIN SISTEMA DE COMPRAS PARA UNA CADENA DE FARMACIAS DEFINIR EL OBJETIVO DEFINIR EL EQUIPO DE TRABAJO OBTENER UNA IMAGEN GLOBAL DEFINIR EL ALCANCE DE LA APLICACIN MANTENER EL DISEO SIMPLE ORIENTARSE A LOS DATOS

CAPITULO 2: DISEO DE TRANSACCIONESESTRUCTURA DE UNA TRANSACCIN Atributos Dominios Atributos Clave Relacin entre la estructura y el modelo de datos Tipos de controles Definicin de la transaccin de pedidos Niveles de una transaccin Tipos de relacin entre los objetos FORM DE UNA TRANSACCIN Dilogo campo a campo Dilogo full-screen Barra o Botones de Men Atributos de entrada y atributos de salida Facilidad de Prompt de Seleccin FORM EDITOR Form Edition Controls Paleta de herramientas

2Uso de las Herramientas Toolbar Propiedades de los controles Editor de Propiedades, Mtodos y Eventos FRMULAS Frmulas Horizontales Frmulas Verticales Frmulas y Redundancia Frmulas de Frmulas REGLAS Default Error Asignacin Add y Subtract Serial Orden de evaluacin Call PROPIEDADES

CAPITULO 3: DISEO DE REPORTESLAYOUT Comando FOR EACH Reportes con varios FOR EACH Otros comandos CONDICIONES REGLAS Default Parm REPORT WIZARD PROPERTIES

CAPITULO 4: REPORTES DINAMICOS GENEXUS QUERY

CAPITULO 5: DISEO DE PROCEDIMIENTOSDISEO DE PROCEDIMIENTOS Modificacin de datos Eliminacin de datos Creacin de datos CONTROLES DE INTEGRIDAD Y REDUNDANCIA

CAPITULO 6: DISEO DE PANELES DE TRABAJODISEO DE PANELES DE TRABAJO EJEMPLO FORM DEL WORK PANEL Subfile EVENTOS

3Evento Start Evento Enter Eventos definidos por el usuario (User Defined Events) Evento Refresh Carga de datos en el Panel de Trabajo CONDICIONES REGLAS Order Noaccept Search BITMAPS Fixed Bitmaps Dynamic Bitmaps GRFICAS PROPERTIES Generar como una ventana Popup DILOGOS OBJETO-ACCIN

CAPITULO 7: DISEO DE MENUES

CAPITULO 8: OBJETOS WEB

ANEXO A: MODELOS DE DATOS RELACIONALES

ANEXO B: FUNCIONES, REGLAS Y COMANDOS

4

INTRODUCCINEl presente documento es una introduccin al desarrollo de aplicaciones utilizando GENEXUS. Est dirigido a profesionales de informtica que se inician en el uso de GENEXUS. GENEXUS es una herramienta para el desarrollo de aplicaciones. Su objetivo es ayudar a los analistas de sistemas a implementar aplicaciones en el menor tiempo y con la mejor calidad posible. A grandes rasgos, el desarrollo de una aplicacin implica tareas de anlisis, diseo e implementacin. La va de GENEXUS para alcanzar el objetivo anterior es liberar a las personas de las tareas automatizables (por ejemplo, la implementacin), permitindoles as concentrarse en las tareas realmente difciles y no automatizables (comprender el problema del cliente). Desde un punto de vista terico, GENEXUS es una herramienta asociada a una metodologa de desarrollo de aplicaciones. Como metodologa, tiene algunos puntos de contacto con las metodologas tradicionales, pero aporta enfoques bastante diferentes en otros. En comn con las metodologas tradicionales, se mantiene el nfasis del anlisis y diseo de la aplicacin sobre la implementacin. Con GENEXUS este enfoque se resalta ms an, ya que el usuario de GENEXUS estar la mayor parte del tiempo realizando tareas de anlisis y GENEXUS, en s, tareas de diseo e implementacin (por ejemplo, normalizacin de la base de datos, generacin de programas, etc.). Por otro lado, algunos de los enfoques metodolgicos son bastante diferentes que los habituales, como, por ejemplo, el comenzar el anlisis de la aplicacin por la interface con el usuario, la casi nula referencia a la implementacin fsica del sistema, etc. Para presentar estos nuevos conceptos, y a los efectos de no realizar una presentacin demasiado abstracta del tema, se ha elegido una aplicacin que se ir desarrollando a travs de los distintos captulos. El primer captulo presenta la aplicacin y los aspectos iniciales de un desarrollo con GENEXUS. Los siguientes captulos presentan los distintos objetos con los que GENEXUS cuenta para describir aplicaciones los cuales se utilizan para desarrollar la aplicacin de ejemplo. As, el segundo captulo trata el diseo de Transacciones, el tercero de Reportes, el cuarto de Procedimientos, el quinto de Paneles de Trabajo y por ltimo se trata el diseo de Menes. Debido a que en todos los captulos se asume cierto conocimiento sobre Bases de Datos Relacionales, se ha incluido un anexo sobre el tema que describe los conceptos necesarios para poder entender este documento. Se recomienda su lectura antes de leer el segundo captulo. Por razones didcticas, en este documento no se tratan los siguientes temas: Ciclo de vida de una aplicacin: Una aplicacin tiene un ciclo de vida, que comienza cuando se planifica la misma y termina cuando la aplicacin sale de produccin. GENEXUS acompaa todo este ciclo. Uso de GENEXUS.

La versin de GENEXUS utilizada en este libro es la 7.5. Puede obtenerse una versin de prueba de GENEXUS accediendo a: http://www.genexus.com/trialversionlquier atributo que pertenezca a la tabla extendida.

5

1. DESARROLLO DE UNA APLICACINDESARROLLO DE UNA APLICACIN La aplicacin que se ha elegido es una simplificacin de una aplicacin real. SISTEMA DE COMPRAS PARA UNA CADENA DE FARMACIAS:

En una cadena de farmacias se desea implementar un sistema de compras que permita a los analistas de compras realizar dicha tarea con la mayor cantidad de informacin posible. La funcin de un analista de compras es decidir los pedidos que se deben efectuar a los proveedores de los distintos artculos. Funcionamiento del sistema: Se desea que el analista de compras utilice el computador para definir los pedidos a los distintos proveedores. Una vez que el pedido est hecho y aprobado, se quiere que el computador emita las rdenes de compra. En el momento de hacer un pedido es necesario hacer varias consultas, por ejemplo cunto hay en stock, cul fue el precio de la ltima compra, etc. Los siguientes puntos describen los pasos seguidos para el desarrollo de esta aplicacin. Definir el objetivo: No se debe olvidar que los computadores son meras herramientas. Los usuarios de los sistemas tienen objetivos especficos. Ellos esperan que la aplicacin los ayude a alcanzarlos ms rpidamente, ms fcilmente, o a un menor costo. Es parte del trabajo de anlisis el conocer esos propsitos y saber por medio de qu actividades los usuarios quieren alcanzarlos. Este objetivo debe ser expresado en pocas palabras (uno o dos prrafos) y ser conocido por todas las personas involucradas con el sistema. En el ejemplo, algunos de los propsitos posibles son: "El sistema de compras debe disminuir la burocracia existente para la formulacin de un pedido." "El sistema de compras debe asistir a usuarios no entrenados en la formulacin de pedidos de tal manera que su desempeo se asemeje al de un experto." "El sistema de compras debe permitir la disminucin del stock existente en las farmacias." De todos los objetivos posibles se debe elegir uno como el objetivo principal o prioritario. Esto es muy importante para el futuro diseo de la aplicacin. Basta con observar cmo los distintos objetivos anteriores conducen a diseos diferentes. Para nuestro ejemplo elegiremos el primer objetivo, dado que en la situacin real el analista de compras no tena toda la informacin que necesitaba, por lo cual deba consultar una serie de planillas, manuales y llamar por telfono a los empleados del depsito para que realizaran un conteo manual del stock. No se debe confundir el objetivo de la aplicacin (el QUE) con la funcionalidad de la misma (COMO se alcanzar el objetivo). Definir el equipo de trabajo:

6A continuacin se debe definir cul ser el equipo de personas encargado de la implementacin del sistema. Dicho equipo debe tener como mnimo dos personas: El analista de sistemas, y Un usuario.

Los analistas de sistemas que trabajen en el desarrollo de la aplicacin deben cumplir dos condiciones: Haber sido entrenados en el uso de GENEXUS Tener una orientacin a las aplicaciones.

Se recomienda que dichos analistas pasen algn tiempo trabajando con los usuarios en el comienzo del proyecto a los efectos de familiarizarse con los conceptos, vocabulario, problemas existentes, etc. Como una aplicacin con GENEXUS se desarrolla de una manera incremental, es MUY IMPORTANTE la participacin de los usuarios en todas las etapas del desarrollo. Se recomienda tener un usuario principal disponible para la prueba de los prototipos y tener acceso a los dems usuarios de una manera fluida. Dado que con GENEXUS los miembros del equipo estarn la mayor parte del tiempo trabajando en tareas de diseo y no de codificacin, se debe tomar como criterio general el trabajar en equipos PEQUEOS, por ejemplo, de no ms de cinco personas. Obtener una imagen global: Se deben tener entrevistas con el nivel gerencial ms alto posible, de modo de obtener informacin sobre la posicin relativa (e importancia) de la aplicacin dentro de toda la organizacin. Definir el alcance de la aplicacin: Luego de un estudio primario se debe decidir cul ser el alcance de la aplicacin para GENEXUS poder cumplir con el objetivo. Para ello se recomienda seguir el Principio de Esencialidad: "Solo lo imprescindible, pero todo lo imprescindible" En el ejemplo, una vez que una orden de compra es enviada a un proveedor, se debe controlar cmo y cundo se fueron entregando efectivamente los productos. Sin embargo vemos que esto no es imprescindible para cumplir el objetivo de la aplicacin y por lo tanto no ser tratado. Mantener el diseo simple: Se debe planificar pensando en un proceso de diseo y desarrollo incremental. Comenzando por pequeos pasos y verificando la evolucin del modelo frecuentemente con el usuario. Orientarse a los datos: En esencia, una aplicacin es un conjunto de mecanismos para realizar ciertos procesos sobre ciertos datos. Por lo tanto, en el anlisis de la aplicacin, se puede poner mayor nfasis en los procesos o en los datos. En las metodologas tradicionales -como el Anlisis Estructurado- el anlisis se basa en los procesos. En general, este anlisis es Top-Down: se comienza con la definicin ms abstracta de la funcin del sistema, y luego sta se va descomponiendo en funciones cada vez ms simples, hasta llegar a un nivel de abstraccin suficiente como para poder implementarlas directamente. Sin embargo, este enfoque tiene ciertos inconvenientes:

7

Las funciones de un sistema tienden a evolucionar con el tiempo, y por lo tanto, un diseo basado en las funciones ser ms difcil de mantener. La idea de que una aplicacin se puede definir por una nica funcin es muy controvertida en aplicaciones medias o grandes. Frecuentemente se descuida el anlisis de las estructuras de datos. No facilita la integracin de aplicaciones. Si, por el contrario, el diseo se basa en los datos, se pueden obtener las siguientes ventajas: Ms estabilidad. Los datos tienden a ser ms estables que los procesos y en consecuencia la aplicacin ser ms fcil de mantener. Facilidad de integracin con otras aplicaciones. Difcilmente una aplicacin es totalmente independiente de las otras dentro de una organizacin. La mejor forma de integrarlas es tener en cuenta los datos que comparten. Por lo tanto, orientarse a los datos parecera ser ms beneficioso. La pregunta natural que surge es, entonces, cmo analizar los datos. La respuesta de GENEXUS es analizar directamente los datos que el usuario conoce, sin importar como se implementarn en el computador. El diseo comienza -como veremos ms en detalle en el siguiente captulo- estudiando cules son los objetos que el usuario manipula. Para cada uno de estos objetos se define cul es su estructura de datos y posteriormente cul es su comportamiento. De esta manera se alcanzan dos objetivos importantes: el anlisis se concentra en hechos objetivos, y ste puede ser evaluado directamente por los usuarios, utilizando la facilidad de prototipacin de GENEXUS.

8

2. DISEO DE TRANSACCIONESEl anlisis mismo de la aplicacin comienza con la definicin de las transacciones. De cualquier manera es importante tener en cuenta que todo el proceso de desarrollo es incremental y por lo tanto no es necesario definir en esta etapa todas las transacciones y cada una de ellas en su mayor detalle. Por el contrario, lo importante aqu es reconocer las ms relevantes y para cada una de ellas cul es su estructura. Las transacciones permiten definir los objetos de la realidad. Son los objetos GENEXUS que nos permitirn interactivamente, por medio de su pantalla, dar altas, bajas y modificaciones en la base de datos de la aplicacin. Para poder definir cules son las transacciones se recomienda estudiar cules son los objetos (reales o imaginarios) que el usuario manipula. Afortunadamente es posible encontrar la mayor parte de las transacciones a partir de:

La descripcin del sistema. Cuando un usuario describe un sistema se pueden determinar muchas transacciones si se presta atencin a los sustantivos que utiliza. En el ejemplo: Analistas de compras Pedidos Proveedores Artculos Ordenes de Compra Formularios existentes. Por cada formulario que se utilice en el sistema es casi seguro que existir una transaccin para la entrada de los mismos. Para cada transaccin se puede definir: Estructura: De qu atributos (campos) est compuesta y qu relacin tienen entre s. Form GUI-Windows: Cada transaccin contiene un form GUI-Windows (Graphical User Interface Windows) mediante el cual se realizarn las altas, bajas y modificaciones en ambiente Windows. Form Web: Cada transaccin contiene un form Web mediante el cual se realizarn las altas, bajas y modificaciones en ambiente Web. Reglas: Con las reglas definimos el comportamiento particular de las transacciones. Por ejemplo, cules son los valores por defecto de los atributos, cules son los controles en los datos que hay que realizar, etc. Eventos: Las transacciones soportan la programacin orientada a eventos. Este tipo de programacin permite el almacenamiento de cdigo ocioso el cual es activado luego de ciertas acciones - provocadas por el usuario o por el sistema. Subrutinas: Son rutinas locales a la transaccin que se ejecutan al ser invocadas desde la misma. Propiedades: Caractersticas que se pueden configurar para definir el comportamiento general de la transaccin.

9Form Classes: Cada objeto puede tener asociado ms de un form que pertenece a una determinada Form Class. Existen dos Form Classes predefinidas: Graphic y Text. Tpicamente la Form Class Graphic se usa para los ambientes grficos (por ejemplo: Windows) y la form class Text se usa para los ambientes que trabajan en modo texto (por ejemplo: AS/400). Haciendo clic con el botn derecho del mouse sobre el Form de una transaccin, se permite seleccionar un form (de determinada Form Class) de los que se hayan asociado al objeto. Style Asociado: Styles son objetos GENEXUS (su forma de definicin es similar a la de los otros objetos), pero no son tenidos en cuenta en la normalizacin o generacin de programas; slo se utilizan para definir estndares. Ayuda: Texto de ayuda para los usuarios de la transaccin. Documentacin: Texto tcnico (para los analistas) que se incluye para ser utilizado en la documentacin del sistema. Cuando editemos un objeto GENEXUS (tanto transaccin, como cualquier otro objeto GENEXUS de los que iremos estudiando en este libro), podremos acceder a las distintas partes que lo componen utilizando los Tabs que aparecen abajo, en la ventana de edicin del objeto. En el caso de estar editando una transaccin, estos tabs son:

El Tab etiquetado como Web Form est disponible para el caso en el que queramos generar la transaccin para aplicaciones Internet de forma tal de ser ejecutadas desde un Browser. Este tab es para editar el form Web diseado. No profundizaremos en este tema en el presente libro. ESTRUCTURA DE UNA TRANSACCIN: La estructura define qu atributos (campos) integran la transaccin y cmo estn relacionados.

En el ejemplo, la transaccin de Proveedores posee los siguientes atributos: PrvCod: PrvNom: PrvDir: PrvTotPed: Cdigo de proveedor Nombre del proveedor Direccin del proveedor Importe total pedido al proveedor

Que componen la informacin que se quiere tener de un proveedor.

10Atributos: Para cada atributo se debe definir:

Name:

Es el nombre del atributo. Se utiliza para identificarlo.

Description: La Descripcin o ms propiamente Nombre largo es un string que contiene una descripcin ampliada del atributo. Debe ser un identificador global del atributo, que lo identifique bien con independencia del contexto, y principalmente debe ser entendible por el usuario final, ya que es con esta descripcin que l va a interactuar en el GENEXUS Query. Dado que debe ser un identificador global del atributo, no pueden haber dos atributos con la misma descripcin para evitar ambigedad al momento de elegir el atributo (ms bien la descripcin) en el GENEXUS Query. Relacionadas con la Descripcin estn las opciones Title y Column Title que aparecen en el Tab Advanced, que se ilustran en la fig. 4 y que comentamos a continuacin de la misma. Domain: Type: DateTime). Dominio en que se basa el atributo al definirlo. Tipo de datos del atributo (Numrico, alfanumrico, fecha, Long Varchar, Varchar o

El tipo de dato Long Varchar (por Variable Character) permite almacenar una cantidad de caracteres indefinida. Se utiliza normalmente para almacenar textos, por ejemplo: notas, descripciones, comentarios, etc.

11Length: Decimals: Largo del atributo. Nmero de posiciones decimales.

Picture: Formato del campo que permite una visualizacin en la entrada y salida. Por ejemplo: en campos carcter, @! significa que todos los caracteres se aceptan y despliegan automticamente en maysculas. Seleccionando el tab Advanced, como puede verse en la fig.4 aparece una opcin Picture que permite setear cuestiones de formato de la entrada y salida, de acuerdo al tipo de datos del atributo. Value Range: Rango de valores vlidos para el atributo. Por ejemplo: La siguiente definicin: 1:20 30: significa que el valor debe estar entre 1 y 20 o ser mayor que 30. 1 2 3 4 significa que el valor debe ser 1, 2, 3 4. 'S' 'N' significa que el valor debe ser 'S' o 'N'.

En la figura anterior podemos ver que dentro del tab Advanced contamos, entre otras, con las dos opciones: Title: Permite definir el ttulo a utilizar en las estructuras planas de los objetos GENEXUS, como por ejemplo: primer nivel de una transaccin, descripcin de las variables en los prompts (o listas de seleccin, que mencionaremos ms adelante en este captulo), ttulos de reportes generados con el report wizard (lo estudiaremos en el cap. 3). Column Title: Permite definir el ttulo asociado al atributo en las columnas de un subfile (tambin lo veremos ms adelante).

12

Es decir, que estos dos "ttulos" son para definir lo que queremos aparezca en las pantallas default de los objetos GENEXUS. De esta manera se busca ahorrar trabajo ya que, generalmente, los ttulos de los atributos se modifican con cierta frecuencia en los lugares donde aparecen, centralizando dichos cambios en estas propiedades. Por defecto, al crear un nuevo atributo, en caso que no se ingrese informacin en estas propiedades, se hereda la descripcin detallada en la propiedad Description del atributo, mostrando en el Tab Advanced la siguiente informacin para las dos propiedades: Default: Attribute Description (como se ve en la figura para el caso de Title). Si nos adelantamos unas cuantas pginas y observamos la figura 6, vemos que en el form de la transaccin (que es plana) aparece Cdigo proveedor como ttulo del atributo, que es la Description del atributo, que se muestra en la Fig.3. En cambio, para este atributo, PrvCod, hemos modificado la descripcin que aparecer cuando ste se utilice como columna de un subfile. En lugar de tener como descripcin Cdigo proveedor, tendr simplemente Cdigo. Utilizando la opcin (en la ltima columna del dilogo que aparece en la Fig. 4) podemos volver al valor por defecto. Dominios: Es comn cuando estamos definiendo la base de datos, tener atributos que comparten definiciones similares, y para los que no se puede establecer ninguna relacin directa. Por ejemplo, es comn almacenar todos los nombres en atributos de tipo character y largo 25. El uso de dominios permite utilizar definiciones de atributos genricos. Por ejemplo, en la transaccin de proveedores tenemos el nombre, PrvNom, y ms adelante vamos a definir el nombre del analista, entonces podemos definir un dominio Nombres de tipo character con largo 25 y asociarlo a estos atributos. Por lo tanto, si en el futuro cambia la definicin de este dominio, los cambios sern propagados automticamente a los atributos que pertenecen a l. Atributos Clave: Es necesario definir cul es el atributo o conjunto de atributos que identifican a la transaccin, es decir, atributos cuyos valores son nicos. Esto se hace poniendo un * al final del o los atributos, o haciendo botn derecho sobre el atributo y presionando la opcin Set Key que aparece en la ventana popup que se despliega. La siguiente notacin indica que no existen dos proveedores con el mismo Cdigo de Proveedor. PrvCod* PrvNom PrvDir PrvTotPed Es importante notar que el concepto de identificador se refiere a la unicidad (si puede haber o no dos proveedores con el mismo nmero) y no a cmo se debe acceder al archivo donde se almacenan los proveedores. En la ventana donde se edita la estructura, al digitar un * al final de los atributos identificadores, automticamente se marcan con un smbolo de llave, como puede verse en la Fig. 2.

13Con respecto a los identificadores: Toda transaccin debe tener un identificador. Los identificadores tienen valor desde un principio (por ejemplo cuando se crea un proveedor nuevo se debe saber cul ser su PrvCod) No cambian de valor. Por ejemplo al proveedor con cdigo 123 no se lo puede cambiar para 234. En los casos en los cuales no se puede determinar un identificador se debe optar por crear un atributo artificial (no existente en la realidad), cuyo valor sea asignado automticamente por el sistema. Relacin entre la estructura y el modelo de datos: GENEXUS utiliza la estructura de la transaccin para capturar el conocimiento necesario para luego, automticamente, definir cul es el modelo de datos que se necesita. En particular de la estructura anterior GENEXUS infiere que: No existen dos Proveedores con el mismo PrvCod. Para CADA PrvCod existe solo UN valor de PrvNom, PrvDir y PrvTotPed.

Y con esta informacin va construyendo el modelo de datos. En este caso a la transaccin de Proveedores se le asociar la Tabla: PROVEEDORES. Tabla: PROVEEDORES Atributos: PrvCod* (aqu con * indicamos clave primaria) PrvNom PrvDir PrvTotPed Indices: IPROVEEDORES (PrvCod) Indice por Clave Primaria El nombre de la tabla y el del ndice son asignados automticamente, pero luego pueden ser modificados por el analista. Diremos que la transaccin de Proveedores tiene asociada la tabla PROVEEDORES en el entendido que cuando se ingresen (modifiquen o eliminen) datos en la transaccin, stos sern almacenados (modificados o eliminados) en la tabla PROVEEDORES. Otras transacciones simples de nuestro ejemplo son: Analistas: AnlNro* AnlNom Artculos: ArtCod* ArtDsc ArtCnt ArtFchUltCmp ArtPrcUltCmp ArtUnd ArtTam ArtFlgDsp

Nmero de analista Nombre del analista

Cdigo de artculo Descripcin del artculo Cantidad en stock Fecha ltima compra Precio ltima compra Unidad del artculo Tamao Disponibilidad

14Que tendrn asociadas las tablas ANALISTAS y ARTICULOS respectivamente. Tabla: ANALISTAS AnlNro* AnlNom Tabla: ARTICULOS ArtCod* ArtDsc ArtCnt ArtFchUltCmp ArtPrcUltCmp ArtUnd ArtTam ArtFlgDsp A partir de la estructura definida para una transaccin, GENEXUS crea por defecto un form GUIWindows y un form Web, los cuales sern la interfaz con el usuario en ambiente Windows y Web respectivamente. Estos forms pueden ser modificados, para transformar por ejemplo controles de tipo edit, a otros tipos de controles. La edicin del form GUI-Windows se realiza con el Tab Form del objeto. En la figura siguiente mostramos el form definido para la transaccin de artculos:

Los atributos ArtUnd, ArtTam y ArtFlgDsp no aparecen en el form como los atributos convencionales (de edit). ArtUnd lo definimos como un Combo Box, ArtTam como un Radio Button y ArtFlgDsp como un Check Box. Tipos de controles:

15Edit: Normalmente los atributos tienen un rango de valores muy grande, por ejemplo: un nombre, un precio, etc. En estos casos se le permite al usuario entrar el valor del atributo y el sistema se encarga de validarlo. A estos tipos de controles se los llama Edit Box. ArtCod, ArtDsc, etc., en la fig. anterior son ejemplos de controles Edit. Sin embargo, existen atributos que tienen un rango de valores muy pequeo y que pueden ser desplegados de antemano para que el usuario seleccione uno. De esta forma controlamos que ingresen solo valores vlidos. Estos tipos de controles son los que veremos a continuacin: Check Box: Es usado para aquellos atributos que tienen solo dos valores posibles, elegidos por el programador. En nuestro ejemplo, para sealar si existe disponibilidad del artculo, el atributo tomar uno de los valores S o N. Existe una nica descripcin (Disponible) y en caso que este campo est seleccionado, el valor ser el especificado por el programador para este caso (S en nuestro ejemplo) y en caso contrario ser el otro valor especificado (N en el ejemplo). Radio Button: Los Radio Button, en cambio, pueden tener ms de dos valores. Todos los valores se despliegan en el form (en realidad se despliegan sus descripciones, el valor que se almacena es manejado internamente) y solo se puede seleccionar uno. En el ejemplo, el tamao del artculo lo definimos como un Radio Button. Combo Box: Es generalmente usado para aquellos atributos que tienen un rango grande de valores, que hace poco prctico utilizar un Radio Button para su manejo. Se despliega un campo de tipo Edit y presionando un botn que se encuentra a la derecha del campo se despliega una lista con todos los valores vlidos. No es recomendable utilizar este tipo de control como lista de seleccin de atributos que puedan ser ledos de una tabla. Para estos casos se usan los Dynamic Combobox. Dynamic Combobox: Un Dynamic Combobox es un tipo de control similar al Combo Box. La forma de operacin es similar, salvo que los valores desplegados no son estticos (ingresados por el programador como valores fijos) sino que son descripciones ledas de una determinada tabla de la base de datos. List Box: Este tipo de control tiene asociada una coleccin de tems. Cada tem tiene asociado un par . El control da la posibilidad de seleccionar un solo tem a la vez. El atributo o variable toma el valor en el momento que se selecciona el tem. La seleccin se realiza dando clic con el mouse en un tem o con las flechas del teclado. El control List Box puede verse como un Combo Box abierto, es decir, que los valores (items) se muestran desplegados en una lista, siendo la definicin y funcionalidad del List Box totalmente anloga a la del Combo Box. Dynamic List Box: Este tipo de control tiene asociada una coleccin de tems. Cada tem tiene asociado un par . La coleccin de tems se carga desde una tabla de la base de datos en tiempo de ejecucin. En tiempo de diseo se asocian dos atributos al Dynamic List Box, uno al valor que tendr el tem y el otro a la descripcin que ste tomar. Ambos atributos deben pertenecer a la misma tabla. En tiempo de especificacin se determina la tabla desde la cual se traern los valores y las descripciones. Definicin de la transaccin de pedidos: Consideremos ahora la transaccin de Pedidos. El formulario preexistente de pedidos es:

16

Los atributos que integran la transaccin son (dejando momentneamente de lado la informacin de los Artculos del pedido): PedNro* PedFch PrvCod PrvNom AnlNro AnlNom PedTot Nmero del pedido Fecha del pedido

Total del pedido

En donde PedNro es el identificador del mismo. Esta transaccin tiene algunas caractersticas interesantes a destacar: tanto PrvCod y PrvNom, como AnlNro y AnlNom son atributos que estn presentes en otras transacciones. De esta manera estamos indicando que existe una relacin entre los Proveedores y los Pedidos y tambin entre los Analistas y los Pedidos. En particular aqu estamos indicando que un Pedido solo tiene UN Proveedor y solo UN Analista. Se tiene as que la forma de indicar a GENEXUS la relacin entre las distintas transacciones se basa en los nombres de los atributos. Reglas para nombres de atributos: Se debe poner el mismo nombre al mismo atributo, en todas las transacciones en que se encuentre, a no ser que ello no sea posible (es el caso de Subtipos que se estudia en el curso GENEXUS y no ser tratado en este libro). Por ejemplo, al nombre del proveedor se le llama PrvNom tanto en la transaccin de Proveedores como en la de Pedidos. Se deben poner nombres distintos a atributos conceptualmente distintos, aunque tengan dominios iguales. Por ejemplo, el nombre del proveedor y el nombre del analista tienen el mismo dominio (son del tipo Character de largo 25), pero se refieren a datos diferentes, por lo tanto se deben llamar diferente: PrvNom y AnlNom. Integridad referencial en las transacciones: Otra caracterstica a destacar es que cuando se define la estructura de una transaccin NO se est describiendo la estructura de una tabla y SI los datos que se necesitan en la pantalla o en las reglas. Por ejemplo, que en la estructura anterior figure PrvNom no quiere decir que ste se encuentre en la tabla de Pedidos. Lo incluimos en la estructura pues queremos que est presente en la pantalla de Pedidos. La tabla asociada al cabezal del Pedido ser:

17Tabla: PEDIDOS PedNro* PedFch PrvCod AnlNro PedTot Indices: IPEDIDOS (PedNro) IPEDIDOS1 (AnlNro) IPEDIDOS2 (PrvCod) ndice por Clave Primaria ndice por Clave Fornea ndice por Clave Fornea

Observar que PrvNom no se encuentra en la tabla PEDIDOS, diremos que GENEXUS normaliz y que existe una relacin de integridad entre la tabla PROVEEDORES, que tiene a PrvCod como clave primaria, y la PEDIDOS que lo tiene como clave fornea. La relacin, que llamaremos de integridad referencial, es: Para insertar o actualizar un registro en la tabla PEDIDOS debe existir el PrvCod correspondiente en la tabla PROVEEDORES. Cuando se elimina un registro de la tabla PROVEEDORES no debe haber registros con el PrvCod a eliminar en la tabla PEDIDOS. Estos controles de integridad son generados automticamente por GENEXUS y, por ejemplo, en la transaccin de Pedidos, cuando se digita el PrvCod se valida que ste exista en la tabla PROVEEDORES e incluso se genera una pantalla de seleccin que permite visualizar los proveedores existentes y seleccionar el proveedor asociado al pedido. Niveles de una transaccin: Volviendo al ejemplo, para terminar de disear la transaccin de Pedidos se debe definir la informacin sobre los Artculos del pedido. Sin embargo, no es posible definir la estructura de la siguiente manera: PedNro* PedFch PrvCod PrvNom AnlNro AnlNom ArtCod ArtDsc PedCnt PedPre PedImp PedTot

Cantidad pedida Precio pedido Importe por el artculo

Porque esto significara que para cada pedido existe solo UN artculo, lo que no se corresponde con el formulario. La estructura correcta es:

18

Donde el identificador es PedNro y para cada nmero de pedido existe solo una fecha, un cdigo y nombre de proveedor, un nmero y nombre del analista y un solo total, pero existen muchos artculos, cantidades pedidas, precios e importes de la lnea. Los parntesis indican que para cada Pedido existen muchos Artculos. Cada grupo de atributos que se encuentra encerrado por parntesis diremos que pertenece a un NIVEL de la transaccin. Cabe notar que el primer nivel queda implcito y no necesita un juego de parntesis. As, la transaccin de Pedidos tiene dos niveles: PedNro, PedFch, PrvCod, PrvNom, AnlNro, AnlNom y PedTot pertenecen al primer nivel y ArtCod, ArtDsc, PedCnt, PedPre y PedImp pertenecen al segundo nivel. Una transaccin puede tener varios niveles y ellos pueden estar anidados o ser paralelos entre s. Por ejemplo, si el Pedido tiene varias fechas de entrega podemos definir:

Con esta estructura se define que un Pedido tiene muchos Artculos y muchas Entregas, pero no hay relacin directa entre ambas (a no ser el hecho de pertenecer al mismo Pedido). Si por el contrario, las fechas de entrega son por artculo (cada artculo tiene sus fechas de entrega particulares), la estructura correcta es:

19

Para cada nivel de la transaccin se debe definir el (o los) atributo(s) que actan como identificador nico(s). Por ejemplo, en el Pedido se defini que el identificador del segundo nivel es ArtCod, lo cual significa que dentro de cada Pedido no pueden existir dos lneas con el mismo ArtCod. En consecuencia, el siguiente Pedido no se podra ingresar porque existen dos lneas del Pedido con el mismo ArtCod.

Si en cambio, se desea permitir que en un mismo pedido se pueda ingresar un mismo artculo en ms de una lnea, ArtCod no debe ser identificador nico del segundo nivel, sino que se debe definir un atributo PedLinNro (Nmero de Lnea del Pedido) que sea identificador nico del segundo nivel, siendo ArtCod clave fornea:

20

En donde el PedLinNro lo puede digitar el usuario o se puede incluir una regla en la transaccin para que lo haga automticamente (regla Serial que se ver ms adelante). Cada nivel de la transaccin tiene una tabla asociada: Tabla: PEDIDOS PedNro* PedFch PrvCod AnlNro PedTot Tabla: PEDIDOS1 PedNro* PedLinNro* ArtCod PedCnt PedPre PedImp La clave primaria de las tablas asociadas a los niveles subordinados es la concatenacin de los identificadores de los niveles superiores (PedNro) ms los identificadores del nivel (PedLinNro). La eleccin de los identificadores es una tarea importante y que puede simplificar o complicar la implementacin de un sistema. Supongamos, por ejemplo, que en el Pedido no se admite que haya dos lneas con el mismo ArtCod. La forma natural de implementar esto es definiendo a ArtCod como identificador del segundo nivel. Ahora bien, si por alguna razn se defini a PedLinNro como el identificador, ya no tendremos ese control automtico y se debe escribir un Procedimiento para realizarlo. En otras palabras, cuantas ms reglas de la realidad se puedan reflejar en la estructura, menor ser la cantidad de procesos que se deben implementar, ganando as en simplicidad y flexibilidad. Tipos de relacin entre los objetos:

21Muchas veces cuando los usuarios estn describiendo la aplicacin, es comn preguntarles qu tipo de relacin existe entre los distintos objetos. Por ejemplo, cul es la relacin entre los proveedores y los pedidos: Un proveedor tiene muchos pedidos (relacin 1-N). Un pedido tiene un solo proveedor (relacin N-1).

Como ya vimos, la relacin 1-N se puede definir con la estructura:

Vemos que generalmente para cada relacin N-1 habr una relacin simtrica 1-N. En estos casos se debe definir la estructura N-1 y no la 1-N. Observar que el primer diseo representa el primer requerimiento, pero no el segundo, ya que permite que un mismo nmero de pedido est asociado a distintos cdigos de proveedor. El segundo diseo, sin embargo, representa ambos requerimientos, y por tanto es el ms adecuado. Otro caso muy comn es el de las relaciones N-N, por ejemplo entre los Pedidos y los Artculos: Un Pedido tiene muchos Artculos. Un Artculo puede estar en muchos Pedidos.

En este caso las dos estructuras posibles son:

22

Se debe definir solo una de las dos estructuras. En este caso la correcta es la primera, porque el usuario ingresa los Pedidos con sus Artculos y no para cada Artculo qu Pedidos tiene. FORM DE UNA TRANSACCIN: Inicialmente GENEXUS crea un Form GUI Windows por defecto partiendo de los atributos de la misma; luego esta pantalla se puede modificar. Asimismo se pueden agregar o quitar forms (de tipo Text o Graphic) a travs de las opciones Edit/Add New Form o Edit/Select Forms. Por otra parte, se puede asociar un style y aplicarlo. El style se asocia en cada objeto en la ventana de Information del mismo. El Form GUI Windows por defecto para los Proveedores es:

Utilizando esta pantalla el usuario final puede ingresar, modificar y eliminar proveedores. Para ello la pantalla tiene un Modo, que indica cul es la operacin que se est realizando (Insertar, Modificar, Eliminar, Desplegar) y el usuario puede pasarse de un modo a otro sin tener que abandonar la pantalla. GENEXUS genera dos tipos de dilogo para las transacciones: campo a campo (ambiente GUIWindows) y full-screen (ambiente Web). Dilogo campo a campo: En este dilogo, cada vez que un campo es digitado inmediatamente se controla su validez.

23Dilogo full-screen: En este dilogo primero se aceptan todos los campos de la pantalla y luego se realizan todas las validaciones. Barra o Botones de Men: En ambos tipos de dilogo se encuentra disponible una Barra de Men que tiene las opciones para poder visualizar los distintos datos.

Por ejemplo, se puede elegir ver (para luego modificar) el primer proveedor, el siguiente (a partir del que se est mostrando en pantalla), o se puede elegir uno en particular.

Atributos de entrada y atributos de salida: Consideremos nuevamente la transaccin de Pedidos pero sin sus Artculos. La pantalla por defecto es:

Vemos que hay algunos atributos que deben ser digitados (son atributos de entrada), por ejemplo PedNro y PrvCod y otros que no, como ser PrvNom (son atributos de salida). GENEXUS automticamente determina qu atributos son aceptados y de cules solo se muestra su valor, siguiendo las reglas: Solo pueden ser aceptados los atributos que se encuentran en la tabla asociada al nivel (en este caso son los atributos de la tabla PEDIDOS: PedNro, PedFch, PrvCod, AnlNro y PedTot). Los atributos definidos como frmulas no son aceptados. En modo Modificar no se aceptan los identificadores. Los atributos que tienen una regla de Noaccept no son aceptados. Facilidad de Prompt de Seleccin:

24Para los atributos que estn involucrados en la integridad referencial de la tabla base del nivel se genera la facilidad de Prompt que permite visualizar cul es el conjunto de valores vlidos para esos atributos. Por ejemplo, en la transaccin de Pedidos presionando una tecla especial (por defecto F4) se puede visualizar cules son todos los proveedores, con la siguiente pantalla:

En donde se puede seleccionar el proveedor. Observar que en la primera parte de la pantalla se permite digitar el PrvCod, el PrvNom, el PrvDir o el PrvTotPed, para poder posicionarse en la lista de proveedores. Esta lista es un work panel (panel de trabajo) de GENEXUS que a pesar de ser creado automticamente, puede ser modificado como cualquier otro objeto. FORM EDITOR: Para la transaccin de Pedidos (considerando ahora los Artculos del mismo), la pantalla por defecto es:

25Cuando se genera el form por defecto se disea un subfile para el ltimo nivel de la transaccin, en el ejemplo, las lneas del pedido. Trabajando con el form editor se puede transformar esta pantalla en la siguiente, que simula mejor el formulario de pedidos:

Los objetos como las Transacciones o los Work Panels, tienen uno o varios Formularios asociados. A los efectos de permitir modificar los Formularios que GENEXUS automticamente crea por defecto, se provee un Form Editor. Este Form Editor es igual para todos los objetos que tienen Formularios. El Formulario est formado por un marco de ventana (frame) cuyo ttulo es la descripcin de la transaccin. Dentro de ella figurarn los distintos tipos de controles de edicin del Formulario. Form Edition Controls: En un Formulario se definen controles. Un control es un rea del Formulario que tiene una forma y un comportamiento determinado. Existen los siguientes tipos de controles: Atributo: Se utiliza para representar atributos o variables. Texto: Todo fragmento de texto fijo en la pantalla debe colocarse utilizando uno o ms controles de este tipo. Lnea: Con este control se dibujan lneas horizontales o verticales. Recuadro: Permite definir recuadros de distintos tamaos y formas. Subfilo: Permite definir SubFiles. La definicin de los subfiles se ver ms adelante en el captulo de Work Panels (Paneles de trabajo). Botn: Permite definir Botones (tambin llamados Command Buttons). Bitmap: Permite definir bitmaps estticos en la pantalla. Tab: Permite definir varios controles dentro de otro. Un Tab control tiene una o varias Pginas y cada Pgina tiene un Title y un rea til donde se ponen los controles de esa pgina. Solo una de las pginas puede estar activa a la vez y es la que se puede ver, del resto solo se ver

26su ttulo. Esto es til para cuando se quiere dividir los datos ingresados en la transaccin en distintos grupos de modo que las pantallas queden diseadas de forma amigable al usuario (transacciones con muchos atributos). Existen otros controles, como son las Tablas, los Subfile Freestyle, etc., que son utilizados en la edicin de otros forms, como los de los Web Objects, que no sern tratados en este libro. Cada control tiene una serie de propiedades (ancho de lnea, color, color de fondo, font, etc.), que dependen del tipo de control, y cuyos valores pueden fijarse en forma independiente. Paleta de herramientas: Mientras se est editando un Formulario, est disponible la paleta de herramientas, en la forma de una ventana adicional, con los botones que representan los tipos de controles disponibles.

Uso de las Herramientas: Sobre los objetos seleccionados con el puntero vamos a poder realizar varias operaciones: Cambiar el tamao y forma de un control. Edicin de propiedades. Move Forward, Move Back, Move to Front y Move to Back. Estas operaciones nos van a permitir cambiar la capa en que se encuentra un control. Cada control se encuentra en una capa distinta del Formulario, por lo que algunos estn "ms arriba" que otros. Cuando dos objetos se superpongan, el de ms arriba ser visible totalmente, mientras que el otro slo en aquellos puntos en que no se encuentre "tapado". Move, Copy y Delete. Toolbar: El Form Editor Toolbar nos permite ubicar los controles en el form, y copiar el tamao de otros controles ya definidos:

27

Propiedades de los controles: Vamos a ver las principales propiedades de algunos de los controles que podemos insertar en un form. Atributo:

Name: En esta opcin se permite ingresar un nombre al control que se est editando. Este nombre ser usado luego para asociarle propiedades, eventos o mtodos al control. Array Indices: En el caso de utilizarse variables que sean matrices, se habilitan estas opciones, donde se pueden indicar expresiones que definan la fila y la columna. Frame: Se puede indicar que el atributo est rodeado por un marco. Es posible indicar el tipo: None, Single o 3D; el ancho de la/s lnea/s (Width), si se pinta dentro de l o no (Fill) y si el tamao y forma deben determinarse a partir del atributo (Auto Resize). Font: Permite seleccionar el font que se utilizar para el atributo en la pantalla. Control Info: Nos da la posibilidad de seleccionar el tipo de control, y de acuerdo a l, nos pide que seleccionemos otras caractersticas del mismo, as como nos permite seleccionar el Fore Color y el Back Color del control: Control Type: En los Formularios generados el atributo podr asociarse a distintos tipos de controles Windows. Se puede seleccionar uno de los siguientes: Combo Box, Dynamic Combobox, Radio Button, Edit, List Box, Dynamic List Box y Check Box. El botn de Setup permite definir caractersticas propias a cada tipo de control. Fore Color: Este botn es para seleccionar el color con el que se desplegar el valor del atributo y la/s lnea/s del frame, si tuviera. Back Color: Con este botn se puede seleccionar el color con el que se pinta el rea asignada al atributo en la pantalla. Slo tiene efecto si est presente la propiedad Fill.

28

Text: Indica el texto que se quiere insertar en la pantalla. Puede consistir de una o ms lneas. Alignment: El texto puede estar justificado a la izquierda (Left), derecha (Right) o centrado (Center). Resto de las propiedades: Anlogas al control de Atributo.

Recuadro:

29Del combo box se selecciona el tipo del borde del recuadro: single, none (sin borde) o 3D. Para el resto de las propiedades ver la explicacin en el control de Atributo. Lnea: Utiliza el mismo dilogo de edicin de propiedades con la salvedad de que la opcin Fill aparece deshabilitada. Editor de Propiedades, Mtodos y Eventos: A los controles (que tienen nombre asociado) que usamos en los forms se le pueden asociar propiedades, mtodos o eventos, por ejemplo: cambiarle el font a un texto, hacer un texto visible o invisible, deshabilitar un botn, etc. El tipo de propiedades/eventos/mtodos que se pueden asociar a un control dependen del tipo de control. Para acceder al dilogo donde poder asociar propiedades a los controles se usa la opcin de men Insert/Property (Insert/Events e Insert/Methods para los eventos y mtodos respectivamente) cuando se estn editando los eventos, rules o subrutinas de la transaccin. El dilogo que aparece es el siguiente:

FRMULAS: Se dice que un atributo es una frmula si su valor se puede calcular a partir del valor de otros atributos. En el ejemplo, el atributo PedImp de la transaccin de Pedidos se puede calcular a partir de la cantidad pedida, PedCnt y del precio del producto, PedPre: PedImp = PedCnt * PedPre

30En cada transaccin se puede definir qu atributos son frmulas, pero esta definicin es global, es decir, toda vez que se necesite el atributo se calcula la frmula, tanto en transacciones como en los otros objetos GENEXUS (Reportes, Paneles de Trabajo, etc.). Existen distintos tipos de frmulas: Horizontales Verticales De agregacin / seleccin

Frmulas Horizontales: Una frmula horizontal se define como una o varias expresiones aritmticas condicionales. Por ejemplo:

En donde el atributo PedDescuento representar un descuento del 10% si el total del pedido est entre 100 y 1000 y del 20% si es mayor. En cualquier otro caso no hay descuento (en las frmulas con condiciones es saludable definir siempre el OTHERWISE). La expresin puede utilizar los operadores aritmticos (+, -, *, /, ^) y funciones (por ejemplo 'today()' que devuelve la fecha del da), y para los casos en donde el clculo es muy complicado se puede llamar a una rutina que lo realice en vez de usar frmulas: PedDescuento = udp('Pdesc', PedTot); En donde udp es un comando de comunicacin entre objetos GENEXUS, 'Pdesc' es el nombre del procedimiento invocado, PedTot es un parmetro que se enva y PedDescuento es el atributo que recibe el resultado que calcula el procedimiento. El importe del pedido tambin es una frmula horizontal: PedImp = PedCnt * PedPre Vemos que la forma de definirla involucra a dos atributos (PedCnt y PedPre), pero no se indica en qu tablas se encuentran. GENEXUS se encarga de buscar la manera de relacionar PedCnt y PedPre para poder calcular la frmula (en este caso es muy fcil porque PedCnt y PedPre se encuentran en la misma tabla). En los casos en que no es posible relacionar a los atributos GENEXUS da un mensaje de 'No Triggered Actions' en el listado de navegacin, del que hablaremos ms adelante. Ahora bien, cules son los atributos que pueden estar involucrados?. La respuesta es: en una frmula horizontal todos los atributos de los cuales depende la frmula deben estar en la misma tabla extendida que la frmula (ver el concepto de tabla extendida en el anexo sobre Modelos de Datos Relacionales). Cuando se define una frmula horizontal GENEXUS sabe cul es la tabla extendida de la tabla base asociada a la frmula y controla que todos los atributos utilizados se encuentren en ella.

31Frmulas Verticales: Consideremos ahora el Total del Pedido (PedTot): ste se debe calcular sumando los Importes (PedImp) de cada una de las lneas del Pedido. Esta frmula se expresa como: PedTot = SUM( PedImp ) Y es un caso de frmula vertical, que se define como el tipo de frmula en la que los atributos involucrados no se encuentran dentro de la misma tabla extendida que la frmula. En el caso de PedTot, si observamos el modelo de datos (usando el diagrama de tablas de GENEXUS, conocido como diagrama de Bachman):

Tenemos que PedTot est en la tabla PEDIDOS y PedImp en la PEDIDOS1 que es una tabla directamente subordinada a la PEDIDOS. Podemos utilizar tambin el Database Browser de GENEXUS para determinar qu tablas estn subordinadas y superordinadas a PEDIDOS (eligiendo la opcin Subordinated o Superordinated del dilogo del browser, respectivamente):

32

Adems de ver qu tablas tiene subordinadas y superordinadas, podemos consultar la estructura de una tabla, que ndices tiene (composicin de los ndices), frmulas, etc. Existen dos operadores para frmulas verticales: SUM que suma todos los datos y COUNT que cuenta cuntos datos hay. Frmulas y Redundancia: En base a los criterios de normalizacin y dado que por definicin una frmula siempre puede ser calculada, no es necesario que la misma est almacenada y basta Tablas superordinadas a Pedidos con recalcularla cada vez que sea necesario. Sin embargo el hecho de que la frmula no est almacenada puede ocasionar problemas de performance, debido al tiempo que puede demorar el reclculo. Para evitar este inconveniente se puede definir la frmula como REDUNDANTE. En este caso la frmula se almacena en la Base de Datos y no es necesario recalcularla cada vez que se use. Una vez que la frmula es definida como redundante, GENEXUS se encarga de agregar todas las subrutinas de mantenimiento de redundancia a todas las transacciones que utilicen esa frmula. Tenemos entonces que la definicin de frmulas redundantes implica un balance de performance por un lado y almacenamiento y complejidad de los programas generados en otro, que el analista debe decidir. Si bien en teora esta decisin puede ser bastante difcil de tomar, en la prctica vemos que la mayor parte de las frmulas que se definen redundantes son las verticales y pocas veces las horizontales. La razn de esto es que el clculo de las frmulas verticales puede consumir un nmero indeterminado de lecturas. Por ejemplo, para calcular el PedTot se deben leer todas las lneas del pedido, que pueden ser una cantidad bastante grande.

33Frmulas de Frmulas: Una frmula se calcula a partir del valor de otros atributos. Dichos atributos pueden estar almacenados o ser otras frmulas. Por ejemplo, si en la transaccin de Proveedores definimos: PrvTotPed = SUM( PedTot ) Total pedido del proveedor

tenemos que para calcularlo se necesita: PedTot = SUM( PedImp ) que a su vez necesita: PedImp = PedCnt * PedPre Para frmulas de frmulas GENEXUS determina cul es el orden de evaluacin correspondiente: PedIm = PedCnt * PedPre PedTot = SUM( PedImp ) PrvTotPed = SUM( PedTot ) Las frmulas se especifican en la estructura de la transaccin, como se muestra en la siguiente figura:

REGLAS: Para definir el comportamiento de las transacciones se utilizan las REGLAS. Usando reglas se definen valores por defecto, controles, etc. Veremos algunas de las reglas: Default: Se utiliza para definir los valores por defecto de algunos atributos, por ejemplo: default( PedFch, today() );

34El funcionamiento del default vara segn el tipo de dilogo (full-screen o campo a campo). En el dilogo full-screen se asigna el valor por defecto si el usuario no digit nada en el campo. En el dilogo campo a campo primero se asigna el valor por defecto y luego se permite modificarlo. Error: Es la regla para definir los controles que deben cumplir los datos, por ejemplo si queremos que el precio del artculo pedido sea siempre mayor que 100: error( 'El precio debe ser mayor que 100') if PedPre ArtCntMax; Ya que la regla add() modifica ArtCnt y la regla msg() utiliza ese atributo. Esto implica que en la regla msg() se debe preguntar por ArtCnt mayor que ArtCntMax y no por ArtCnt + PedCnt mayor que ArtCntMax. Cada vez que se especifica una transaccin se puede pedir la opcin -"Detailed Navigation"- que lista cul es el orden de evaluacin. En este listado se explicita en qu orden se generarn

37(usualmente decimos se disparan), no solo las reglas, sino tambin las frmulas y lecturas de tablas. Call: CALL es una regla (y a la vez comando) con la cual se permite llamar a otro programa. Este puede ser cualquier otro objeto GENEXUS, por ejemplo, de una transaccin se puede llamar a un reporte o a otra transaccin, o a un programa externo. En el caso de la regla Call es necesario precisar en qu MOMENTO se debe disparar el Call. Por ejemplo, si en la transaccin de Pedidos se quiere llamar a un reporte que imprima el pedido que se acaba de ingresar, se utiliza la regla: call(RImpRec, PedNro) if after( trn ) ; En donde 'RImpRec' es el programa llamado y PedNro es el parmetro que se le pasa. Al tener after(trn), el Call se realizar despus de haber entrado todo el Pedido. El uso de after() no es privativo de la regla Call y puede ser utilizado en otras reglas. Los after() existentes son: Confirm: La regla se dispara despus de haber confirmado los datos del nivel pero antes de haber realizado la actualizacin. Se usa por ejemplo, en algunos casos de numeracin automtica cuando no se quiere utilizar la regla serial para evitar problemas de control de concurrencia. Insert | Update | Delete: Se dispara despus de haber insertado, actualizado o eliminado el registro de la tabla base del nivel. Se usa fundamentalmente para llamar a procesos que realizan actualizaciones. Level: Se dispara despus de haber entrado todos los datos de un nivel. Se usa muchas veces para controles de totales. Por ejemplo, si cuando se entra el cabezal del Pedido se digita un total (llammosle PedTotDig) y se quiere verificar que ste sea igual que el total calculado la regla es: error( 'El total digitado no cierra con el calculado' ) if PedTotDig PedTot and after( level( ArtCod) ); En donde el control recin se realizar cuando se terminaron de entrar todas las lneas del pedido. Trn: Se dispara despus de haber entrado todos los datos de una transaccin. Se usa fundamentalmente para llamar a programas que imprimen los datos, o a otras transacciones. En ambientes con integridad transaccional esta regla se dispara luego que se realiza el commit de la transaccin. PROPIEDADES: En el editor de propiedades de las transacciones se pueden seleccionar configuraciones especficas para definir el comportamiento general del objeto. A continuacin vemos la pantalla para la edicin de las mismas:

38

Por ejemplo se pueden configurar propiedades que estn asociadas con el manejo de la integridad transaccional y con la interface. Podemos indicar si deseamos que la transaccin haga un commit al final; asimismo es posible configurar que no deseamos que se soliciten confirmaciones cada vez que se actualiza un nivel, etc.

39

3. DISEO DE REPORTESCon Reportes se definen los procesos no interactivos de extraccin de datos. Los reportes son listados que pueden emitirse por impresora, visualizarse por pantalla, o seleccionar que la salida sea a un archivo. Es un proceso no interactivo, porque primero se extraen los datos y luego se muestran, no habiendo interaccin con el usuario durante el proceso de extraccin, y es solo de extraccin ya que no se pueden actualizar los datos ledos. Para cada Reporte se debe definir: Informacin: Datos generales del Reporte, por ejemplo nombre, descripcin, etc. Layout: As como las Transacciones tienen una pantalla los Reportes tienen un layout de la Salida Condiciones: Qu condiciones deben cumplir los datos para ser impresos. Reglas Propiedades: Definen aspectos generales del Reporte. Ayuda: Texto para la ayuda a los usuarios en el uso del Reporte. Documentacin: Texto tcnico para ser utilizado en la documentacin del sistema. Layout: En el Layout se define simultneamente la estructura de la navegacin (qu datos se quieren listar y en qu orden) y el formato de la salida. Para ello se utiliza un lenguaje procedural muy simple que describiremos brevemente a continuacin. Comencemos por un Reporte para listar todos los proveedores:

40

En donde tenemos los comandos Header, End, For each y Endfor. Para describir ms fcilmente el funcionamiento de estos comandos veamos el resultado de ejecutar el programa generado correspondiente:

La definicin de reportes se divide en uno o varios bloques. Estos bloques pueden ser de cdigo o de impresin. En los bloques de impresin se disea la salida que posteriormente ser impresa. Cada bloque de impresin puede tener un conjunto de controles (atributos, variables, textos, etc.). Los bloques de impresin (o Print Blocks) tienen asociadas ciertas propiedades, que pueden ser configuradas desde un dilogo que se abre al hacer doble-clic sobre el bloque de impresin, como ser: el tipo de papel, el tipo de letra, etc. El dilogo es el siguiente:

Para el diseo de los bloques de impresin tenemos disponible una paleta de herramientas similar a la de las transacciones:

41

La cual permite insertar atributos, textos, lneas, recuadros, bitmaps y nuevos bloques de impresin. Dentro del reporte, los controles son definidos de la misma forma en que se hace en el editor del form de las Transacciones (tipo de letra, color, tamao, etc.). Todos los bloques de impresin que se encuentren entre los comandos HEADER y END son las lneas que se imprimen en el cabezal de la pgina. Tambin existe el comando FOOTER que permite imprimir un pie de pgina en cada hoja. El comando FOR EACH indica que se consultarn cada uno de los registros de cierta tabla, mostrando la informacin que se indique en el (o los) bloque(s) de impresin. En este caso:

Para cada uno de los proveedores, se imprime su cdigo, nombre y direccin. Comando FOR EACH: Este es, quizs, el comando ms importante en los Reportes, ya que toda la definicin del acceso a la base de datos y la estructura del reporte se realiza solo con este comando. Usando el FOR EACH se define la informacin que se va a leer de la base de datos, pero la forma de hacerlo se basa en nombrar los atributos a utilizar y NUNCA se especifica de qu tablas se deben obtener, ni qu ndices se deben utilizar. Por lo tanto, con este comando se define QUE atributos se necesitan y en qu ORDEN se van a recuperar, y GENEXUS se encarga de encontrar COMO hacerlo. Obviamente esto no siempre es posible, y en estos casos GENEXUS da una serie de mensajes de error indicando porque no se pueden relacionar los atributos involucrados. La razn por la cual no se hace referencia al modelo fsico de datos es para que la especificacin del Reporte sea del ms alto nivel posible, de tal manera que ante cambios en la base de datos la especificacin del mismo se mantenga vlida la mayor parte de las veces. El acceso a la base de datos queda especificado por los atributos que son utilizados dentro de un grupo FOR EACH - ENDFOR. Para ese conjunto de atributos GENEXUS buscar la tabla extendida que los contenga (el concepto de tabla extendida es muy importante y sugerimos repasar su definicin en el Anexo sobre Modelos de Datos Relacionales). Por ejemplo, en el Reporte anterior dentro del FOR EACH - ENDFOR se utilizan los atributos PrvCod, PrvNom y PrvDir, GENEXUS sabe que estos atributos se encuentran en la tabla PROVEEDORES y por lo tanto el comando:

42

es interpretado por GENEXUS como:

Para clarificar el concepto hagamos un Reporte que involucre datos de varias tablas. Por ejemplo, listemos el cabezal de todos los pedidos:

El layout para este listado es:

43

Si recordamos el modelo de datos definido en el captulo Diseo de Transacciones, el Diagrama de Bachman es:

En el listado anterior se requieren datos de las tablas PROVEEDORES (PrvNom), ANALISTAS (AnlNom) y PEDIDOS (PedNro y PedFch). La tabla extendida de PEDIDOS contiene a todos estos atributos y por lo tanto el comando FOR EACH se interpretar como:

Cuando se especifica un Reporte, GENEXUS brinda un listado (que llamaremos Listado de Navegacin) donde se indica cules son las tablas que se estn accediendo. En este caso el listado contiene lo siguiente: AnlNom PrvNom PedFch PedNro Donde la primer tabla representada indica cul es la tabla base de la tabla extendida y las tablas que figuran debajo de sta, e indentadas, indican las tablas 1-N de la misma. Una interpretacin muy prctica de este diagrama es: para la tabla del primer nivel de indentacin se leen muchos registros y para cada tabla del siguiente nivel se lee un solo registro por cada registro ledo en la tabla del primer nivel.

44Orden: En los Reportes anteriores no se tuvo en cuenta en qu orden se deben listar los datos. Cuando no se indica el orden, GENEXUS utiliza como orden el de la clave primaria de la tabla base del For Each (existe una excepcin a esta regla, que ocurre en el caso de tener For Eachs anidados, como se ver en el curso). Observar que en el listado de navegacin representado en la Fig.27, GENEXUS utiliz como orden el de PedNro, es decir, el correspondiente a la clave primaria de la tabla PEDIDOS. Para los casos en donde se quiere definir el orden de los datos de forma explcita se utiliza la clusula ORDER en el comando FOR EACH. Por ejemplo, para listar los pedidos ordenados por cdigo de proveedor, PrvCod:

En este caso el ndice a utilizar ser el IPEDIDOS2 (PrvCod) de la tabla PEDIDOS, que fue definido automticamente por GENEXUS. La navegacin para este reporte es la siguiente:

Si al listado anterior lo queremos ordenar por PedFch:

Como no hay ningn ndice definido en PEDIDOS para PedFch, GENEXUS crear un ndice por PedFch cada vez que se ejecute el Reporte y lo eliminar al finalizar el mismo, y en el Listado de Navegacin indicar que no existe un ndice para satisfacer ese orden, lo que significa que deber crear un ndice temporario.

45

Obviamente este proceso es ms lento si lo comparamos con el listado anterior en donde haba un ndice definido. Dada esta situacin el analista debe tomar una decisin: Crear un ndice de usuario. En este caso el Reporte ser bastante ms eficiente, pero se debe mantener un ndice ms (lo que implica mayor almacenamiento y mayor procesamiento en las transacciones para mantener actualizado el ndice). Dejar el Reporte con el ndice temporario.

No es posible recomendar, a priori, cul de las dos soluciones es la mejor, por lo tanto se debe estudiar, caso por caso, la solucin particular, siendo fundamental la frecuencia con que se ejecutar el Reporte. De cualquier manera si al comienzo no se defini el ndice y posteriormente se decide cambiar y definirlo, alcanza con regenerar el Reporte (sin modificar nada del mismo) y ste pasar a utilizarlo. Los criterios de ordenamiento utilizado por GENEXUS son: Cada grupo FOR EACH puede estar ordenado por CUALQUIER conjunto de atributos pertenecientes a la tabla base del grupo, pero no se puede ordenar por atributos que NO se encuentren en la misma. Por ejemplo el listado anterior no se puede ordenar por PrvNom porque la tabla base del grupo es PEDIDOS que no tiene PrvNom. Si no existe un ndice para el orden elegido, se crea un ndice temporario que se eliminar al finalizar la ejecucin del Reporte. Observar que este proceso es anlogo a realizar un SORT cuando se trabajaba con archivos tradicionales. Condiciones en el FOR EACH: Para restringir los datos que se quieren listar se utiliza la clusula WHERE. Por ejemplo, para listar slo los pedidos de hoy:

Se pueden definir varios WHERE dentro del FOR EACH:

46

Lo que significa que se deben cumplir AMBAS condiciones, es decir, se interpreta como que ambas clusulas estn relacionadas por un AND. Si se quiere utilizar un OR (es decir, se desea que se cumpla alguna de las dos condiciones) se debe utilizar un solo WHERE:

GENEXUS posee una serie de mecanismos para optimizar el Reporte en funcin del orden del FOR EACH y de las condiciones del mismo, pero stas se aplican slo a las condiciones que tienen la siguiente forma:

En muchos casos es necesario ejecutar determinado cdigo cuando en un For Each no se encuentra ningn registro. Para esto se usa el comando WHEN NONE. Es importante aclarar que si se incluyen For Eachs dentro del When None no se infieren Joins ni filtros de ningn tipo con respecto al For each que contiene el When None. Cuando la condicin ha sido optimizada, en el Listado de Navegacin aparece como 'Navigation Filter' y cuando no, como 'Constraint'. Por ejemplo, el listado de navegacin correspondiente a un reporte que contiene:

47

Siendo &today una variable del sistema que contiene la fecha de hoy, es:

El mismo reporte, pero esta vez sin especificar clusula ORDER en el for each:

es:

48Tener en cuenta que cuando la condicin tiene la forma especificada antes, se realizar algn tipo de optimizacin, pero no quiere decir que otras formas no sean vlidas; al contrario, en el WHERE se pueden definir condiciones para atributos que son frmulas, que no se encuentran en la tabla base, etc. Determinacin de la tabla extendida del grupo FOR EACH Resulta importante saber cmo determina GENEXUS la tabla extendida que se debe utilizar. El criterio bsico es: Dado el conjunto de atributos que se encuentran dentro de un grupo FOR EACH - ENDFOR, GENEXUS determina la MINIMA tabla extendida que los contiene. Consideremos nuevamente el listado:

Segn vimos, todos estos atributos se encuentran dentro de la tabla extendida de PEDIDOS, sin embargo, tambin se encuentran dentro de la tabla extendida de PEDIDOS1 (Lneas del pedido), pero la tabla extendida de PEDIDOS est contenida en la de PEDIDOS1 (porque justamente la de PEDIDOS1 contiene a la de PEDIDOS adems de otras tablas), y por lo tanto ser la elegida por GENEXUS. Para que GENEXUS pueda determinar cul es la tabla extendida del grupo FOR EACH debe haber por lo menos un atributo que pertenezca a la tabla base. Por ejemplo, en el Reporte que estamos realizando hay dos atributos pertenecientes a la tabla base PEDIDOS (PedNro y PedFch), si ellos no estuvieran y el listado fuera:

Se podra argumentar que la tabla extendida de PEDIDOS contina siendo vlida, sin embargo por razones de simplicidad GENEXUS en este caso indicar que no hay relacin entre estos dos atributos y ser necesario que se utilice algn atributo de la tabla PEDIDOS para poder generar el Reporte. Tambin puede darse el caso que exista ms de una tabla extendida mnima que contenga a los atributos del grupo FOR EACH - ENDFOR. Ante esta ambigedad GENEXUS escoge la PRIMER tabla extendida que cumpla con las condiciones anteriores. Para resolver estos dos problemas (no hay ningn atributo de la tabla base o hay ms de una tabla extendida mnima posible), se utiliza la clusula DEFINED BY dentro del comando FOR EACH, por ejemplo:

49

En el DEFINED BY se debe hacer referencia a por lo menos un atributo de la tabla base que se quiere. An en los casos en los que no se dan ninguno de los problemas anteriores, se recomienda el uso del DEFINED BY para Reportes ms o menos complejos porque mejora bastante el tiempo de especificacin del Reporte. Reportes con varios FOR EACH For Each anidados Hasta ahora hemos definido reportes en donde exista un solo FOR EACH, pero es posible utilizar ms de un FOR EACH para realizar Reportes ms sofisticados. Supongamos que queremos listar para cada proveedor cules son sus pedidos, por ejemplo:

El layout que se debe definir es (slo se muestran los grupos FOR EACH):

50

Si colapsamos todos los print blocks, queda ms claro cmo se definen los FOR EACH anidados:

51En este Reporte tenemos dos FOR EACH anidados. Si analizamos el primer FOR EACH vemos que utiliza slo los atributos PrvCod y PrvNom y por lo tanto su tabla extendida ser la de la tabla PROVEEDORES. El segundo FOR EACH utiliza los atributos PedNro, PedFch y PedTot por lo que su tabla extendida ser la de PEDIDOS. Pero el segundo FOR EACH se encuentra anidado respecto al primero y a su vez la tabla PEDIDOS est subordinada a PROVEEDORES (por PrvCod) por lo tanto GENEXUS interpretar el Reporte como:

Y as se listarn, para cada registro en la tabla de proveedores, cules son sus pedidos en la tabla de pedidos. Ms formalmente, cuando hay dos FOR EACH anidados, GENEXUS busca cul es la relacin de subordinacin existente entre la tabla base del segundo FOR EACH y la tabla extendida del primer FOR EACH (en el caso anterior la relacin era que la tabla PEDIDOS estaba subordinada a la tabla PROVEEDORES por PrvCod) y establece de esta manera la condicin que deben cumplir los registros del segundo FOR EACH (en el ejemplo: todos los registros de la tabla PEDIDOS con el mismo PrvCod ledo en el primer FOR EACH). Puede darse el caso de que no exista relacin entre ambos FOR EACH, por ejemplo:

La tabla base del primer FOR EACH es la PROVEEDORES (porque los atributos son PrvCod y PrvNom) y la del segundo FOR EACH es la ANALISTAS (porque los atributos son AnlNro y AnlNom) y no existe relacin entre la tabla extendida de PROVEEDORES y la tabla base del for each anidado: ANALISTAS. En este caso GENEXUS hace el producto cartesiano entre los dos FOR EACH, es decir, para cada registro de la tabla PROVEEDORES se imprimirn todos los registros de la tabla ANALISTAS.

52Cortes de Control: Un caso particular de FOR EACH anidados son los llamados cortes de control. Supongamos que queremos listar los pedidos ordenados por fecha:

El layout es:

53La tabla base del primer FOR EACH es PEDIDOS (pues contiene PedFch) y la del segundo FOR EACH tambin (pues contiene PedNro y PrvNom). Este es un caso de corte de control sobre la tabla PEDIDOS y GENEXUS lo indica en el Listado de Navegacin con la palabra BREAK en vez de FOR EACH. Los cortes de control pueden ser de varios niveles. Por ejemplo, si quisiramos listar los pedidos por fecha y dentro de cada fecha por proveedor:

Cuando se definen cortes de control es MUY IMPORTANTE indicar el ORDEN en los FOR EACH ya que es la forma de indicarle a GENEXUS por qu atributos se est realizando el corte de control For Each paralelos: Tambin se pueden definir grupos FOR EACH paralelos, por ejemplo, si se desean listar los proveedores y los analistas en el mismo listado:

54Los listados con FOR EACH paralelos son muy prcticos cuando se quiere hacer listados del tipo Listar toda la Informacin que se tenga sobre un Proveedor, en donde el Layout ser del tipo:

Otros comandos: En el Layout se pueden utilizar otros comandos adems de los ya vistos. Nos limitaremos aqu a ver solo los ms significativos. Definicin de Variables: Antes de describir los comandos en s es bueno detenernos en el concepto de variable. Ya vimos que los datos se almacenan en la base de datos en atributos, pero muchas veces se necesita utilizar variables, que se diferencian de los atributos en que son locales al Reporte y no estn almacenadas en la base de datos. Una Variable es reconocida por GENEXUS por ser un nombre que comienza con &, por ejemplo &Today o &Aux. Existen algunas Variables predefinidas, es decir, que ya tienen un significado propio. Por ejemplo, ya mencionamos a &Today, que es una variable con la fecha de hoy. Otro ejemplo es la variable &Page que indica cul es la pgina que se est imprimiendo. Se deben definir las caractersticas (tipo, largo, decimales, etc.) de las variables que se utilicen en el Reporte, con excepcin de las predefinidas.

55

Las variables se pueden definir tambin en funcin de otros atributos, usando la opcin de Based On. Se recomienda utilizar esta opcin siempre que sea posible. Asignacin: Este comando permite asignar valores a variables. Por ejemplo si queremos mostrar totales en un listado:

56

El layout es:

Comandos de Control: Algunos comandos de control son IF-ELSE-ENDIF y DO WHILE-ENDDO. El comando IF-ELSEENDIF es muy utilizado para impresin condicional, es decir, imprimir una lnea solo cuando se cumple alguna condicin.

57En el ejemplo anterior:

El comando DO WHILE-ENDDO es muy usado para imprimir varias vas, por ejemplo si se quiere imprimir dos vas del Pedido.

Llamadas a otros Programas y a Subrutinas: Con el comando CALL se puede llamar a otro programa, ste puede ser otro programa GENEXUS o un programa externo. El formato del comando es: CALL( Program_name, Parameter1, ..., ParameterN) Donde Program_name es el nombre del programa llamado y Parameter1 a ParameterN son los parmetros que se envan. Estos parmetros pueden ser atributos, variables y constantes. Los parmetros pueden ser actualizados en el programa llamado. Cuando desde un Reporte se llama a otro Reporte, que tambin imprime, es importante pasarle como parmetro la variable predefinida &Line (que contiene el nmero de lnea que se est imprimiendo) para que el Reporte llamado no comience en una pgina nueva. Con el comando DO se llama a una subrutina que se encuentra dentro del mismo Layout. En este caso no son necesarios los parmetros porque estn disponibles para la subrutina los mismos datos (variables) que estn disponibles en el lugar donde se hace el DO.

58

Print if detail: Volvamos al listado de Pedidos por Proveedor:

Recordemos que el primer FOR EACH tena como tabla base PROVEEDORES y el segundo PEDIDOS. Ahora bien, el primer FOR EACH es independiente del segundo y por lo tanto se imprimirn los datos del primer FOR EACH ANTES de determinar si hay datos en el segundo nivel y como consecuencia se van a imprimir TODOS los proveedores, independientemente de si tienen o no pedidos. Si se quiere que SOLO se impriman los proveedores que s tienen pedidos se puede utilizar el comando Print if detail:

59

Este comando define que el FOR EACH en donde se encuentre debe usar como tabla base la misma tabla base del siguiente FOR EACH. En el ejemplo el primer FOR EACH pasar a estar basado en la tabla PEDIDOS y no en la PROVEEDORES y por lo tanto solo se imprimirn los proveedores que tienen pedidos. Se debe tener en cuenta que al pasar a estar los dos FOR EACH basados en la misma tabla base, se est definiendo implcitamente un corte de control. Por lo tanto se DEBE definir explcitamente el ORDEN en el primer FOR EACH. Existen otros comandos como ser EJECT (salta de hoja), NOSKIP, etc. Condiciones: Aqu se definen las condiciones que se quieren imponer a los datos a listar. Es equivalente a la clusula WHERE del comando FOR EACH (incluso tienen la misma sintaxis), con la diferencia que el WHERE se aplica al FOR EACH en el que se encuentra y las condiciones definidas aqu se aplicarn a TODOS los FOR EACH que correspondan. En el Listado de Navegacin se indica a qu FOR EACH se estn aplicando. Muchas veces se requiere que las condiciones no sean con valores fijos, sino que el usuario elija los valores cuando se ejecuta el Reporte. Por ejemplo, si en el Reporte que lista proveedores deseamos que se liste un rango de ellos: PrvCod >= ask( 'Ingrese Proveedor inicial: ' ); PrvCod = &Nom ); Y en la pantalla se debe agregar la variable &Nom:

81

De esta manera, cada vez que el usuario digite algo en &Nom, luego de dar Enter, el cursor quedar posicionado en el primer proveedor con PrvNom mayor o igual al digitado. En los casos de nombres, es muy usual la regla: search( PrvNom LIKE &Nom ); En donde el cursor se posiciona en el primer proveedor cuyo PrvNom contenga a &Nom (en el ejemplo si en &Nom se digit 'X' se posicionar en 'GX Corp.'). Si bien esta regla es muy til para que el usuario avance rpidamente en un SubFile, se debe tener en cuenta que no hay ningn tipo de optimizacin sobre la misma. Si se quieren utilizar los criterios de optimizacin se deben usar las Condiciones. Bitmaps: Los bitmaps son usados usualmente para mejorar la presentacin de las aplicaciones. Se pueden incorporar en los forms de las transacciones, reportes y work panels. GENEXUS provee dos mtodos diferentes para agregar un Bitmap: Fixed Bitmaps: Se puede agregar un Bitmap seleccionando el botn de Bitmap de la paleta de herramientas. De esta forma tenemos que indicar su ubicacin. Agreguemos un logo en el work panel que permite visualizar los datos de un proveedor. El nuevo form se ver de la siguiente forma:

82

En este caso siempre aparecer el mismo Bitmap en el form. Dynamic Bitmaps: Este mtodo tiene como diferencia que el Bitmap lo asignamos a una variable y usando la funcin Loadbitmap podemos cargar el Bitmap que deseemos. Por ejemplo, se puede tener un Bitmap que despliegue la foto de cada proveedor. Definicin de una varible de tipo bitmap:

83En el evento load hay que cargar el bitmap para el proveedor pasado por parmetro. Para poder hacer esto, debemos agregar un atributo, PrvFoto, en la transaccin de proveedores, que contendr la ubicacin del archivo (bmp, gif, jpg, etc.) con la foto a cargar.

En tiempo de ejecucin se ver de la siguiente forma:

Grficas: Grafiquemos el total pedido por Proveedor. Para ello utilizaremos el atributo PrvTotPed que habamos definido en la transaccin de proveedores. En el captulo sobre Diseo de Transacciones vimos que este atributo poda ser definido como una frmula SUM vertical:

84De esta forma estamos definiendo el total Pedido de un proveedor como la suma de todos los totales de los pedidos de ese proveedor. Recordemos que el atributo PedTot haba sido definido, a su vez, como una frmula, que era el resultado de sumar todos los importes de las lneas de los pedidos, siendo cada uno de ellos tambin una frmula. Por lo tanto tenemos disponible este atributo para usarlo en la definicin del work panel:

En este work panel definimos el botn Graficar el cual va a tener asociado el siguiente evento:

De esta manera cuando el usuario presiona el botn de graficar visualizar el total pedido por los proveedores en forma grfica. Vemos a continuacin ejemplos de los tipos de grficos que podemos disear:

85

Properties:

86

Generar como una ventana Popup: Se utiliza para indicar que el Panel de Trabajo debe cargarse como una ventana y no borrar la pantalla anterior. Tiene sentido para ambientes que no tienen interfaces grficas. En el segundo Panel de Trabajo del ejemplo se utiliz esta regla. Dilogos Objeto-Accin: Con el uso de Paneles de Trabajo, se tiene la oportunidad de definir para la aplicacin una arquitectura orientada a dilogos Objeto-Accin. Pero previo a introducir este concepto veamos cul era la forma tradicional. Si observamos una aplicacin desarrollada por los mtodos tradicionales, veremos que cuanto mayor es, ms grande ser el rbols de menes que se tiene para acceder a los programas que efectivamente trabajan con los datos. La arquitectura de este tipo de sistemas normalmente es:

Esta situacin se puede apreciar claramente en los sistemas con muchas consultas. En general, todas estas consultas dependen de un men, pero no se encadena una consulta con las otras. Y al no estar encadenadas, se da la paradoja de que cuanto ms consultas se implementan en el sistema, menos son usadas por el usuario, porque le resulta difcil acordarse de las diferencias entre ellas. Diremos que este tipo de aplicacin tiene un dilogo Accin-Objeto, porque primero se elige la accin a realizar (por ejemplo modificar un proveedor, o listar los pedidos) y luego se elige el objeto al cual aplicar la accin (qu proveedor o los pedidos de qu fecha). Con Paneles de Trabajo se pueden implementar sistemas en donde el dilogo puede ser ObjetoAccin, en el que primero seleccionamos el objeto con el cual vamos a trabajar y luego las acciones que aplicamos al mismo. En este caso la arquitectura ser:

87De esta manera el usuario, una vez que selecciona el tipo de objeto con el que va a trabajar, ya puede utilizar el Panel de Trabajo que le permite seleccionar el objeto en s, y luego, las acciones a aplicar sobre el mismo.

Esta arquitectura permite desarrollar aplicaciones complejas, pero que se mantienen fciles de usar.

88

7. DISEO DE MENUESDISEO DE MENES Este objeto permite definir los diferentes mens de la aplicacin. La definicin de un men es muy fcil, y prcticamente lo nico que se requiere es definir las opciones del mismo. Ejemplo: Men Principal del Sistema de Compras

El men anterior cuando es generado para FoxPro Windows es:

Es un men de seleccin implcita, es decir la opcin se selecciona directamente con el Mouse. El mismo men generado para Visual Basic tiene el siguiente formato:

89

El mismo men generado para el ambiente AS/400 tiene el siguiente formato:

En donde se utiliza la tcnica de seleccin explcita, donde para seleccionar la opcin se debe digitar el nmero de la misma en el campo de seleccin. Los menes generados para AS/400 siguen las especificaciones CUA 89 (Common User Access) de IBM. Call Browser: Este browser despliega todos los objetos que se llaman a travs de los comandos call y udp. Dado un programa podemos ver su rbol de llamadas (a que programas llama) y desde que programas es llamado (eligiendo la opcin Callees o Callers del dilogo del browser). En nuestro ejemplo vamos a ver el rbol de llamadas del men Compras:

90

Desde este browser podemos editar cualquier objeto que aparezca en las listas.

91

8. OBJETOS WEBOBJETOS WEB: Los Objetos Web se utilizan para desarrollar aplicaciones para Internet. Generan cdigo HTML -el cdigo que los navegadores interpretan- pudiendo interactuar con la base de datos, permitindonos de esta forma la generacin de pginas web dinmicas adems de la generacin de pginas estticas. Los Objetos Web los podemos clasificar en: Transacciones con form Web (HTML) y en Web Panels. El desarrollo es inmediato, ya que cualquier usuario GENEXUS va a trabajar con los Objetos Web de la misma forma con la que lo hace con el resto de los objetos GENEXUS, optimizando sus tiempos de desarrollo. No entraremos en detalle en este tema en el presente libro, pero s les daremos una breve descripcin a continuacin. Transacciones: Las Transacciones Web no son un nuevo tipo de objeto GENEXUS, sino un form ms para las transacciones que permiten su ejecucin en navegadores. Para disear el form Web (HTML) de una transaccin, se debe abrir la transaccin y seleccionar la opcin Object/Web Form del men GENEXUS o el tab etiquetado como Web Form. Las Transacciones Web facilitan el diseo de aplicaciones Web porque permiten resolver el ingreso de datos realizando automticamente todos los controles de integridad referencial necesarios. Para ejecucutarlas, slo se requiere un navegador instalado en el cliente. Web Panels: Se puede decir que los objetos web panel y work panel son similares ya que ambos permiten definir consultas interactivas a la base de datos. Son objetos muy flexibles que se prestan para mltiples usos, cuya programacin est dirigida por eventos. De todos modos, hay algunas diferencias entre ellos, causadas principalmente por el esquema de trabajo en Internet. Una particularidad fundamental que diferencia a estos dos objetos es que en los web panels, en tiempo de ejecucin, el resultado de la consulta se formatea en HTML para presentarse en un

navegador.

92

ANEXO A: MODELOS DE DATOS RELACIONALESEl propsito de este Anexo es explicar una serie de conceptos sobre Bases de Datos Relacionales relevantes para el uso de GENEXUS. Un Modelo de Datos est compuesto por: Tablas: En una Base de Datos Relacional la nica forma de almacenar informacin es en Tablas. Una Tabla es una matriz (tiene filas y columnas) con un nombre asociado (ej.: PROVEEDORES). A las columnas les llamaremos Atributos, y a las filas Registros o Tuplas. Por ejemplo, una Tabla de Proveedores:

Una Tabla se diferencia de un archivo convencional porque debe cumplir las siguientes reglas: Todos los atributos representan la misma informacin para cada una de las filas (o registros). Es decir en el atributo PrvNom se almacenan los nombres de los proveedores, y no puede ocurrir que para algunos proveedores en ese atributo se almacene la direccin del mismo. En la prctica esta regla implica que no existen tablas con diferentes tipos de registros. No existen dos registros con exactamente la misma informacin.

El orden de los registros no contiene informacin. Es decir se pueden reordenar los registros sin perder informacin. Clave primaria y Claves candidatas: Dado que no puede haber dos registros con la misma informacin, siempre se puede encontrar en una tabla el atributo o conjunto de atributos cuyos valores no se duplican. Se llama a ese atributo o conjunto de atributos Clave Primaria de la tabla. En realidad pueden existir varios de esos conjuntos, a cada uno de ellos lo llamamos Clave Candidata. Por ejemplo, si sabemos que adems de no haber dos proveedores con el mismo cdigo, tampoco puede haber dos proveedores con el mismo nombre, entonces en la tabla PROVEEDORES tanto PrvCod como PrvNom sern claves candidatas. En una Base de Datos Relacional slo una de las claves candidatas debe ser definida como la Clave Primaria. Tambin se debe respetar la siguiente regla: no deben existir dos tablas con la misma clave primaria.

93Por ejemplo consideremos el siguiente diseo: Tabla: PROVEEDORES Atributos: PrvCod* PrvNom Tabla: PROVDIR Atributos: PrvCod* PrvDir Tanto PROVEEDORES como PROVDIR tienen la misma clave primaria. Esto era relativamente comn cuando el criterio de diseo era separar las actualizaciones (por ejemplo dado que PrvDir cambia ms que PrvNom, entonces es mejor definir un archivo diferente en donde el registro que se modifica es menor, y por lo tanto de mejor performance). Sin embargo en una Base de Datos Relacional el criterio de diseo es diferente (ver seccin de Normalizacin) y es preferible una sola tabla con los tres atributos:

Tabla: PROVEEDORES Atributos: PrvCod* PrvNom PrvDir Integridad Referencial: Son las reglas de consistencia entre los datos de las distintas tablas. Supongamos que nuestro modelo de datos corresponde a la representacin del Sistema de Compras para una cadena de Farmacias, introducido en el captulo 1. En este sistema queremos representar pedidos de artculos a proveedores. Para ello necesitamos una tabla de PEDIDOS, que contendr informacin de los pedidos efectuados por los analistas de compras a los proveedores. Esta tabla podra contener los siguientes atributos: PedNro, PedFch, PrvCod, AnlNro y PedTot para representar el nmero de pedido, su fecha, el proveedor al cul se le realiza el pedido, el analista de compras que resuelve hacer el pedido y el importe total por concepto del pedido, respectivamente. La relacin de esta nueva tabla con la de PROVEEDORES definida anteriormente puede representarse de la siguiente manera:

94

La relacin entre estas dos tablas se determina analizando los atributos que tienen en comn, por ejemplo aqu tenemos que el atributo comn es PrvCod, que es la clave primaria de la tabla PROVEEDORES y se encuentra en la tabla PEDIDOS y, por lo tanto, ambas tablas estn relacionadas y la relacin es 1-N. Con relacin 1-N se indica que un Proveedor tiene varios Pedidos y que un Pedido slo tiene un Proveedor. Tambin es usual decir que la tabla de proveedores est superordinada a la de pedidos, y la de pedidos est subordinada a la de proveedores. Esta relacin implica que los datos de ambas tablas no son independientes y cada vez que se realicen modificaciones en una de las tablas, se deben tener una cuenta los datos de la otra tabla. A estos controles se les llama de integridad referencial y son: Cuando se elimina un registro en la tabla superordinada (PROVEEDORES), no deben existir registros correspondientes en la tabla subordinada (PEDIDOS). Cuando se crean/modifican registros en la tabla subordinada (PEDIDOS), debe existir el registro correspondiente en la tabla superordinada (PROVEEDORES). El atributo PrvCod de la tabla PEDIDOS se dice que es una clave fornea (o externa) de dicha tabla, que referencia a PROVEEDORES, tabla que tiene como clave primaria justamente el atributo de igual nombre. El diagrama anterior se ha inspirado en los conocidos Diagramas de Bachman, y tiene justamente la virtud de explicitar la integridad referencial del modelo de datos. Indices: Son vas de acceso eficientes a las Tablas. Existen cuatro tipos de ndices: Primarios, Forneos, De Usuario, y Temporales.

95El ndice primario de una tabla es el que se define para la Clave Primaria y, por lo tanto, se usa en el control de unicidad de los registros. Por otro lado, la existencia del ndice primario hace posible que se realice el segundo control de integridad referencial, visto en la pgina anterior, en forma eficiente. En el ejemplo visto, la existencia de un ndice por PrvCod en la tabla PROVEEDORES, hace eficiente el chequeo de que cuando se ingresa/modifica un registro en la tabla PEDIDOS, exista uno en la tabla PROVEEDORES tal que el valor del Atributo PrvCod del primer registro coincida con el valor del atributo de igual nombre del segundo registro. Con GENEXUS todos los ndices primarios son definidos automticamente a partir de los identificadores de las transacciones. Los ndices forneos (o extranjeros) son utilizados para hacer eficientes los controles de integridad inter-tablas. Se definen para las claves forneas. Estos son los que hacen posible que se realice eficientemente el primer control de integridad referencial mencionado en la pgina anterior. En el ejemplo, la existencia del ndice forneo por PrvCod en la tabla PEDIDOS, posibilita que eficientemente se chequee y, en base al chequeo, se prohba, eliminar un registro de la tabla PROVEEDORES si existe uno en la tabla PEDIDOS, p