Copyright (c) ARTech Junio1999 Parte I Copyright (c) ARTech Junio1999

Capacitación GeneXus Cursos Iniciales Curso GeneXus: Curso GeneXus Parte I Curso GeneXus Parte II Workshop Cursos Avanzados Curso para Gerentes de Proyectos Cursos Específicos Desarrollo de aplicaciones Client/Server Desarrollo de aplicaciones para Internet Curso Data Warehousing Cursos de Actualización CURSO GENEXUS PARTE I Es indispensable para comenzar a desarrollar Aplicaciones GeneXus. Objetivo : Capacitar a los usuarios para conseguir el cambio de mentalidad que GeneXus requiere y dar elementos básicos para el diseño de Aplicaciones. Alcance : Conceptos fundamentales y elementos básicos. No se abordan todos los temas, algunos de ellos son abordados en el Curso Genexus Parte II. Orientado: A Usuarios que van a desarrollar directamente Aplicaciones usando GeneXus y líderes de Proyecto. Etapas: Este curso consta de 3 etapas:Autoestudio , Curso Teórico/ Práctico y Taller. Aprobación: Este curso es evaluado por los instructores de Artech . La evaluación consiste en la defensa del Taller realizado y el resultado de dicha evaluación (Aprobación /No aprobación) es comunicado a la Empresa. Habilitado a: El alumno que aprueba dicho curso queda habilitado a desarrollar aplicaciones de pequeño y mediano porte, sin embargo es necesario el apoyo que se brinda en el WorkShop. Duración: 76 horas distribuidas en cuatro semanas.

Introducción Teórica

? Herramientas y Metodologías REALIDAD Desarrollo y Mantenimiento BASE Nuestra tarea como profesionales de la informática es desarrollar y mantener aplicaciones para apoyar al usuario en su actividad final. Para realizar esta tarea se han instrumentado diferentes herrramientas y metodologías. Con GeneXus se desarrollan aplicaciones aplicando una metodología que tiene un enfoque muy diferente al de las metodologías mas comunmente utilizadas. Aprender a utilizarlo adecuadamente va más alla de conocer el lenguaje de especificación y lo más importante es el aprendizaje de una nueva metodología de desarrollo. Desarrollo y Mantenimiento aa BASE DE DATOS PROGRAMAS

Modelado de la realidad a partir de las Visiones de Usuarios Satisface MODELO DE LA REALIDAD Ingenieria Inversa El primer problema al que nos enfrentamos en el desarrollo de aplicaciones es la obtención del conocimiento de la realidad. Cómo obtener el conocimiento de la realidad en una forma lo suficientemente objetiva y detallada al mismo tiempo, que nos permita construir un modelo corporativo? Todos compartirán la afirmación de que cada usuario conoce muy bien los objetos con los que trabaja cotidianamente, conoce claramente la información que se maneja en ellos, que reglas deben seguirse y que cálculos deben realizarse. Por lo tanto, utilizar estas visiones de los objetos de su realidad como fuente de información parece muy razonable. Se ha demostrado con mucha rigurosidad que es posible obtener un modelo de datos a partir de la síntesis de visiones, por lo que nuestro problema se ha reducido a un problema matemático ya que si conseguimos describir adecuadamente estas visiones podremos obtener mediante Ingenieria Inversa el modelo de datos. Este método que se conoce como síntesis de visiones canónicas. Este es el punto de partida de la metodología de GeneXus: Describir las visiones de los usuarios para modelar el sistema, y se construirá a partir de este modelo el soporte computacional (base de datos y programas ) para soportarlo. VISIONES DE USUARIOS BASE DE DATOS PROGRAMAS

Comparación de Metodologías Es bueno, para fijar ideas, comparar la metodología utilizada por GeneXus conocida como Metodología Incremental con las metodologías tradicionales más utilizadas actualmente. Algunos de los ejemplos de estas metodologías son: Análisis Estructurado, Ingeniería de la Información, Análisis Escencial. Estas metodologías son diferentes entre sí, pero en todos los casos, separan el análisis de los datos del de los procesos. Veremos un esquema general que podría aplicarse a cualquiera de éstas metodologías y estudiaremos sus problemas.

Metodología Tradicional .

REALIDAD ANALISIS DE DATOS BASE DE DATOS ANALISIS FUNCIONAL La primera tarea, generalmente, es el análisis de datos. Se pretende analizar la empresa y dar como producto un modelo de datos con las Entidades y Relaciones encontradas (Modelo ER). Aquí se analiza la empresa desde el punto de vista de los objetos que existen en ella y sus relaciones. Construir un sistema integrado, que requiere un modelo de datos Corporativo de la empresa no es una tarea simple debido a que el número de objetos y relaciones hacen que esta tarea sea extremadamente compleja. Debido a la complejidad de la construcción de un sistema integrado,lo que se hace normalmente es dividirlo en módulos, y cada uno solucionará los problemas operativos de un área en particular de la empresa. Simplificaremos notablemente la tarea de modelado ya que lo que precisamos normalmente son 10 o a lo sumo 20 archivos para cada modelo. Los módulos operan sin una real integración, lo que hace que exista información redundante y como consecuencia todo intento de buscar información fuera del entorno de cada aplicación resulte imposible o por lo menos peligroso. GENERACION/ INTERPRETACION ESPECIFICACION FUNCIONAL PROGRAMAS PROGRAMACION

Metodología Los fundadores de ARTech han desarrollado una amplia actividad de consultoría internacional en diseño de grandes bases de datos. Cuando se comenzaron a utilizar verdaderos modelos corporativos, que normalmente poseen cientos de tablas, les quedó claro que no debía perderse más tiempo buscando algo que no existe: las bases de datos estables. Luego de importantes investigaciones, desarrollaron una teoría, organizaron una metodología e implementaron una herramienta para posibilitar el desarrollo incremental y permitir la convivencia con las bases de datos reales (inestables), a costo mínimo.

Desarrollo con REALIDAD DESCRIPCION DE OBJETOS Utilizando GENEXUS, la tarea básica del analista es la descripción de la realidad. Sólo el hombre podría desarrollar esta tarea, ya que sólo él puede entender el problema del usuario. Desde luego que esto modifica la actividad del analista e, incluso, su perfil óptimo, ya que lo transforma en un “Business Analyst”. Ahora trabaja en alto nivel, discutiendo problemas con el usuario y probando con él las especificaciones a nivel de prototipo, en vez de desarrollar su actividad a través de tareas de bajo nivel como son: diseñar archivos, normalizar, diseñar programas, programar, buscar y eliminar los errores de los programas.

Desarrollo con REALIDAD DESCRIPCION DE OBJETOS BASE DE BASE DE DATOS CONOCIMIENTO Desarrollo con Al crear un nuevo sistema o proyecto Genexus, se crea una nueva Base de Conocimiento. Una vez creada la nueva Base de Conocimiento, el siguiente paso es empezar a describir los objetos de la realidad mediante objetos Genexus. A partir de los objetos definidos en la Base de Conocimiento, GENEXUS genera automáticamente tanto los programas de creación / reorganización de la base de datos como los programas de la aplicación. El término Base de Conocimiento hace referencia a la capacidad de reutilizar en forma automática el conocimiento almacenado y sobre todo a la capacidad de realizar inferencias que permiten obtener más conocimiento. PROGRAMAS

. REALIDAD Comparación de Metodologías ANALISIS DE DATOS DESCRIPCION DE OBJETOS BASE DE DATOS BASE DE CONOCIMIENTO Comparación de Metodologías . ANALISIS FUNCIONAL GENERACION/ INTERPRETACION Como se ha visto, existen varios caminos para la implementación de aplicaciones: 1. Programación utilizando lenguaje de 3a. generación. 2. Programación utilizando lenguajes de 4a. generación 3. Generación / interpretación automática de la especificación funcional. 4. Desarrollo incremental. La productividad en el desarrollo de aplicaciones aumenta de arriba a abajo. Disminuir en gran forma el mantenimiento de las aplicaciones (datos y programas), sólo se consigue con el desarrollo incremental. ESPECIFICACION FUNCIONAL PROGRAMAS PROGRAMACION

Descripción de Objetos Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs) La primer tarea que hay que realizar es pasar a describir los objetos de la realidad, mediante objetos Genexus. Para ello existen 5 objetos básicos: TRANSACCIONES Las transacciones permiten definir los objetos de la realidad. La mayor parte de las transacciones pueden ser identificadas prestando atención a las entidades que el usuario menciona (por ej. Clientes, Proveedores, Artículos). A partir de las transacciones Genexus infiere el diseño de la base de datos. PROCEDIMIENTOS Procesos no interactivos de actualización de la base de datos (procesos batch). REPORTES Recuperan información a partir de los datos almacenados y no los alteran. Los reportes son lo que conocemos habitualmente como listados. PANELES DE TRABAJO Permite definir consultas interactivas a la base de datos. Es un objeto muy flexible que se presta para múltiples usos. MENUES Objetos organizadores del resto.

Sistematización del conocimiento Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs) Base de Conocimiento Veamos ahora con más detalle el proceso de desarrollo de una aplicación con GeneXus. GeneXus captura el conocimiento que reside en los objetos descritos y lo sistematiza en una base de conocimiento. GENEXUS funciona basado en su capacidad de inferencia. Así infiere, por ejemplo: En el modelo de datos: las tablas, las restricciones de integridad y los índices necesarios. Los programas de creación y/o de reorganización de la base de datos. Los programas de la aplicación. Los análisis de impacto de los cambios.

Inferencia de la Base de Datos Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs) Base de Conocimiento Base de Datos A partir del conocimiento especificado a través de las transacciones, GENEXUS diseña el modelo de datos normalizado (en 3a. forma normal).

Creación de la Base de Datos Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs) Base de Conocimiento GENEXUS genera automáticamente los programas necesarios para crear la base de datos, y la crea mediante ellos. Base de Datos Programas Generación BD

Generación de los Programas de la Aplicación Programas de Aplicacion Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs) Base de Conocimiento GENEXUS genera automáticamente, a partir de la Base de Conocimiento, los programas de la aplicación. Base de Datos Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)

Programas de Aplicacion Resultado final en la Etapa de Desarrollo Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs) Base de Conocimiento En este estado , la aplicación está pronta. Base de Datos Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU) Aplicaciones

Programas de Aplicacion Las Visiones de los Usuarios Cambian Nuevas Transacciones Nuevos Reportes Procedimientos Work Panels Menues Base de Conocimiento Como se ha dicho, durante el ciclo de vida de la aplicación, existen muchas modificaciones. Ante cambios en las visiones de usuarios, GENEXUS diseña la nueva base de datos. Base de Datos Nueva Base de Datos Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)

Programas de Aplicacion Análisis de Impacto Totalmente Automático Nuevas Transacciones Nuevos Reportes Procedimientos Work Panels Menues Base de Conocimiento Análisis de impacto Algunas veces, la nueva base de datos coincide con la anterior, en cuyo caso, todos los programas existentes seguirán siendo válidos. Otras veces, existen cambios en la base de datos. El análisis de impacto de los cambios nos informa si debe reorganizarse la base de datos, cómo debe ser hecha esa reorganización y, los eventuales problemas que esa reorganización podría ocasionar. Una vez analizado el análisis de impacto, el analista resolverá efectuar la reorganización o renunciar a ella volviendo a la situación anterior. Base de Datos Nueva Base de Datos Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)

Programas de Aplicacion Generación de Programas de Reorganización de la Base de Datos Nuevas Transacciones Nuevos Reportes Procedimientos Work Panels Menues Base de Conocimiento Programas de Reorganiz. Si el analista ha dado el visto bueno a la reorganización, GENEXUS genera automáticamente los programas necesarios para esa reorganización. GENEXUS, considerando la base de conocimientos nueva y la vieja, estudia el impacto de los cambios sobre los programas actuales y produce un informe sobre el tema. La reorganización consiste entonces, en ejecutar esos programas. En realidad es de esperar que tengan muchas tablas comunes, que no se modificarán en la reorganización. Base de Datos Nueva Base de Datos Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)

Programas de Aplicacion Análisis Automático del Impacto de los cambios sobre los Programas Nuevas Transacciones Nuevos Reportes Procedimientos Work Panels Menues Base de Conocimiento Análisis de impacto Nuevos Programas de Aplicacion Nueva Base de Datos (TRN, RPT, PROC, WKP y MNU)

Programas de Aplicacion Generación Automática de Nuevos programas Nuevas Transacciones Nuevos Reportes Procedimientos Work Panels Menues Base de Conocimiento Generación de nuevos Programas GENEXUS genera /regenera automáticamente los programas necesarios. Nuevos Programas de Aplicacion Nueva Base de Datos (TRN, RPT, PROC, WKP y MNU)

Programas de Aplicacion Nueva Realidad , con los cambios en la Aplicación Nuevas Transacciones Nuevos Reportes Procedimientos Work Panels Menues Base de Conocimiento Ahora se tienen las nuevas aplicaciones. El ciclo de mantenimiento está completo. Nuevos Programas de Aplicacion Nueva Base de Datos (TRN, RPT, PROC, WKP y MNU) Aplicaciones

Múltiples Plataformas de ejecución a partir de una única especificación ARQUITECTURAS CENTRALIZADAS Plataforma Lenguaje Generado AS/400 COBOL/400, RPG/400 ARQUITECTURAS FILE SERVER DOS Foxpro, Clipper DBF WINDOWS Foxpro for Windows DBF Visual Basic ACCESS Visual Fox DBF ARQUITECTURA CLIENT/SERVER Cliente Database Server Plataformas (Ejs.) FOXPRO FOR WIN, VB, VFP ORACLE Unix, NT MS SQL SERVER Alfa, WINDOWS NT y 95 INFORMIX Unix, NT DB2 Common Servers RS6000, OS2 DB2/400 AS400

Metodología Incremental Consiste en construir una aplicación mediante aproximaciones sucesivas. La construcción automática de la Base de Datos y programas a partir de una única fuente de especificación permitirá a GENEXUS aplicar una metodología de desarrollo que podríamos llamar “Metodología Incremental”, ya que el proceso se realiza mediante aproximaciones sucesivas. En cada momento desarrollamos la aplicación con el conocimiento que tenemos y luego cuando pasamos a tener más (o simplemente diferente) conocimiento, GENEXUS se ocupará de hacer automáticamente todas las adaptaciones en la base de datos y programas. El incrementar una aplicación implica cambios en la base de datos y programas. Los cambios en la base de datos pueden tener un costo aceptable, pero el alto costo de las adaptaciones de los programas harían inviable la aplicación de este método si no fueran resueltos automáticamente. DEFINICION INICIAL

Ciclos Diseño-Prototipo y Diseño-Producción Diseño Prototipo El trabajo consiste de dos ciclos: el Ciclo de Prototipación y el Ciclo de Producción. Ciclo de Prototipación: El diseñador recorrerá repetidamente el bucle Diseño-Prototipo durante la fase de diseño, construyendo y probando sucesivos prototipos del modelo. Ciclo de Producción: Por el contrario, pasará menos frecuentemente al bucle de Diseño-Producción, ya que la generación del sistema se realiza solamente cuando el prototipo ha sido totalmente aprobado, o luego de haber instrumentado y probado algún cambio. Producción

Prototipación Integral en PC MODELO DE LA REALIDAD Construcción Automática Usuario probando todos los detalles de la aplicación BASE DE DATOS La construcción automática del soporte computacional nos dará la gran posiblidad de crear prototipos. Verdaderos prototipos ! , ya que estos tendrán un funcionamiento equivalente al del sistema en producción real, permitiendo que se pruebe hasta el último detalle de la aplicación. Los resultados que todos quieren ver, están en forma de programas ejecutando, lo que no es posible sin la utilización de prototipos. PROGRAMAS

Ventajas de la Prototipación Permite ver resultados en forma temprana Permite el seguimiento de los requerimientos del usuario Detección de errores en forma temprana Logra el compromiso de los usuarios con el desarrollo Sistemas de mejor calidad Toda comunicación es suceptible de errores: El usuario olvida ciertos detalles. El analista no toma nota de algunos elementos. El usuario se equivoca en algunas apreciaciones. El analista interpreta mal algunas explicaciones del usuario. Pero, además, la implementación del sistemas es, habitualmente,una tarea que insume bastante tiempo. Como muchos de estos problemas sólo son detectados en las pruebas finales del sistema, el costo (tiempo y dinero) de solucionarlos es muy grande y la realidad cambia, por lo que no es razonable pensar que se pueden mantener las especificaciones mientras se implementa el sistema. La consecuencia de mantener las especificaciones, es que se acaba implementando una solución relativamente insatisfactoria. El impacto de estos problemas disminuiría mucho si se consiguiera probar cada especificación, inmediatamente, y saber cual es la repercusión de cada cambio sobre el resto del sistema.Una primera aproximación a esto, ofrecida por diversos sistemas, es la posibilidad de mostrar al usuario formatos de pantallas, informes, etc. animados por menúes. Esto permite ayudar al usuario a tener una idea de qué sistema se le construirá pero, al final, siempre se presentan sorpresas.

Warnier-Orr Nro de Factura Nro de Cliente Nombre Cliente Fecha Factura Comienzo Emisión del cabezal Comienzo Emisión de la Factura Emisión de una Factura (cuerpo) Código Producto Nombre Producto Precio Producto Cantidad Producto Importe Producto Ahora vamos a concentrarnos en cuál es la forma práctica utilizada por GeneXus, para la captura de la realidad de la que tanto hablamos. Jean Dominique Warnier y Ken Orr, formularon una teoría acerca de cómo puede ser construida una aplicación de procesamiento de datos. Algunos de sus enunciados fueron los siguientes: Los datos y los procesos están estructurados. Todos los procesos son subdivididos en subconjuntos partiendo del nivel más alto y empleando reglas de subdivisión adecuadas (de manera jerárquica). Todo Proceso tiene un Comienzo, un Cuerpo, y un Final. Esta regla se aplica a la organización de datos y resultados. Analicemos por ejemplo un proceso de emisión de las Facturas de una empresa: Tenemos en este proceso 5 niveles, distinguiendo en cada nivel, los conjuntos repetitivos de lo que está presente una sola vez. Vemos que la gestión jerárquica de los datos hace aparecer relaciones entre los conjuntos definidos en los distintos niveles. Existe entonces una ley de correspondencia: Un elemento de un conjunto de un nivel inferior, se corresponde con uno del nivel superior, si esta incluído en él. Todo conjunto de nivel inferior se llama Conjunto de Partida y todo conjunto de nivel superior se llama Conjunto de Llegada. En el momento de jerarquizar procesos y datos, sería muy bueno que obtuviera este tipo de relaciones. El no observar esta ley es fuente de confusión, eliminando la claridad y la simplicidad de la organización de los datos tanto como la de los procesos. Proceso de emisión de líneas Emisión de una línea Fin Fin Fin

DISEÑO DE TRANSACCIONES

Notación GeneXus para Transacciones Ejemplo: Proceso de Emisión de Facturas FacNro* Código de la factura CliCod Código del cliente CliNom Nombre del cliente FacFch Fecha de la factura (ProdCod* Código del producto ProdNom Nombre del producto ProdPre ) Precio del producto El siguiente paso es encontrar una forma de notación adecuada para GeneXus. Por ejemplo, una transacción de emisión de Facturas tendrá la siguiente notación. Cada nivel definirá un conjunto de atributos que deben operar en conjunto. Se ingresarán , eliminarán o modificarán conjuntamente en la base de datos. Precisamos entonces encontrar un conjunto de atributos que actúe como identificador de cada instancia de este conjunto. Notaremos a estos atributos con un asterisco. Este es en definitiva el concepto de clave primaria por lo que en la elección de estos atributos debemos atender a todas las reglas correspondientes a su definición. El conjunto de atributos entre paréntesis representa la ocurrencia de varios para cada instancia del nivel anterior. En el ejemplo, una factura tiene varios productos.

Definición del diseño de Base de Datos en 3era Forma Normal para soportar las transaccciones definidas. TRN. FACTURA TABLAS FacNro* Factura CliCod FacNro* CliNom CliCod FacFch CliNom (ProdCod* FacFch ProdNom ProdPre Factura1 FacLinCnt FacNro* FacLinImp) ProdCod* ProdPre FacLinCnt FacLinImp Veamos el proceso de obtención de una base de datos en 3era. forma normal a partir de las especificaciones de transacciones. Para esto utilizaremos como ayuda las dependencias funcionales que se derivarían de la definición de la transacción. La definición de esta primera transacción a determinado las siguientes dependencias funcionales. FacNro ----> CliCod FacNro ----> CliNom FacNro ----> FacFch Por lo que se definirá una tabla con el siguiente diseño FacNro* CliCod CliNom FacFch Tenemos además las siguientes dependencias funcionales determinadas por el 2do nivel de la transacción. FacNro, ProdCod ----> ProdNom FacNro, ProdCod ----> ProdPre FacNro, ProdCod ----> FacLinCnt FacNro, ProdCod ----> FacLinImp Que definirán una tabla con el siguiente diseño FacNro * ProdCod* ProdNom ProdPre FacLinCnt FacLinImp

Definición de las transacciones Clientes y Productos Trn. Clientes CliCod* CliNom Trn. Productos ProdCod* ProdNom ProdPre Clientes CliCod* CliNom Producto ProdCod* ProdNom ProdPre Factura FacNro* CliCod FacFch Factura1 FacLinCnt FacLinImp La definición de dos nuevas transacciones: Clientes y Productos han determinado la aparición de nuevas dependencias funcionales. GeneXus diseñará las nuevas tablas que correspondan ( Clientes y Producto ) y realizará las modificaciones necesarias en las ya existentes ( Factura y Factura1 ) para considerar el conjunto total de dependencias funcionales. CliCod ----> CliNom ProdCod ----> ProdNom, ProdPre La siguiente dependencia funcional FacNro ----> CliNom se ha vuelto transitiva a partir de la existencia de las dep. func. FacNro ----> CliCod Por lo que deberá modificarse la tabla Factura. Análogamente con la tabla Factura1 y las dependencias funcionales FacNro, ProdCod ----> ProdNom, ProdPre ProdCod ----> ProdNom, ProdPre

GeneXus establece las relaciones por los nombres. Todo lo que es conceptualmente lo mismo, debe tener el mismo nombre. Transacciones: Factura Cliente FacNro* CliCod SI CliCod* CliNom CliNom .......... ........... Factura Cliente CliFacCod NO CliCod * Conceptos diferentes no deben tener el mismo nombre. Ventas Compras FctVtaNro* FctCmpNro* Fecha NO Fecha CliCod PrvCod CliNom PrvNom

Es conveniente usar padrones para los nombres de atributos. Facilitan la tarea de darle nombre a un atributo dentro de las reglas establecidas Facilitan la tarea de integración de bases de conocimiento

Nomenclatura GIK - Nombre del Atributo Complemento (texto libre) Calificador (1 a 3) Calificador (1 a 3) ARTech ha definido un Standard para la nomenclatura de atributos, el GIK (GeneXus Incremental Knowledge Base). Puede gustarnos más o menos que otros. Lo importante es que es el utilizado por la comunidad de usuarios GeneXus. Esto viabiliza reutilización de conocimiento entre ellos. Nombre de atributo> Objeto + Categoría + Calificador Objeto, Es el nombre de la transacción a la que pertenece el atributo. Categoría, Es la categoría semántica del atributo. Calificador, Puede existir uno o dos calificadores. Categoría Semántica (1 a 3) Objeto ( 1 a 6 )

Ejemplo de Nomenclatura GIK Objetos Categorias Calificador Cli FacVta FacCmp Cod Nom Fch Nro Ini Fin

Tipos de Datos Numeric, Character, Date Long Varchar VarChar DateTime Equivalente al Character, salvo en la forma en que se almacena en la BD. DateTime Los valores de M y N no afectan la forma de almacenar el tipo de datos, sino la forma de aceptar o mostrar su contenido. Long Varchar Permite almacenar una cantidad de caracteres indefinida. Se utiliza normalmente para almacenar textos, descripciones, comentarios, etc. El largo que se le asigna es considerado el largo máximo (la implementación depende de la plataforma). VarChar Permiten almacenar texto de largo variable. Su función, en contraposición al character, es la de optimizar el almacenamiento en la base de datos. Definición: Varchar(M, N) M es el largo máximo posible que dependerá del DBMS. Si el largo asignado al atributo es mayor que el soportado por el DBMS se utilizará el máximo soportado. N es el largo promedio. Se utiliza para optimizar los accesos a disco en algunos DBMSs . La idea es que si el valor de un atributo varchar es menor o igual que N, se almacenan N caracteres (rellenados con blancos) en el registro del archivo y se utiliza un único acceso a disco para leerlo o grabarlo.

Dominios Cuando debemos usar dominios? Atributos con la misma definición No existe relación entre ellos Ejemplo: Dirección Char 30 Dirección del Cliente Dirección del Banco Dominio El objetivo de los dominios es permitir usar definiciones de atributos genéricos y luego poder asociar un atributo con su correspondiente dominio. En el ejemplo, el dominio Dirección es definido como Char de 30. Los atributos dirección del banco y del cliente son asociados a él. Por lo tanto, si en el futuro se cambia la definición de este dominio, los cambios van a ser automáticamente propagados a todos los atributos que pertenezcan a éste. De esta forma los dominios pemiten un mayor nivel de abstracción en la definición de la aplicación. Atributos

Reglas Se utilizan para definir el comportamiento de las transacciones. Algunas reglas Default, Error, Ask, Msg, Asignación, Add, Subtract, etc. Default(FacFch, &today); Error(‘No se permiten clientes sin nombre’) if null(CliNom); Pueden incluir: atributos, variables, constantes y funciones. Las reglas son LOCALES a la transacción. Programación DECLARATIVA Según el Análisis Orientado a Objetos, para cada objeto del sistema se debe definir cual es su estructura y su COMPORTAMIENTO. En el caso de las Transacciones, el comportamiento se define mediante el uso de Reglas (Rules). Algunas reglas: Default - Se utiliza para definir los valores por defecto de algunos atributos. Error - Es para definir los controles que deben cumplir los datos, por ejemplo si no queremos permitir que queden ingresados clientes sin nombre: Error(‘No se permiten clientes sin nombre’)if null(CliNom); Cuando se cumple la condición ( null(CliNom) ) se despliega el mensaje (‘No se permiten clientes sin nombre’) en pantalla y no se permite continuar hasta que el usuario ingrese un nombre sobre el campo CliNom. Asignacion - Dentro de las reglas de la transaccion se permiten definir asignaciones a atributos, dicha asignacion implica una actualizacion en la tabla base del nivel o en alguna de las tablas que pertenecen a la tabla extendida del nivel. Una asignacion en las reglas es LOCAL (vale solo para la transaccion en la cual fue definida). Orden de evaluación La definición de reglas es una forma DECLARATIVA de definir el comportamiento de la transacción. El orden en el cual fueron definidas no necesariamente indica que ese sea el orden en que se encuentran en el programa generado. GeneXus se encarga de determinar el orden correcto según las dependencias de atributos existentes (en este tema entraremos en detalle mas adelante).

Tool Bars de Controles Usados en el diseño de Pantallas Atributo / Variable Texto Línea Recuadro Subfile Botón Bitmap Tab Control Print Block Se utiliza para diseñar la pantalla (form) en forma gráfica. Mientras se está diseñando un form (de TRN’s, WKP’s o Reports) está disponible la tool bars de Controles que contiene los tipos de controles que se pueden agregar al form que se está editando. 12 12 12 16 12

Tab Control Permite definir varios controles dentro de un Tab Control. Tiene una o varias páginas. Default: Dos páginas Agregar o eliminar páginas: Botón derecho sobre el Tab Control Página Título Area útil Check Box de Hide Tabs ==> Para diseño de Wizards Sólo para los generadores visuales. Un Tab Control tiene una o varias páginas (por defecto tiene dos). Cada página tiene un título y un área útil, es decir donde se ponen los controles de esa página. Sólo una de las páginas puede estar activa a la vez y es la que se puede ver. Del resto sólo se verá su título. Las opciones Edit/Add Tab Page y Edit/Remove Tab Page son para agregar y eliminar páginas respectivamente. Puede accederse también a estas opciones con botón derecho sobre el Tab Control. Hide Tabs Para mostrar sólo la página activa y no mostrar los tabs. Util para la definición de Wizards.

Generación de HELP Tipo Windows Es necesario generar y compilar el Help. Opción: Build/Generate Help El compilador viene con el Visual Basic/Foxpro/Visual FoxPro Disponible solamente en los generadores windows. Esto es para los generadores Windows. Se genera un .HLP compatible con el Help de Windows. El compilador de Help como se mencionó más arriba viene con el Visual Basic/Foxpro/Visual FoxPro y se requiere como mínimo la versión 3.10.505. 62

Generación de HELP Tipo Windows Botón de Help: Llama al help del objeto. F1: Llama al help del atributo en donde se encuentra el cursor. Si ese atributo no tiene help se llama al help del objeto.

INTEGRIDAD REFERENCIAL

Diagrama de Bachman Catego Depart Client DtoCod* DtoNom CliCod* CliNom CatCod* CatNom DtoCod* DtoNom Client CliCod* CliNom CatCod DtoCod Las reglas de integridad referencial permiten asegurar la consistencia entre los datos de las distintas tablas. El diagrama anterior se ha inspirado en los conocidos Diagramas de Bachman, y tiene la virtud de explicitar la integridad referencial del modelo de datos. En el ejemplo, existe una relación entre la tabla Clientes y Departamentos y también entre Clientes y Categorías. La relación entre dos tablas se determina analizando los atributos que tienen en común. Por ejemplo, entre las tablas Clientes y Categorías tenemos que el atributo común es el código de la categoría, que es la clave primaria de la tabla Categoría. Decimos que la relación entre ambas tablas es 1-N, que indica que un cliente tiene una categoría y una categoría tiene N clientes. También es usual decir: . La tabla Categorías está Superordinada a la tabla de Clientes . La tabla de Clientes está Subordinada a la tabla de Categorías Esta relación implica que la información contenida en ambas tablas no es independiente, por lo que es neceario realizar controles para que la información sea consistente. A estos controles se les llama de Integridad Referencial y básicamente son los siguientes: * Cuando se crean registros en la tabla subordinada (Client), debe existir el registro correspondiente en la tabla superordinada (Catego). * Cuando se elimina un registro en la tabla superordinada (Catego), no deben existir registros correspondientes en la tabla subordinada (Client).

Definición de Indices Tabla Indice Tipo Composición Catego PK CatCod Depart PK DtoCod Client PK CliCod FK DtoCod FK CatCod Definición de Indices Para hacer eficiente los controles de Integridad, GeneXus crea automáticamente índices, que son vías de acceso eficientes a las Tablas. Existen tres tipos de índices: Primarios, Extranjeros y del Usuario. Indice Primario (PK) : El índice primario es el que se define para la Clave Primaria, se utiliza para el control de unicidad de los registros y para el control de que cuando se crean registros en la tabla subordinada (Client), debe existir el registro correspondiente en la tabla superordinada (Catego). Con GeneXus todos los índices primarios son definidos automáticamente a partir de los identificadores de las transacciones. Indice Extranjero (FK): Los índices extranjeros son utilizados para hacer eficientes los controles de integridad inter-tablas. También son definidos automáticamente. Cuando se elimina un registro en la tabla superordinada (Catego), no deben existir registros correspondientes en la tabla subordinada (Client). Indice del Usuario: Los índices del usuario se definen, fundamentalmente, para recorrer los datos por determinado orden de una forma eficiente. Por ejemplo, en la tabla Client se puede definir un índice por CliNom, que es muy útil para los listados ordenados por nombre. Los índices del usuario NO son definidos automáticamente ya que no se usan para los controles de integridad. En una Base de Datos Relacional los índices se utilizan sólo por problemas de performance, pero siempre es posible acceder a los datos de la tabla por cualquiera de los atributos de la misma.

CONCEPTO DE TABLA EXTENDIDA

Tabla Extendida Definición Dada una tabla de la base de datos, se denomina tabla extendida de la misma al conjunto de atributos conformado por: Atributos que pertenecen a la tabla. Atributos que tengan una relación N-1 con la tabla extendida determinada hasta el momento. Los criterios de normalización del diseño de la base de datos apuntan a minimizar la posibilidad de inconsistencia en los datos. Una base de datos diseñada de esta manera tiene una serie de ventajas importantes (tal es así que actualmente la normalización de datos es un standard de diseño) , pero se deben tener en cuenta también algunos inconvenientes. El inconveniente más notorio es que los datos se encuentran dispersos en muchas tablas, y por lo tanto cuando se quieren hacer consultas más o menos complejas a la base de datos se debe consultar una cantidad importante de tablas. Así, por ejemplo, para listar las facturas sería necesario consultar las tablas Cabezal y líneas de Facturas, Clientes, Categorías y Productos. Para simplificar esta tarea GeneXus utiliza el concepto de tabla extendida.

Tabla Base y Tabla Extendida FACTURA CLIENTE CATEGORIA FacNro* FacFch CliCod CatCod* CatDto CliCod* CliNom CatCod FACTURA1 PRODUCTO ProdCod* ProdNom ProdPre FacNro* ProdCod* FacLinCnt

Tabla Base: Tabla extendida: Categoría Categoría Cliente Cliente Categoría Factura Factura Cliente Categoría Factura1 Factura1 Producto Factura Cliente Producto Producto

ATRIBUTOS FORMULAS

Características Relación entre Atributos, Constantes o Funciones Definición Global, definidas a nivel del modelo Atributo Virtual ( No se almacena en la tabla ) Son calculadas siempre que se hace referencia al atributo Un atributo es una fórmula si su valor se puede calcular a partir del valor de otros atributos. En cada transacción se puede definir qué atributos son fórmulas, pero esta definición es global (no es local a la transacción), es decir toda vez que se necesite el atributo se calcula la fórmula, tanto en transacciones como en los otros objetos GeneXus. Existe una similitud entre fórmulas y asignaciones (regla), incluso la sintáxis de definición es similar. La diferencia entre ambas es que una fórmula es GLOBAL (vale para todos los objetos GeneXus que la utilicen), mientras que una asignación en las reglas es LOCAL (vale sólo para la transacción en la cual fue definida). Cuando un atributo es fórmula, éste no está almacenado (a no ser que se lo defina como redundante) y cuando es una Asignación, por ser esta local, si esta almacenado.

Clasificación Horizontales Verticales Aggregate / Select Una o varias expresiones aritméticas condicionales. Verticales SUM COUNT Aggregate / Select Select Max, Min, Find Aggregate Sum, Count , Set Fórmula Horizontal Los atributos involucrados en la misma deben pertenecer a la tabla extendida del atributo definido como fórmula. Fórmula Vertical Los atributos involucrados deben pertenecer a la tabla directamente subordinada del atributo definido como fórmula. Son incondicionales. Aggregate / Select Pueden navegar sobre cualquier tabla del modelo. Son condicionales.

Fómulas Horizontales Atributo = <Expresión> if <Condición>; <Expresión> if <Condición>; : <Expresión> Otherwise; <Expresión> es una expresión aritmética que puede involucrar atributos, constantes y funciones. Los atributos que participan de la expresión deben pertenecer a la tabla base y/o a tablas que están en una relación N para 1 con la tabla sobre la que se define la fórmula (es decir, a la tabla extendida del atributo definido como fórmula). El atributo fómula deja de estar almacenado en la tabla y decimos que es un atributo virtual. <Condición> es la condición de disparo de la fórmula. Cuando se define una fórmula horizontal, GeneXus sabe cual es la tabla extendida del atributo que se está definiendo como fórmula, y controla que todos los atributos utilizados en dicha fórmula se encuentren en ella.

Fómulas Horizontales Ejemplo: TRANSACCION TABLA CliCod* CliCod* CliNom CliNom CliTotCmp CliTotCmp CliTotPgo CliTotPgo CliSdo = CliTotCmp- CliTotPgo Un atributo puede definirse como fómula cuando su valor se obtiene siempre de un cálculo que puede involucrar atributos, constantes y/o funciones. Por ejemplo, el saldo del cliente es siempre la diferencia entre el total de compras y el total de pagos. Diferencias entre Fórmulas y Reglas Fórmula La fórmula es una definición global ya que está a nivel del modelo de datos, su valor será calculado cada vez que se utilice en cualquier objeto GeneXus ya que el atributo no está almacenado en la tabla. Regla La regla está definida a nivel local en la transacción. Cada vez que se mencione el atributo, su valor no se calculará, sino que se tomará directamente de la tabla.

Importe de la Línea de la Factura CLIENTE CATEGORIA FacCod* FacFch CliCod CatCod* CatDto CliCod* CliNom CatCod FACTURA1 PRODUCTO ProdCod* ProdNom ProdPre FacCod* ProdCod* FacLinCnt En el ejemplo, definimos al importe del producto en la factura (FacLinImp) como una fórmula horizontal, por lo cual dicho atributo no está almacencado en la tabla Factura1. FacLinImp = FacLinCnt * ProdPre if FacLinCnt <= 100; (FacLinCnt * ProdPre * 0.9) if FacLinCnt >100;

Fórmulas Verticales SUM - COUNT Sintáxis: AtriFla = SUM(Att) AtriFla = COUNT(Att) Características: Att debe pertenecer a una tabla directamente subordinada a la tabla en la que se encuentra AtriFla. Son incondicionales. Navegación vertical - Performance Características de las Fórmulas Verticales SUM - Suma un atributo perteneciente a una tabla directamente subordinada. COUNT - Cuenta las filas de una tabla directamente subordinada. Se utilizan cuando el valor de un atributo se obtiene sumando o contando filas de una tabla que está directamente subordinada. La tabla está en una relación 1 a N. Se consideran todas las filas que pertenecen a la relación ya que no se pueden establecer condiciones. Se resuelve mediante una navegación vertical, de ahí el nombre Fórmulas Verticales Performance El hecho que la fórmula no este almacenada puede ocasionar problemas de performance, debido al tiempo que puede demorar el recálculo. Para evitar este inconveniente se puede definir la fórmula como REDUNDANTE. En este caso la fórmula se almacena en la Base de Datos y no es necesario recalcularla cada vez que se use. Profundizaremos en este tema más adelante.

Fórmulas Verticales SUM - COUNT Cálculo del subtotal de la Factura Factura: FacNro* FacFch CliCod FacSubTot = SUM(FacLinImp) Factura1: ProdCod* FacLinCnt FacLinImp = FacLinCnt * ProdPre FacSubTot y FacLinImp no están almacenados. Equivalencia entre SUM redundante y regla ADD Factura 1 N Factura1 Precisamos calcular ahora el subtotal de las líneas de la factura, que hemos llamado FacSubTot. Este atributo está en el cabezal de la factura y el atributo a ser sumado en las líneas. Estas tablas están en una relación de 1 a N, por lo que no podemos utilizar una fórmula horizontal. Precisamos una fórmula que recorra todas las líneas de la factura y las sume, utilizamos para esto una fórmula SUM( ) perteneciente a las llamadas Fórmulas Verticales. Se puede decir que un SUM redundante es equivalente a la regla ADD.

Fórmulas Verticales Sólo se puede definir entre atributos de tablas “directamente” subordinadas N 1 FACTURA CLIENTE FacSubTot = SUM(FacLinImp) 1 SUM(att) No permitido N FacLinImp FACTURA1 Sólo se puede definir entre atributos de tablas directamente subordinadas Dentro de una fórmula vertical no se puede mencionar directa o indirectamente una fórmula AGGREGATE/SELECT. El atributo mencionado en la fórmula COUNT no puede formar parte de ninguna clave . El atributo mencionado en la fórmula SUM puede ser fórmula. Para fórmulas de fórmulas GeneXus determina cuál es el orden de evaluación correspondiente. SUM (att) Puede ser Fórmula No se puede involucrar directa o indirectamente una fómula AGGREGATE/SELECT

Fórmulas Aggregate/Select Son fórmulas que permiten buscar, sumar, contar atributos que cumplan determinadas condiciones, en cualquier tabla del modelo. Aggregate Sum Count Set Select Max Min Find Fórmulas Aggregate Sum .- Suma condicionalmente atributos de cualquier tabla del modelo Count .- Cuenta condicionalmente filas de cualquier tabla del modelo Set .- Imprime instancias de un atributo en determinadas condiciones Fórmulas Select Find .-Buscar el valor de un atributo en determinadas condiciones Max .-Buscar el máximo valor de un atributo en determinadas condiciones Min .-Buscar el mínimo valor de un atributo en determinadas condiciones

Fórmulas Aggregate/Select Sintáxis atrib = Sum | Count (<att>, <cond. búsq.>, <def>) atrib = Set(<Att>, <Cond> , <Def>) atrib = Max | Min(<att>, <cond. búsq. >, <def>, <ret>) atrib = Find(<att>, <cond. búsq.>, <def>) atrib: es el atributo que se define como fórmula Sum ( atributo a ser sumado, condiciones que debe cumplir, valor por defecto ) Set: Selecciona las primeras ocurrencias (hasta 50) del atributo <att> que cumplen la condición <cond.>, y las manipula como si fueran un solo atributo. Si no se especifica ninguna condicion, las primeras 50 ocurrencias serán seleccionadas. <def> es el valor por defecto devuelto cuando ningún registro cumple la condición <cond>. Si no se menciona nada en <def>, se devuelve el nulo del tipo de datos de <att>. Max ( atributo a maximizar, condiciones de maximización, valor por defecto en caso de no encontrar quien cumpla con las condiciones, valor de retorno en caso de encontrar) Find (atributo a buscar, condiciones de búsqueda, valor por defecto en caso de no encontrar quien cumpla con las condiciones)

USO DE LA FORMULA MAX( ). Ejemplo: Buscar el precio del producto según la fecha de la Factura. Transacción Productos Transacción Factura ProdCod* FacNro* ProdDsc CliCod (ProdFch* FacTot ProdPre) FacFch (ProdCod* FacProdPre FacLinCnt FacLinImp) Atributo = MAX(Atributo a Maximizar), (Condición de Maximización), (Valor por defecto), (Atributo a devolver) IF (Condición de ejecución) Uso de la Fórmula Max( ) para buscar el precio del producto según la fecha de la factura. Definimos la transacción de productos de tal forma de guardar el histórico de precios, con la fecha de aumento de precio asociada. Con la fecha de la factura buscaremos el precio del producto correspondiente. Por ejemplo: Fecha de Factura: 10/10/93 Precio producto correspondiente: 220 correspondiente al 3/10/92 Incluiremos en las líneas de la factura el atributo ProdCod. No podemos incluir ProdFch debido a que no podríamos saber que valor darle a la fecha para poder heredar directamente el ProdPre. Definimos el atributo FacProdPre y buscaremos con una fórmula el precio correspondiente de acuerdo a la fecha de factura. Buscaremos el precio de fecha máxima anterior a la fecha de factura. La fórmula quedaría: FacProdPre = Max (ProdFch, ProdFch <= FacFch, 0, ProdPre )

USO DE LA FORMULA MAX( ). FacProdPre = Max(ProdFch, ProdFch <= FacFch, 0, ProdPre) Fecha de Factura: 10/10/93 Precio correspondiente: 220 Código de Producto Fecha Aumento Precio Valor del Producto 1021 10/08/89 200 1021 20/11/90 210 1021 03/10/92 220 1021 15/10/95 230 1022 10/08/89 100 1022 20/11/90 110 1022 03/10/92 120 1022 15/10/95 180 Atributo a Maximizar.......... ProdFch Condición.............................. Factura1.ProdCod = Producto1.ProdCod (cond. implícita). El máximo valor de ProdFch <= FacFch (cond. explícita). Atributo a devolver.............. ProdPre Valor por defecto.................. 0 , si no se encuentra ningún registro que cumpla la condición.

Ejemplo Hacer lo siguiente: Transacción de Cotizaciones MonId* CotMes* MonDsc (CotDia* CotImp) Transacción de Asientos AsiNro* AsiFch AsiMes AsiDia (AsiIdLin* MonId AsiImpME AsiImpNS AsiTipDH CtaId AsiFndCot) Hacer lo siguiente: A. Buscar la cotización de la moneda para la fecha del Asiento. B. En caso de que no exista, dar un aviso y buscar la última ingresada anterior a la fecha del asiento.

A. Transacción de Cotizaciones: MonId* CotMes* MonDsc (CotDia* CotImp) Transacción de asientos : AsiNro* AsiFch AsiMes = Month(AsiFch) AsiDia = Day(AsiFch) (AsiIdLin* MonId AsiImpME AsiImpNS AsiTipDH CtaId AsiFndCot) = Find(CotImp, CotMes=AsiMes .and. CotDia=AsiDia) if MonId<>’NS’; 1 otherwise;

B. Transacción de Asientos : AsiNro* AsiFch AsiMes =Month(AsiFch) AsiDia =Day(AsiFch) (AsiIdLin* MonId AsiImpME AsiImpNS = AsiImpME*AsiFndCot if AsiFndCot<>0; AsiImpME*AsiMaxCot if AsiMaxCot<>0; 1 otherwise; AsiTipDH CtaId AsiFndCot a=Find(CotImp, CotMes=AsiMes .and. CotDia = AsiDia) if MonId <> “NS”; 1 otherwise; AsiMaxCot) = Max(CotDia, CotMes= AsiMes .and. CotDia <= AsiDia, 0 , CotImp) if null (AsiFndCot) ; 0 otherwise; Rules : Msg (“No existe Cotización, se toma la última ingresada”) if null (AsiFndCot) .and. MonId <> “NS”;

1. Condiciones involucradas en una Fórmula Aggregate Select Condición de Búsqueda Es la condición a la cual está sujeta la búsqueda. Condición de Disparo Es la condición que determina si la fórmula se ejecuta.

2. Inferencias en el caso de una Fórmula Aggregate Select La condición de búsqueda queda determinada por: La condición explicitada como segundo parámetro. Atributos que quedan instanciados por el ambiente en el que se dispara la Fórmula : Intersección de la tabla extendida del atributo definido como fórmula (tabla de partida) y la tabla sobre la cual se está resolviendo la fórmula (tabla de llegada).

En el ejemplo: Transacción de Cotizaciones: MonId* CotMes* Given : MonId MonDsc (CotDia* CotImp) Transacción de Asientos : AsiNro* AsiFch AsiMes =Month(AsiFch) AsiDia = Day(AsiFch) (AsiIdLin* MonId AsiImpME AsiImpNS AsiTipDH CtaId AsiFndCot) =Find(CotImp, CotMes=AsiMes .and. CotDia = AsiDia) if MonId <> “NS”; 1 otherwise; En la fórmula AsiFndCot, está implícita la condición de que Asiento1.MonId = Cotizac1.MonId Esto se refleja en la navegación como “Given: MonId”

3.Cómo se determina la tabla sobre la cual efectuar la búsqueda (tabla de llegada) Atributo de Búsqueda Atributos que están en la condición y que no pertenecen a la tabla extendida del Atributo Fórmula Atributo de Retorno De otra forma: <Atr.Fórm.> - Fórmula Inválida Es importante aclarar que los atributos involucrados en la fórmula aggregate select y pertenecientes a la tabla de llegada, deben estar ALMACENADOS en la misma. Es decir, que no pueden ser fórmula ni pertenecer a la tabla extendida de la tabla de llegada.

Ejemplo de determinación de la tabla sobre la cual buscar: X = Find( A , B = C .and. D = 4 .and. E = F , 0 ) Atributos de la tabla extendida de X

Ejemplo de determinación de la tabla sobre la cual buscar: Deben pertenecer físicamente a una misma tabla X = Find( A , B = C .and. D = 4 .and. E = F , 0 ) Atributos de la tabla extendida de X

4. Fórmulas Aggregate Select no pueden participar en fórmulas SUM y COUNT simples No se permite definir una fórmula SUM que suma un atributo que es una Aggegate/Select o depende de ella. Ejemplo: FacProdPre = fórmula MAX FacLinImp = FacLinCnt * FacProdPre FacSubTot = SUM (FacLinImp) Para resolver esto, se debería almacenar el valor de FacProdPre en otro atributo, pues las Fórmulas Aggregate Select NO PUEDEN SER DEFINIDAS REDUNDANTES. O utilizar la regla ADD en lugar del SUM vertical

5. Dependencia física de las fórmulas Aggregate Select Las Fórmulas Aggregate Select dependen de la inserción, actualización o eliminación física del o los registros que involucran. EJEMPLO : Transacción de Asientos AsiNro* AsiFch AsiTotDeb = Sum(RengImp, RengTipDH=“D” , 0) AsiTotHab = Sum(RengImp, RengTipDH=“H” , 0) (RengId* MonCod RengImpNS RengImp RengTipDH CtaCod ) Dependen de la inserción: El COUNT vertical en caso de agregar o borrar una línea no recorre toda la tabla de nuevo a diferencia del Count Aggregate/Select. Las fórmulas verticales cuentan o suman los valores que estan en "memoria". Las aggregate/select no.

Diferencias entre fórmulas aggregate select y fórmulas verticales 1. Las fórmulas agg/sel actúan sobre cualquier tabla de la base de datos y las fórmulas verticales solamente sobre tablas directamente subordinadas. 2. En las fórmulas agg/sel se pueden especificar condiciones de búsqueda. En las verticales no. 3. Las fórmulas verticales cuentan o suman los valores que estan en "memoria". Las aggregate/select no. 4. Las fórmulas verticales cuentan o suman atributos que pueden ser fórmulas (pero esta fórmula no puede ser agg/sel ni involucrar en su definición una fórmula agg/sel). Los atributos mencionados en las fórmulas aggregate/select y pertenecientes a la tabla de llegada deben estar ALMACENADOS FISICAMENTE en la tabla de llegada 5. Las fórmulas agg/sel no se pueden definir como redundantes. Las verticales sí.

COMUNICACION ENTRE OBJETOS

Objetos GeneXus TRN RPT PROC WKP MENU Comunicación entre objetos GeneXus Una de las características importantes de los objetos de GeneXus es poder comunicarse entre ellos o con otros programas externos. Un objeto GeneXus puede llamar o ser llamado por otro objeto, intercambiando información entre ellos a través de parámetros que se declaran en cada uno. WKP MENU

Reglas y Comandos para implementar la comunicación CALL UDP (User defined Procedure) UDF (User defined Function) Para implementar la comunicación entre objetos GeneXus (y “no GeneXus”, es decir programas externos) se disponen de los siguientes comandos o reglas : CALL - Llama a un objeto o programa externo, permitiéndose pasar parámetros si éstos son necesarios. Los parámetros especificados son de entrada/salida. UDP, UDF - Se llama a un objeto GeneXus o a un programa externo, al cual se le pasarán los parámetros necesarios y retornará un valor, que es resultado de la ejecución de dicho objeto o programa. La diferencia entre los UDP y UDF es que los programas llamados por la función UDF no deben abrir ninguna tabla, mientras que los llamados por la función UDP sí lo hacen. Esta diferencia existe SOLAMENTE en el generador Fxp 2.6 y VFP (en los demás generadores no existe diferencia entre los udp y udf), las UDF al regresar no reabren/reposicionan las tablas, por lo tanto no soportan que el programa llamado abra tablas. Por otro lado, el Call es un poco más rápido. Las UDP restauran las tablas al volver y se usan para llamar a programas que abren tablas.

Objeto Prefijo El nombre se trunca a: Transacción T 7 caracteres Cuál es la convención usuada para el nombre de los objetos GeneXus en las llamadas? Objeto Prefijo El nombre se trunca a: Transacción T 7 caracteres Procedimiento P 7 “ Reportes R 7 “ Work Panel W 7 “ Menú M 7 “ Web Panels H 7 “ Los programas llamados con las reglas o comandos mencionados pueden ser cualquier objeto GeneXus (Transacciones, Procedimientos , etc.), o un programa externo escrito por el usuario. El nombre de dichos objetos a utilizar en la llamada (call , udp) se forma por un prefijo (identificando el tipo de objeto) seguido por el nombre del objeto truncado de acuerdo a la tabla de más arriba. En caso de que el objeto llamado sea un programa externo, debe mencionarse el nombre del programa entre comillas; en caso de ser un objeto GeneXus va sin comillas. Ejemplo: Por ejemplo, si luego del ingreso de una Factura se quiere un listado de la misma, lo que habría que poner en las Rules de la Transacción Factura es: call(RImpFac, FacNro) if insert .and. after(TRN); donde ImpFac es el nombre del Report que imprime la factura recibida como parámetro.

Call Sintáxis En regla de Transacciones: call(nom-prog,par1,...,par2) if (condición); En layout de los reports, program source de los procedures, eventos de Work Panel y eventos de Transacciones: if (condición) call(nom-prog, par1,...,par2) endif La regla o comando Call ejecuta el programa ‘nom-prog’, donde ‘nom-prog’ es el nombre de un objeto GeneXus o un programa externo escrito por el usuario (según sea el caso hay que poner o no al nombre entre comillas). El momento del disparo del call va a depender del lugar donde se encuentra. Si el call está en las reglas de la transacción, se va a tomar en cuenta en el árbol de evaluación de las reglas. Si está en el layout o program source de un reporte o procedimiento, o en los eventos (tanto de transacciones como work-panels) se va a ejecutar proceduralmente en el lugar donde fue escrito.

Call - Regla Parm La regla PARM tiene como función declarar los parámetros en el objeto llamado. Sintáxis: Parm(atributo/variable); Ejemplo: call(PAltaCli, par1, … , parn) En las Rules de PAltaCli poner: parm(par1, ..., parn ); NOTA: Si en la regla parm se recibe en un atributo, se instancia el valor y no es posible cambiarlo (noaccept implícito) Con la regla PARM se declaran los parámetros que recibe un objeto GeneXus, estos parámetros son posicionales, se deben escribir en el mismo orden, la misma cantidad y el mismo tipo que los indicados en el CALL. Los parámetros especificados en la regla parm, cuando se está invocando al objeto con el CALL, son de entrada/salida.

Udp Sintáxis En reglas de Transacciones <Att|&var> = Udp(nom-prog,par1,...,parn) if (condición); En Fórmulas: <Att> = Udp(nom-prog,par1,...,parn) if (condición); En el layout de los reportes, y en los eventos de Work Panels o Transacciones: <&var> = Udp(nom-prog,par1,...,parn) En el program source de un procedimiento: if (condición) <Att|&var> = Udp(nom-prog,par1,...,parn) endif La Udp ejecuta el objeto o programa ‘nom-prog’ que retornará un valor que será asignado a un atributo o a una variable dependiendo del caso.

Udp - Regla Parm El último parámetro en la regla parm es el valor de retorno. Ejemplo: parsal = udp(PAltaCli, par1, … , parn) En las Rules de PAltaCli poner: parm(par1, ..., parn, parsal ); Al igual que en los programas llamados con call, en los programas llamados por UDPs se debe declarar los parámetros con la regla Parm. A diferencia con los calls, el programa llamado siempre va a tener un parámetro como mínimo (el parámetro de retorno). Ejemplo: Tenemos un procedimiento que calcula la calificación de un funcionario FunValCalificacion = Udp(PCalif ,FunId, FunFchIngreso ); En el procedimiento PCalif, tenemos las siguiente regla parm: parm( &funid, &funfching, &ValorRetorno ); Al terminar el cálculo, en el program source del procedimiento se asigna a la variable &ValorRetorno el valor de la calificación del funcionario, y dicho valor es el devuelto por la llamada y asignado al atributo FunValCalificacion .

FacImpDesc = udp(‘Pcaldto’, FacTot,FacCat) Ejemplo: FacImpDesc = udp(‘Pcaldto’, FacTot,FacCat) En procedimiento PCaldto: parm(&tot, &cat, &desc); Parámetro de retorno Los programas llamados se pueden considerar como funciones , ya que al ser llamados utilizando UDP van a retornar un valor. Este valor que retornan es el último parámetro en la regla parm del objeto llamado y no debe ser especifificado en la invocación de la UDP. En el ejemplo, se utiliza una función externa (por ser externa es que el nombre se pone entre comillas) para calcular el descuento dado el total de una factura y la categoria del cliente. Las Udps pueden ser utilizadas en las reglas de los objetos, en las fórmulas, en el program source de procedimientos, en el layout de reportes, y en los eventos de transacciones o work-panels.

SUBRUTINAS

Comando SUB Sintáxis : Sub 'RoutineName’ //cuerpo de la subrutina EndSub No se permite el pasaje de parámetros. Todas las variables del programa fuente pueden ser usadas en la rutina 'RoutineName' , es decir que son globales. Disponible en Transacciones, Work Panels, Reportes y Procedures.

Comando DO Sintáxis : Do 'RoutineName' Ejecuta la rutina ‘RoutineName’. Disponible en Transacciones, Work Panels, Reportes y Procedures.

ARBOL DE EVALUACION Y EVENTOS

Arbol de evaluación F. FacImp = FacCnt * ArtPrc CliTotCmp FctTot R. Add(FctTot, CliTotCmp) ; F. FctTot = FctSubTot - FctDto + FctFleVal F. FctDto = FctSubTot * CatDto F. FctFleVal = MAX( FctFleFch, FctFleFch <= FctFch, ... F. FctSubTot = SUM ( FctImp) F. FacImp = FacCnt * ArtPrc R. Subtract(FctCnt, ArtStk) ; R. Error( ‘Stock Insuficiente’) if ArtStk < 0 ; CliTotCmp FctTot FctFleVal FctDto error (‘No hay Stock’) FctSubTot Arbol de Evaluación El conjunto de reglas y fórmulas han sido definidas sin especificar su secuencia de ejecución; pero en el momento de generar el programa GeneXus deberá determinar esta secuencia. GeneXus determina las dependencias existentes entre estas reglas y fórmulas, construyéndose lógicamente un árbol de dependencia que determinará la secuencia de evaluación. Podemos imaginar que el árbol se ejecuta de abajo hacia arriba, cada vez que cambia algún valor de un atributo, se ejecuta todo lo que depende de este atributo. Por ejemplo, si cambió la Cantidad se redispara el Importe de la línea, y a partir de esto el Sub-Total, y el Descuento y el Total y la actualización del Total de compras del cliente. También vinculado con la cantidad está el Stock, y se disparará también el Subtract correspondiente. El árbol muestra claramente que debe especificarse: error(‘No hay Stock Suficiente’) if ArtStk < 0 ; No es correcto definir: error('No hay Stock suficiente') if FctCnt > ArtStk; Esto no es correcto, pues decíamos que primero se dispara el SUBTRACT y luego el ERROR, o sea que al momento de considerar el error, ya se disparó el subtract, y se disminuyó el stock. FctFch ArtStk FctImp CatDto FctCnt ArtPrc

Arbol de evaluación F. FacImp = FacCnt * ArtPrc CliTotCmp FctTot R. Add(FctTot, CliTotCmp) ; F. FctTot = FctSubTot - FctDto + FctFleVal F. FctDto = FctSubTot * CatDto F. FctFleVal = MAX( FctFleFch, FctFleFch <= FctFch, ... F. FctSubTot = SUM ( FctImp) F. FacImp = FacCnt * ArtPrc R. Subtract(FctCnt, ArtStk) ; R. Error( ‘Stock Insuficiente’) if ArtStk < 0 ; Es importante mencionar que cuando se encuentra un error se desarma el Arbol de Evaluación, dejándose todo en el estado anterior a producirse el error. El error detiene cualquier actualización a la base de datos. El árbol es en realidad una red pero donde no pueden haber ciclos, si los hubiera en algunos casos se dispara con el valor anterior. Ejemplo: A = 1/A, se ejecuta en realidad con el valor anterior de A. A = 1 / Old(A) CliTotCmp FctTot FctFleVal FctDto error (‘No hay Stock’) FctSubTot FctFch ArtStk FctImp CatDto FctCnt ArtPrc

Alteraciones del orden de disparo de las Reglas PrvCod* FctNro* ... FctTotIng Total ingresado ( ArtCod* FctCnt FctPrc FctImp = FctPrc * FctCnt) FctTotCalc = SUM (FctImp) Total calculado Error Total Calculado Total Ingresado Fact Impt En la mayoría de los casos el orden de ejecución de las reglas definido por GeneXus a partir de nuestras especificaciones es el deseado. Pero en algunos casos puedo querer cambiar el momento de disparo de una Rule. Por ejemplo: En las facturas que recibimos de nuestro proveedor queremos controlar que el total que viene impreso en la factura (FctTotIng) sea correcto, por lo que lo calculamos nuevamente (FctTotCalc), y emitimos un error si no es así. Si construimos el arbol de evaluación vemos que las dependencias entre las reglas y fórmulas determinan que cada vez que cambie el importe, se cambiará el total calculado que es parte de la condición de la regla Error. Esta condición se va a cumplir (total calculado <> total ingresado) ya para la primera línea ingresada en la factura y se va a disparar el error en ese momento.y no podré seguir adelante. En este caso la inferencia del árbol de evaluación no me sirve, lo que quiero en realidad es que se me dispare el error cuando termine de ingresar las lineas (a la salida del nivel). Error('El total ingresado no coincide con el total calculado') if (FctTotCalc <> FctTotIng) .and. after(level(ArtCod));

Alteraciones del orden de disparo de las Reglas Entonces le marco el evento de disparo After(level(ArtCod)) Error('El total ingresado no coincide con el total calculado') if (FctTotCalc <> FctTotIng) .and. after(level(ArtCod)); Es importante mencionar que cuando se encuentra un error se desarma el Arbol de Evaluación, dejándose todo en el estado anterior a producirse el error. El error detiene cualquier actualización a la base de datos. Estos casos no son muy frecuentes, pero se dan y hay que conocerlos. A continuación se describirán cada una de estas funciones que permiten resolver casos como este, en el que el momento que GeneXus definió para ejecutar la regla no es el deseado. // INCORRECTO Error('El total de la factura no coincide con el ingresado') if FctTotIng <> FctTotCalc; // CORRECTO Error('El total de la factura no coincide con el ingresado') if FctTotIng <> FctTotCalc .and. after(level(ArtCod)); PrvCod* FctNro* ... FctTotIng Total ingresado ( ArtCod* FctCnt FctPrc FctImp = FctPrc * FctCnt) FctTotCalc = SUM (FctImp) Total calculado Error Total Calculado Total Ingresado Fact Impt Error('El total ingresado no coincide con el total calculado') if (FctTotCalc <> FctTotIng) .and. after(level(ArtCod));

Funciones booleanas que permiten cambiar el momento de disparo de una regla Level( Atributo) Insert After( Atributo ) Update After(Insert) Delete After(Update) After(Delete) After(Confirm) After(Level(Atributo)) After(Trn) Son funciones lógicas que devuelven .T. or .F. Level Sintáxis: Level(Atributo) Retorna True o False dependiendo del nivel en que se encuentre en la estructura el atributo especificado. Ejemplo: Call(‘Pxxx’) if Insert .and. level(CliCod) ; Si se mencionara un atributo como parámetro no sería necesario especificar el nivel ya que se tomaria el nivel del parámetro. Ejemplo: Call(‘Pxxx, CliCod’) if Insert ; After Sintáxis: After(<Event>) Donde <Event> puede ser : <Att> | <Action> | Level(<Att>) | Trn | Confirm After(Attribute) Ejemplo: A = B * C if After(C); Ejecuta la regla después de aceptar el valor del atributo C. La condición After(Att) tiene el mismo efecto que la condición Level(Att) en el entorno AS/400, ya que la transmisión es a pantalla completa y no atributo a atributo como en PC.

Insert, Update, Delete Para condicionar el modo de disparo After(Confirm) Dispara la regla después de haber confirmado los datos del nivel asociado pero antes de haber realizado la actualización. After(Insert) After(Delete) After(Update) Se dispara después de haber insertado, actualizado o eliminado el registro de la tabla base del nivel. Ejemplo: La siguiente transacción llama a un procedimiento que realiza la impresión de los datos de un cliente. El procedimiento seteará el atributo CliSts, para indicar que se realizó la impresión. Transacción Clientes CliCod* Código de Cliente CliNom Nombre de Cliente CliSts Status cliente Llamadas al Procedimiento: es necesario precisar en que momento se debe disparar el llamado al procedimiento. Llamadas Incorrectas: Caso 1: Call('pficha', CliCod) if Insert .and. After(Confirm); El cliente no existe, por lo que falla la lectura. Caso 2: Call('pficha', CliCod) if Update .and. After(Confirm); El cliente ya existe, pero aún no se han grabado las modificaciones. Llamadas Correctas: call('pficha', CliCod) if After(Insert) ; call('pficha', CliCod) if After(Update); call('pficha', CliCod) if After(Trn); El cliente ya existe o ya se han grabado las modificaciones. After(Trn) Dispara la regla después de procesar todos los datos de la transacción, es decir, el primer nivel y todos los subordinados. En el AS/400 la regla es disparada después del Commit. Funciones booleanas que permiten cambiar el momento de disparo de una regla Level( Atributo) Insert After( Atributo ) Update After(Insert) Delete After(Update) After(Delete) After(Confirm) After(Level(Atributo)) After(Trn)

Reglas que ocurren en el mismo evento Son disparadas en el orden en que fueron definidas Ejemplo call(' ') if After(Trn); call('pgmname', CliCod, &flag) if After(Confirm); error(' ') if After(Confirm) .and. &flag = 'N’ ; Para CALLs, ERRORs, y MSGs, cuando se marca el evento de disparo, si dos Reglas ocurren en el mismo evento y no dependen entre sí, vale el orden en el cual se definieron. Ejemplo 1 Se ejecuta un Call y luego el otro Ejemplo 2 Se quiere llamar a un procedimiento que realiza determinada validación, y que retorna en la variable &flag, el resultado (S o N). En caso de que el resultado sea negativo se quiere mostrar un mensaje de error. | call(pgmname, CliCod, &flag) if After(Confirm); | | error(' ') if After(Confirm) .and. &flag = 'N'; v Importante: Si se invierte el orden de estas reglas, y la validación resulta negativa, el error no se dispara.Si en vez de ser un call fuera un udp donde el campo de salida fuera &flag , sí se dispararía.

Ejemplo de transaccion de dos niveles Level CabFac .....................................> reglas stand-alone Trasmit Screen ....................................> evaluación de reglas y fórmulas según árbol Confirm Screen ....................................> reglas after(confirm) Insert/Update/Delete ....................................> reglas after(insert/update/delete) Level LinFac ..........................> evaluación de reglas y fórmulas según árbol ..........................> after(confirm) .and. level(<att de 2do. nivel>) ....................................> reglas after(insert/update/delete) .and. level(<att de 2do. nivel>) EndLevel ....................................> after( level (<att de 2do. nivel>)) Commit ................................> evaluación de reglas after (trn)

Eventos en las Transacciones El código permanece ocioso hasta que ocurre un evento al cual está relacionado Evento = Acción reconocida por un objeto y a la cual se le puede asociar un código ejecutable Programación Dirigida por Eventos En las transacciones se permite la Programación Dirigida por Eventos, que es un estilo de programación en el que existe código que permanece ocioso, hasta que es llamado para responder a eventos, provocados en nuestro caso por el usuario, o por el sistema. Los eventos son acciones que pueden suceder o no. Nosotros tendremos un código asociado a cada evento posible, el cual se disparará sólo si el evento se produce. Por ejemplo, puede haber un código asociado al evento de presionar una tecla (Por ejemplo <Enter>), que se activará cuando el usuario decida presionar esa tecla. La programación dentro del evento sigue un estilo procedural.

Eventos explícitos en las Transacciones Evento Start Evento ‘User-Event’ Evento After Trn Evento Exit Start: Es un evento del sistema y se da al comienzo del programa. Es normalmente usado para asignar valores a variables. User Defined Event: Es un evento definido por el usuario, que es activado una vez que se selecciona una opción del menú o se presiona una tecla de función/botón. After Trn: Es un evento del sistema y es activado una vez que la transacción ha terminado. Es similar a la regla AFTER(TRN) usada en las transacciones. Exit: Es un evento del sistema y es activado cuando el usuario abandona el programa.

Evento Start EndEvent Se ejecuta al principio del programa. Sintáxis: Event Start EndEvent Se ejecuta al principio del programa. Ejemplo: Guardar el inicio de ejecución del programa Event Start &entrada=Time( ) Generalmente es utilizado para la asignación de variables y parámetros que interesa evaluar una sola vez en la ejecución del programa.

Evento Start Ejemplos: 1.- Event Start &Mes1 = ‘Enero’ EndEvent 2.- En el Evento Start de la transacción de Facturas : Event Start call(PFindCli,&today, CliCod) Se instancia el Cliente. Se accede sólo a las Facturas de ese Cliente. Si en el Evento Start de una transacción hay un call , los atributos que están en el call tienen el mismo comportamiento que si se recibieran como parámetros. Es decir, que funcionan también como filtro (se instancia). En el ejemplo 2, al pasar como parámetro al CliCod se pueden ver sólo las Facturas del CliCod pasado como parámetro. Queda instanciado el Cliente.

Eventos del Usuario Sintáxis: Event ’User-event-name’ <Key> Level <att> Endevent Ejemplo Event ‘Deuda Cliente’ 2 Level FacId if .not. null(CliId) call(wdeucli,CliId) endif Endevent Se ejecuta cuando el usuario presiona la tecla de función asociada o el botón correspondiente. Level <att> - El evento se activa sólo si se encuentra en el nivel definido por el atributo.

Evento After Trn Event After trn EndEvent Ejemplo: Event After trn Return Equivalente a la función After(trn), pero permite agrupar todas las acciones que se deseen evaluar en el after(trn) sin tener que condicionarlas por separado (rules). Ejemplo: Event After trn return Endevent Abandonar el programa una vez que se ejecutó un ciclo completo de la transacción.

Evento Exit Event Exit EndEvent ……………. EndEvent Se activa cuando el usuario abandona el programa. Ej: Llamar a un procedimiento que graba la hora de entrada y salida del programa para cada usuario en una tabla de control. Event Exit &user = userid() &salida = Time() call(‘pcontrol’, &entrada, &salida, &user) EndEvent

Rules / Eventos En caso de conflicto de evaluación entre reglas y eventos de una transacción, la regla se evalúa primero. Eventos: Rules: Event After trn call(tvenfac,FctCod) if after(trn); ……. return End event Esta convención toma efecto cuando se presenta un conflicto en el momento de evaluación de las reglas y eventos. Sólo el evento after trn presenta ese caso. El evento Start no entra en conflicto con las reglas llamadas stand-alone ya que conceptualmente su evaluación son en diferentes momentos. Las reglas stand-alone se evalúan en el primer nivel antes del despliege de la pantalla. El evento Start se evalúa al comenzar el programa.

Rules / Eventos En caso de conflicto de evaluación entre reglas Ejemplos de uso de Eventos en las Transacciones 1. Desplegar el nombre de la organización en la pantalla al comienzo de la transacción: Event Start &Orgnom = udp(PNombre, Orgcod) Endevent 2. Imprimir una factura al presionar F7 o presionar el botón correspondiente. Event 'Imprimir Factura' 7 call(RPFac, FacNro) 3. Podemos querer retornar al programa llamador una vez que la transacción haya sido ingresada: Event After trn Return 4. Para contar la cantidad de veces que una transacción ha sido invocada durante una sesión, podemos programar los siguientes eventos: &Veces = 0 &Veces = &Veces + 1 Event Exit &Msg = 'El número de transacciones grabadas: ’ + str(&Veces) msg(&Msg) Rules / Eventos En caso de conflicto de evaluación entre reglas y eventos de una transacción, la regla se evalúa primero. Eventos: Rules: Event After trn call(tvenfac,FctCod) if after(trn); ……. return End event

Rules / Eventos En caso de conflicto de evaluación entre reglas 5. Por ejemplo, supongamos que en la transacción de facturas queremos dar la opción de visualizar otras compras del cliente. Definimos entonces un evento del usuario: Event "Ver otras compras" 4 Call(wVerComp, CliCod) Endevent Cuando el usuario presione la tecla F4, llamaremos al work panel 'VerCompras' que mostrará las otras compras del cliente. Rules / Eventos En caso de conflicto de evaluación entre reglas y eventos de una transacción, la regla se evalúa primero. Eventos: Rules: Event After trn call(tvenfac,FctCod) if after(trn); ……. return End event

Consideraciones No se permite asignar valor a los atributos. Start-Exit ---> Sin tabla base User Event-After(trn) ---> Con tabla Base Restricciones No se permiten comandos asociados a otros eventos existentes en los work panels (load, refresh,etc.). A parte de estas restricciones, hay que tener en cuenta que los momentos de evaluación no están asociados a modos de evaluación activos por lo que no son válidas tampoco las funciones asociadas a los modos activos como Insert, Update , Delete y After(Event). Para condicionar el disparo de eventos a los modos de ejecución activos debemos utilizarlos en combinación con reglas. Recomendaciones Controlar mediante variables seteadas en las reglas que los eventos de usuario hagan calls en situaciones válidas. Los eventos de usuario pueden evaluarse en cualquier momento, sin tener en cuenta el modo en que está la transacción. Los atributos pasados como parámetros en los calls que se ejecutan en los eventos, son de entrada/salida, por lo tanto pueden cambiar su valor instanciándose con el valor devuelto por el programa llamado.

REPORTES Y PROCEDIMIENTOS

Reportes y Procedimientos Procesos no interactivos de consulta de la base de datos. Procedimientos Procesos no interactivos de actualización de la base de datos. Reportes Definen procesos no interactivos de extracción de datos. Usualmente un reporte es un listado que se envía a la impresora, aunque también puede ser visualizado por pantalla. Procedimientos Definen procesos no interactivos de actualización de la base de datos y subrutinas de uso general. Podemos decir que son un superset de los reportes, ya que pueden hacer todo lo que estos hacen y además actualizar la base de datos.

Características Definición procedural Definición sobre la Base de Conocimiento Independencia de la Base de Datos Definición Procedural. A diferencia de las transacciones donde las especificaciones se realizan en forma declarativa y GeneXus resuelve en el momento de generar el programa la secuencia de ejecución, en los reportes las especificaciones son realizadas en forma procedural. Definición sobre la Base de Conocimiento. La gran protencia del lenguaje de reportes/procedimientos es que las definiciones se hacen sobre la Base de Conocimiento y no directamente sobre el modelo físico. Esto nos permite utilizar automáticamente todo el conocimiento ya incorporado o generado por GeneXus a partir de las especificaciones realizadas. Por ejemplo el concepto de tabla extendida, que es posible porque GeneXus conoce las relaciones entre las tablas de la Base de Datos. Otro ejemplo claro, es el caso de los atributos fórmulas, donde aprovecharemos que GeneXus sabe como calcular el valor para este atributo. Independencia de la Base de Datos, definición a nivel de atributos. La definición de Reportes y Procedimientos se hace a nivel de atributos, en ningún momento decimos qué tablas se deben recorrer ni qué índices se deben utilizar, sino que esto es determinado por GeneXus en base a las especificaciones realizadas. De esta manera logramos una real independencia de la base de datos, ya que en cualquier cambio en las tablas será manejado automáticamente por GeneXus.

Comando For Each Sintaxis: For Each [Order] [ Atr...Atr] Where <Condition> ... Defined by <Attribute List> ….. Endfor Toda la definición del acceso a la base de datos y la estructura del reporte o procedimiento se realizan sólo con este comando. El acceso a la base de datos queda especificado por los atributos que son utilizados dentro de un grupo FOR EACH - ENDFOR. Order: Lista de atributos indicando el orden de recorrida de la tabla base. Sólo pueden mencionarse atributos almacenados en la tabla base. El Order es opcional, en caso de no especificarse se asume el orden de la clave primaria de la tabla base (si es que el for each no está anidado a otro for each). Elección del índice: GeneXus elige automáticamente el índice a utilizar para satisfacer el orden, en caso de que no exista ninguno se crea uno en forma temporal. Where: Establecen condiciones de filtro en la recorrida de la información. Se pueden mencionar atributos de la tabla base y/o de la tabla extendida. Defined by: En el caso de que no se mencione ningún atributo secundario dentro del For Each, debe utilizarse esta cláusula (mencionando algun atributo secundario de la tabla base que se desea recorrer) para que GeneXus pueda determinar la tabla base a utilizar. Debe quedar claro que el/los atributos mencionados en el defined by “ participan” en la determinación de la tabla base, así como también participan los atributos mencionados en todo el For Each. Lo que ocurre es que si se utiliza cuando realmente es necesario, entonces dichos atributos son los que determinan la tabla base.

Inferencia de las tablas utilizadas en el For Each Determinadas automáticamente a través de los atributos del grupo For Each (Order , where, defined by y cuerpo del For Each) GeneXus después de definir los atributos que participan determina una Tabla Base y su Tabla Extendida A partir de esto define la navegación GeneXus infiere la tabla base del for each, por los atributos mencionados en el order, where, defined by y en el cuerpo del for each. Tomemos como ejemplo un reporte con la siguiente definición: En base a la definición realizada para el reporte, GeneXus genera el programa correspondiente determinando automáticamente lo siguiente: 1. Que las tablas que el programa debe utilizar en el reporte son Client y Depart 2. Que la tabla que debe recorrerse es Client 3. Que debe accederse a la tabla Depart para complementar la información (obtener DptNom) 4. Que el orden de recorrido es CliCod y que el índice que debe usarse es el Indice IClient Todo esto en base a una especificación que sólo incluía los atributos a listar.

Ejemplo :Tabla Base y Tabla Extendida FACTURA CLIENTE CATEGORIA FacNro* FacFch CliCod CatCod* CatDto CliCod* CliNom CatCod FACTURA1 PRODUCTO ProdCod* ProdNom ProdPre FacNro* ProdCod* FacLinCnt

When None Ejecutar determinado código, cuando en un For Each no se encuentra ningún registro. Sintáxis For each //clientes Where (condiciones de filtro) (proceso el cliente) When none Msg(“ningún cliente cumple condiciones”) Endfor El Msg se ejecuta sólo cuando no se entra en el For Each. También se aplica a For Each [Selected] Line, XFor Each y XFor First, los cuales veremos más adelante. Importante: Si se incluyen For Eachs dentro del When None no se infieren Joins ni filtros de ningún tipo con respecto al For each que contiene el When None ya que son considerados dos For Each paralelos .

Report Wizard Permite diseñar el layout de un reporte (o procedimiento) de una forma mucho más fácil. Se define a partir de una estructura de datos muy similar a las transacciones. El diseño del layout consiste en dos pasos: 1.- Requiere de una estructura de datos en la cual hay que incluir atributos definidos en las transacciones. Dicha estructura es muy similar a la usada en las transacciones, sin embargo, los paréntesis se usan para indicar niveles de For Each (en vez de niveles de una transacción) y el asterisco (*) se usa para indicar el orden deseado (y no para indicar la unicidad como en las transacciones). Las reglas que son usadas para definir la estructura de una transacción también se aplican al describir la estructura del layout. Una vez que se definió correctamente la estructura, se presiona el botón de “Next” para pasar al siguiente paso. 2.- Permite definir otras características del layout. Se permite elegir los fonts para representar los atributos o textos, también se permite definir si los cabezales de los atributos para cada uno de los niveles se despliegan horizontalmente o verticalmente. Presionando el botón de “Finish “ se graban las definiciones para el paso actual y se sale del diálogo del Report Wizard. El Wizard permite que los niveles tengan o no orden . El atributo que indica el orden no tiene porqué ser el primero del nivel. Una vez que todas las opciones del Wizard fueron aceptadas, se genera el layout del reporte, el cuál puede ser modificado como cualquier otro reporte. También es posible editar el Wizard mediante la opción : Edit / Report/Proc. Wizard.

For Each paralelos For Each // Facturas EndFor For Each // Recibos Los For Each se pueden definir en forma paralela o anidada. En el ejemplo hemos definido dos for eachs paralelos. El primero recorrerá todas las facturas y el segundo todos los recibos. Navegaciones totalmente independientes.

For Each anidados Tres Casos: Tabla Base de los For Each distintas pero relacionadas por uno o varios atributos Tabla Base de los For Each distintas y no existe ningún atributo relación entre las tablas extendidas de los For Each Tabla Base de los For Each es la misma: Corte de Control La tabla base queda determinada estudiando los atributos utilizados en el cuerpo del For Each en el caso de los For Each principales (no anidados). Para el caso de los For Each subordinados la tabla base queda establecida por los atributos utilizados en el cuerpo del For Each siempre y cuando estos atributos no esten contenidos en la tabla extendida del For Each principal. Si el conjunto de atributos utilizados en el For Each están contenidos en la extendida ya calculada, el for each anidado tendrá la misma tabla base del for Each principal. Este caso se distingue en el diagrama de navegación utilizando BREAK en lugar de For Each para todo grupo For Each subordinado que no defina una nueva tabla base.

For Each anidados Caso 1 : Tablas extendidas de los For Each distintas pero relacionadas por uno o más atributos For Each [CliCod] [CliNom] [FacNro] [FacTot] Endfor Endfor Atributo relación: CliCod Se instancia el orden CliCod en el For Each anidado Cliente Cuando se definen For Each anidados GeneXus intentará establecer que atributos en común tienen ambas tablas extendidas (dándole prioridad a los atributos de la tabla base), y definirá que estos atributos actuarán como condiciones de filtro en la recorrida de la tabla anidada. En este ejemplo, la tabla base del primer for each es la de clientes, y la del segundo, la de facturas. Ambas tablas están relacionadas por el atributo CliCod. FOR EACH Client Order : CliCod Index : I00101 Navigation filters: Start from: First record Loop while: Not end of table ------->> Client ( CliCod ) FOR EACH Factur Index : I00402 Start from: CliCod = CliCod Loop while: -------- >> Factur ( FacNro ) END FOR CliCod Facturas

For Each anidados Caso 2 : Cuando tenemos que la tabla base de los For eachs son distintas y no existe ningún atributo que las relacione, el resultado que obtenemos es el Producto Cartesiano de dichas tablas. Producto Cartesiano: Para cada registro de la tabla base del primer For Each se recorre toda la tabla asociada al For Each anidado.

Corte de Control Caso 3 : Procesar información por grupos. Ej: Procesar facturas por cliente. Cada vez que cambia el cliente se define un nuevo grupo. For Each Orden CliCod (tabla Factura) orden - determina For Each corte de control (tabla Factura) EndFor EndFor -> Defined by, Print if detail Corte de Control La resolución de este reporte puede hacerse accediendo únicamente a las facturas, recorriendo la tabla ordenada por cliente. En este caso imprimiríamos solo aquellos clientes que tienen facturas. De todas maneras es necesario utilizar dos for eachs, ya que se necesita una instancia de corte, es decir un momento en el que se cambia de cliente y se puede operar en consecuencia, por ejemplo imprimir el total facturado al cliente. Lo interesante del caso dos for eachs tendrán como tabla base la tabla de facturas. Para lograr esto se puede utilizar la cláusula DEFINED BY del For each o el comando PRINT IF DETAIL. En el ejemplo podríamos mencionar un atributo de la tabla de facturas en el Defined by , con lo que estaríamos diciendole explícitamente a GeneXus que utilizara esta tabla. Si utilizamos Print if detail debemos definirlo en el primer For Each. Se debe definir además en el orden de recorrida del primer for each (cláusula ORDER), los atributos por los que se quiere realizar el corte (en el ejemplo CLICOD). Este es un requerimiento debido a que GeneXus no podría saber cual es el criterio de agrupación que queremos ya que en una misma tabla pueden ser varios, por ejemplo podríamos querer realizar el corte de control por Fecha de factura, totalizando el total facturado cada dìa. Debido a esto es que la definición de la cláusula Order es necesaria.

Corte de Control Caso 3 : Procesar información por grupos. Para resumir, un corte de control queda definido de la siguiente manera: Existen dos grupos FOR EACH anidados sobre la misma Tabla Base, los atributos de corte quedan definidos por el conjunto de atributos especificados en el comando ORDER. Para hacer un corte de control, necesitamos hacer una navegación de Facturas por Fecha. Cuando ejecutemos este reporte, generará un índice temporal por fecha, sobre la tabla Facturas. La navegación de un corte de control es la siguiente: FOR EACH Factur Order : CliCod Navigation filters: Start from: First record Loop while: Not end of table ----- >> Factur ( FacNro ) --- > Client ( CliCod ) BREAK Factur Order : CliCod, FacNro CliCod = CliCod FacNro = FacNro ------->> Factur ( FacNro ) END BREAK END FOR La particularidad de esto es que el segundo For each se muestra como un BREAK. Caso 3 : Procesar información por grupos. Ej: Procesar facturas por cliente. Cada vez que cambia el cliente se define un nuevo grupo. For Each Orden CliCod (tabla Factura) orden - determina For Each corte de control (tabla Factura) EndFor EndFor -> Defined by, Print if detail

Filtros en la navegación Where Condition Parm(Atr ... Atr) - Atributos recibidos como parámetros Como filtrar la información a recuperar de la base de datos. Muchas veces es necesario filtrar la información a incluir en el reporte, por ejemplo supongamos que el reporte deberá listar sólo aquellos clientes cuyo código esté comprendido en un rango determinado. Para resolver esto, tenemos dos opciones: * El uso de condiciones (Item Conditions) * El uso de la cláusula where en el FOR EACH La única diferencia entre usar Conditions o la cláusula Where, es que la primera es global para todos los FOR EACH que definamos en el layout y la segunda se cumple sólo para el FOR EACH donde fue definida. La performance es la misma en ambos casos. Debemos escoger una de las dos opciones. La regla PARM() La utilización de atributos en la regla PARM() determina una condición por igual global para todo el reporte o procedimiento. Ejemplo: PARM(CliCod) . For Each [ CliCod] [CliNom] Endfor El reporte sólo podrá acceder al cliente cuyo código sea igual al recibido como parámetro.

Diseño de la salida Header …... End PL [nlines] CP [nlinea] MT Header …... End PL [nlines] CP [nlinea] Lineno [nlinea] Eject Noskip Footer PL MT [nlínea]: nlíneas es el número de línea en el que se quiere empezar a imprimir el listado. En caso de no especificarse un valor se asume el valor por defecto que es 0. MB [nlínea]: nlíneas es el número de líneas que se desea dejar como margen inferior. En caso de no especificarse un valor se asume el valor por defecto que es 6. PL [nlínea] : Setea el largo de página. El número de líneas que será impreso es el número especificado menos el margen de abajo (valor por defecto es 6). Ej: PL 66 Setea el largo de página a 66 líneas, aunque sólo 60 líneas serán impresas en el form, con un margen inferior de 6 líneas. CP [nlínea] : Si queda en la página actual un número de líneas mayor o igual al número especificado, continúa imprimiendo en la misma página. De lo contrario, pasa a imprimir en la próxima página (fuerza a un salto de página). Lineno [nlínea] : Define el número de línea donde va a ser impresa la siguiente línea. Si el número de línea actual es mayor al número especificado, entonces, la línea será impresa en la próxima página. Eject : Fuerza a un salto de página. Noskip : Tiene que estar inmediatamente después de un printblock. Si el comando se encuentra entre dos líneas, este comando las imprimirá en la misma línea. MB

Report Viewer Permite: Imprimir Visualizar el reporte mientras se está generando Paginado Zoom Salvado a un archivo Find En las preference del modelo se indica si se desea o no utilizar el report viewer. Los listados se pueden salvar a archivos, almacenandose en archivos de extensión *.gxr. Para visualizar reportes anteriores se debe invocar al Report Viewer para poder desde éste hacer un File/Open del archivo que contiene el reporte listado anteriormente. El Report Viewer se abre automáticamente cuando se ejecuta cualquier reporte, o se puede ejecutarlo Standalone ejecutando el utilitario GxRView.

PROCEDIMIENTOS

Inserción de registros Ejemplo: Inserción en tabla de resumen de ventas anuales Tabla: CliCod* VtaAno* VtaTot New CliCod = &CliCod VtaAno = &Ano VtaTot = &Total When Duplicate For each VtaTot = VtaTot + &Total Endfor EndNew New: Permite dar altas en una tabla de la base de datos. Siempre se ejecuta por clave primaria Cuando hacemos una inserción en una tabla, GeneXus controla que no hayan claves duplicadas. Si quisieramos aplicar un tratamiento especial para estos casos, podemos usar el comando When Duplicate para decir que acción tomar cuando se detecta que el valor de la clave en un alta ya existe en la tabla correspondiente.

Actualización For Each Atr = <Exp> Actualiza atributo de ..………. la tabla extendida Endfor La actualización se realiza en el EndFor. Los atributos actualizables dentro de un grupo For Each, son todos los pertenecientes a la tabla extendida. La actualización física se realiza cuando se encuentra el EndFor del grupo For Each correspondiente.

Delete For Each defined By FacFch Delete sólo Tabla Base endFor La ejecución real del comando se produce cuando se encuentra el Delete y no cuando se llega al EndFor . La eliminación de registros de la tabla base dentro de un grupo For Each se hace mediante el comando DELETE.

Restricciones No se realiza control de integridad referencial No Actualiza atributos definidos como redundantes En los procedimientos, el control de Integridad Referencial queda a cargo del diseñador, lo que no ocurre en las transacciones. Las fórmulas redundantes no se actualizan, hay que calcularlas y actualizarlas en forma manual. Consideraciones: Si no incluimos la clave primaria en el New, ese New se realiza con valor nulo de clave. Si no incluimos atributos secundarios pueden pasar dos cosas: 1.Estos quedan nulos, en caso de no estar anidado el New.. 2. Si el New está dentro de un For Each con la misma tabla base del New, los atributos instanciados por el For Each y no mencionados en el New son inferidos para la inserción del registro.

WORK PANELS

Work Panels Definir consultas interactivas a la base de datos. Es muy flexible por lo que se presta para múltiples usos. Es especialmente útil para usuarios que usan el computador para tomar decisiones

Diferentes tipos de Paneles - Entry Panel - Display Panel - Single Choice Selection List - Multiple Choice Selection List - Action List Las normas Common User Acces de IBM definen diversos tipos de pantallas, estandarizando los diálogos con el usuario.

Entry Panel - Panel de Entrada Paneles de Entrada Son paneles de entrada/salida. A través de ellos se aceptan y se despliegan valores. Por ejemplo, un panel de entrada puede ser una pantalla previa a una impresión, donde se piden los parámetros necesarios para la misma y luego se llama a un Report.

Display Panel - Panel de Salida Paneles de Despliegue Son un caso particular de Paneles de Entrada, donde los datos pueden ser solamente exhibidos. Un panel de despliegue puede ser una pantalla plana o puede mostrar una cantidad variable de datos. Esto último, consiste en mostrar varias líneas por pantalla permitiendo que el usuario se desplace hacia arriba y hacia abajo (scrolling).

Selección Unica/Selección Múltiple/Listas de Acción Area Fija Subfile Eventos y Teclas de función Listas de Selección de opción única Una lista de selección de opción única contiene un grupo de opciones de las que los usuarios pueden seleccionar solamente una. La forma de hacer la selección es teclear algún valor en la línea a ser seleccionada. Una acción puede ser entonces ejecutada sobre el contenido de la línea seleccionada. Listas de Selección de opción múltiple Una lista de selección de opción múltiple contiene un grupo de posibilidades de las que los usuarios pueden seleccionar cualquier número de ellas. Una lista de este tipo permite que una acción (solamente una) sea ejecutada en varias líneas simultaneamente. Lista de Acción Se pueden elegrir acciones diferentes a aplicar a cada una de las líneas.

Comando For Each Line Sintáxis: For Each Line …….. Recorre todas las lineas EndFor del subfile En caso de querer recorrer sólo las lineas del subfile que fueron seleccionadas: For Each Selected Line …………. EndFor El comando For Each Line permite recorrer el Subfile (no la base de datos). Para cada una de las lineas del subfile, se ejecuta el cuerpo del For Each Line. El comando For Each Selected Line permite recorrer sólo las lineas que fueron seleccionadas del Subfile. Los generadores no visuales sólo permiten selección única. En Visual FoxPro, no es posible seleccionar varias lineas en los grids a diferencia de Visual Basic (es una limitación de VFP, no del generador).

Programación dirigida por Eventos El código del programa permanece ocioso hasta que se invoca su ejecución mediante acciones tomadas por el operador del programa frente a la pantalla . Ejemplo: Event Enter Código en respuesta a pulsar la tecla Enter EndEvent La forma de programar los paneles de trabajo está inspirada en la programación de los ambientes gráficos, especialmente en la llamada Programación Dirigida por Eventos (Event Driven Programming). Por Programación Dirigida por Eventos se entiende un estilo de programación en el cual las aplicaciones contienen código que permanece ocioso hasta que es llamado para responder eventos provocados por el usuario o por el sistema. Los Work-Panels se definirán entonces de una manera menos procedural que en la programación clásica, y orientada a eventos. Los eventos son acciones que pueden suceder o no. Tendremos un código asociado a cada evento posible, el cual se disparará sólo si el evento se produce.

Eventos Start Refresh Load Enter User-defined Exit Evento Start: Es un evento del sistema, ocurre cuando se comienza a ejecutar el work panel. Es usado comunmente para asignar valores a variables, generalmente para dar valores por defecto a las variables del área fija de la pantalla. Evento Refresh: Es un evento del sistema, ocurre inmediatamente antes de comenzar la carga del subfile. En un ambiente multiusuario, los datos de la pantalla pueden estar desactualizados si fueron modificados desde otra terminal. En este caso, cuando el usuario desee actualizarlos, deberá presionar el botón refresh cuyo efecto es cargar nuevamente el subfile. Comando Refresh: En algunos casos, desde otro evento también puede ser necesario cargar nuevamente el subfile. Por ejemplo cuando en un evento se llama a una transacción que actualiza los datos (Ejemplo "Ingresar" (F6)) que se están desplegando en el subfile, lo que se hace entonces es ejecutar el comando refresh luego del call a la transacción. También se necesita hacer un refresh cuando una variable que aparece en las Conditions es modificada por el usuario. Estas variables determinan qué datos se cargarán en el subfile, si una condición cambia, el subfile debe ser cargado nuevamente. Evento Load: Es un evento del sistema que ocurre cuando un subfile está siendo cargado. Para cada registro que se cargará en él, se disparará este evento.Este evento es usado generalmente para cargar variables en el subfile. Los valores de estas variables pueden ser calculados o leidos de la base de datos usando el comando For Each. Se puede hacer referencia a cualquier atributo que pertenezca a la tabla extendida asociada al panel de trabajo. Evento Enter: Este evento ocurre cuando el usuario presiona Enter. Evento Exit: Este evento ocurre después que el usuario presionó la tecla de salida (ESC o F12), o el comando "return" es ejecutado en cualquier evento. User Defined Event:: Se pueden definir eventos del usuario, los que pueden estar asociados a una tecla de función o a un botón. De esta manera el evento ocurre cuando el operador presiona la tecla de función o el botón asociado al evento.

Estructura de los eventos Comienzo Evento Start Evento Refresh Evento Load Mostrar datos en pantalla Evento Enter Evento 'User Defined' Evento Exit Fin

Reglas más importantes Order Noaccept Search Hidden Workfile_lines Order Define cuál es el orden de los datos en el subfile. Es equivalente a la cláusula ORDER del For Each y se aplica todo lo dicho en la sección de Reportes sobre el tema (incluida la creación de índices temporales). Por ejemplo, si quisieramos ver los clientes ordenados por nombre: Order(CliNom); Noaccept A diferencia de las Transacciones, en los paneles de trabajo ningún atributo es aceptado. En cambio las variables presentes en la pantalla son aceptadas, a no ser que tengan la regla NOACCEPT. Search Cuando el subfile es demasiado extenso, muchas veces se quiere brindar la posibilidad de que el usuario pueda 'posicionarse' en alguna línea determinada del mismo, en forma directa, sin tener que avanzar página por página. Por ejemplo, para buscar un cliente por su nombre se debe definir la regla: Search(CliNom >= &Nom); Hidden: En los paneles, GeneXus infiere automáticamente cuales son los atributos y variables que debe incluir en el subfile.Esta regla es usada para indicarle explícitamente a GeneXus cuales atributos o variables debe incluir en el subfile sin estar presentes en el mismo. Se usa cuandopor razones de presentación, no es conveniente mostrar un atributo en el área de subfile de la pantalla, pero se quiere capturar su valor cuando se haga el load de la misma. Workfile_lines (<MaxLine>): Dado que los subfiles se cargan en archivos temporales y que no existe un límite en la cantidad de líneas a cargar en ellos en PC o LAN , puede traer problemas si la tabla base asociada tiene muchos registros ya que el archivo temporal tendría todos los registros de la tabla base. Usando esta regla, se menciona en MaxLine la máxima cantidad de líneas que se permite cargar en el subfile. Si el límite expecificado se excede, se despliega el siguiente mensaje “ Number of lines exceeded xxxx ”.

Propiedades más importantes Loading Load Records Load at Startup Automatic Refresh Refresh Timeout (FoxPro only) Load Records: Los posibles valores son ‘Load on request’ o ‘Load all records’. Load on request: A medida que se va paginando va cargando los registros del subfile (‘Carga a pedido’). Load all records: Carga todos los registros. Load at Startup: Los valores posibles son ‘Yes’ o ‘No’. Yes: Inmediatamente después de ejecutar el Workpanel se carga el subfile. No: No carga el subfile de l panel hasta que no se ingresen los valores de la parte fija del WorkPanel. Automatic Refresh: Esta property es especialmente útil en el caso de un subfile con sólo variables, cuando uno desea que se haga automáticamente un refresh cada vez que uno de los valores de la parte fija son modificados. Los valores posibles son Only when variables in condition change (default): : Tiene el comportamiento de siempre. When any variable changes: Genera un refresh cada vez que cualquier variable de la parte fija del Workpanel es modificada. Refresh Timeout: Esta property es para que se haga un refresh del subfile automáticamente si el usuario no efectuó ninguna operación en el lapso de tiempo especificado. No hay valores predefinidos. Debe especificarse un valor en segundos (lapso de tiempo).

Work-Panel con o sin Tabla Base ? Los atributos que determinan la tabla base y su extendida son los definidos en: Panel Reglas Hidden y Order Eventos ( fuera de comandos For Each) Work Panel sin tabla base comando LOAD Work -Panel con tabla base: En la navegación: For Each [ Tabla Base ] Order: Atributos del indice por clave Primaria (si no se incluyó regla order) Index: Clave primaria (si no se incluyó regla Order) // Otros For Eachs definidos en los eventos Endfor Work -Panel sin tabla base: No se mencionan atributos en: Panel Reglas Hidden() y Order() Eventos En este caso se genera sólo un Evento Load, y es en él donde se deben cargar los datos en el subfile, haciendo for each a la (s) tabla(s) deseadas cargando las variables del form.

Diálogo Modal/No Modal Property Modal dialog En transacciones y work panels (llamados). Opciones: Yes if parameters specified Yes No Sólo generadores Visuales. La property Modal Dialog permite elegir si el diálogo sera modal o no modal para ese objeto. Las opciones de esta property son: Yes if parameters specified: Es la opción por defecto. Significa que si el objeto tiene parámetros, el diálogo será modal y si no tiene el diálogo sera no-modal. Yes: Dialogo modal. No: Dialogo no modal.

SUBTIPOS

Subtipos Ejemplo: Transferencias entre Bancos. Atributos similares que cumplen roles diferentes. Transacción de Bancos: BcoCod* Código de Banco BcoNom Nombre de Banco Transacción de Transferencia : TrnNro* Número de transacción TrnFch Fecha ‘Problema’ BcoCod Banco Origen Atributos BcoNom Nombre del Banco Origen con el BcoCod Banco Destino mismo BcoNom Nombre del Banco Destino nombre TrnImp Importe Hay que definir el banco origen y destino en la misma transacción. Esto no es correcto pues tengo que poner atributos con el mismo nombre en la misma transacción. Para estos casos GeneXus provee los Subtipos, los cuales permiten definir que dos atributos que se llaman diferente, corresponden al mismo concepto.

Transferencia: TrnNro* TrnFch Subtipos Bancos: TrnBcoOriCod BcoCod* TrnBcoOriNom BcoNom TrnBcoDestCod TrnBcoDestNom Subtipo Supertipo TrnBcoOriCod BcoCod TrnBcoOriNom BcoNom TrnBcoDestCod BcoCod TrnBcoDestNom BcoNom Hay que definir atributos con distinto nombre y que tengan una dependencia funcional. Los atributos que se encuentran en una relación Subtipo/Supertipo siempre comparten la misma definición. Se realizan los controles de integridad referencial. La tabla extendida que se obtiene con la definición del subtipo, es la misma que se obtendría en el caso que se utilizara directamente el supertipo.

Subtipos: Grupos Almacenado TrnBcoOriCod Grupo TrnBcoOri Inferido TrnBcoOriNom Almacenado TrnBcoDestCod Grupo TrnBcoDest Inferido TrnBcoDestNom Todavía queda algo por determinar. Tenemos dos bancos y dos nombres pero en ningún lugar indicamos el nombre a que banco corresponde. Es acá donde aparece la necesidad de definir grupos. Decimos que el Código de Banco Origen y el Nombre pertenecen al mismo Grupo.

Algunas Consideraciones El subtipo y supertipo serán definidos del mismo tipo, GeneXus lo determina así y cuando se quiere definir un subtipo este "hereda" la definición del supertipo. No incluir subtipo y supertipo en la misma transacción, ni tampoco en la misma tabla extendida. No se pueden actualizar los subtipos inferidos (Add, Subtract). No se pueden definir redundantes los subtipos inferidos. Por ejemplo: TrnBcoOriNom

DATA VIEWS

DataViews - Archivos Externos Los Data Views de GeneXus permiten manejar Archivos Externos como si fueran Archivos pertenecientes a la Base de Conocimiento. Propiedades Definición Global Uniformización de la nomenclatura

DataViews - Archivos Externos Para trabajar con Archivos Externos en GeneXus tenemos dos posibilidades: DATA VIEWS Sin tabla Asociada Con tabla Asociada

Data Views SIN TABLA ASOCIADA CON TABLA ASOCIADA GENEXUS DATABASE DATA VIEW DEFINITION EXTERNAL ENVIRONMENT EXTERNAL FILE SIN TABLA ASOCIADA Los Data Views de GeneXus permiten manejar Archivos Externos como si fueran archivos pertenecientes a la Base de Conocimiento. En el Data View se puede indicar que se manejará una transacción interna asociada, o no. Data View con transacción interna asociada Supongamos que desde una Base de Conocimiento se desea manejar el archivo externo clientes.dbf cuyos campos son: - Codigo* - Nombre - Dir - Tel 1) Se debe crear una transacción de clientes definiendo los atributos que se deseen manejar de la tabla externa. Estos atributos internos deben coincidir en lo que se refiere a tipos y tamaños con los campos externos, pero los nombres pueden ser redefinidos respetando la nomenclatura GIK. INTERNAL TABLE EXTERNAL FILE CON TABLA ASOCIADA

2) Se debe crear un Data View e indicar en él, cual es la transacción interna asociada. Asimismo se deben indicar las correspondencias entre los atributos internos y los campos externos. También se debe ingresar en el Data View, información relacionada al Archivo Externo como ser la plataforma y ubicación (esto debe ser indicado tanto en el caso que el Data View tenga una transacción interna asociada, o no). 3) Los objetos GeneXus deben definirse haciendo referencia a los atributos internos de los clientes, sin embargo los programas son generados utilizando los campos externos en forma transparente. Nota: Si bien se define una transacción de clientes, esta no provoca la creación de una tabla física por estar asociada a un DataView. Esta transacción se especifica y genera como cualquier objeto de la Base de Conocimiento y en ejecución, accede en forma interactiva a los registros de la tabla externa en forma transparente. Data View sin transacción interna asociada En este caso, se debe crear un Data View, sin crear previamente una transacción interna. La forma de acceder al Archivo Externo es únicamente mediante la definición de procesos batch utilizando los External File Commands: XFOR EACH, XNEW, etc.

Definición de un Data View Assoc. table: En este punto se debe seleccionar la tabla interna asociada al Data View. Composition: Aquí se deben indicar las correspondencias entre los atributos internos y los campos externos. [Nombre Interno] [Nombre Externo] Cuando no se menciona el Nombre Externo es porque coincide con el Nombre Interno. En el ejemplo, el nombre y la dirección del cliente en el Archivo Externo se llaman CliNom y CliDir respectivamente. Indices: En esta lista, se deben definir los índices internos que GeneXus usará en la aplicación. Plataform Specific Information: Aquí se debe completar información del archivo externo (como ser la plataforma y ubicación).

Composition Ejemplo: Dados los siguientes Archivos Externos: CLIENTES PRODUCTO Codigo* Codigo* CliNom ProDsc CliDir ProPre Composition Composition CliCod 'Codigo' ProCod 'Codigo' CliNom ProDsc CliDir ProPre Se uniformiza la nomenclatura

Indices Name: Nombre del índice que GeneXus usará en la aplicación. Unique o Duplicate: Si permite tener o no llave duplicada. Compositions: Es la lista “ordenada” de campos que componen al indice. Los atributos mencionados acá deben ser parte de la Composition del Data View.

Platform Specific Information / Add Las propiedades del Data View pueden definirse para cada plataforma o por modelo. Esto nos brinda la posibilidad de especificar diferentes ubicaciones del mismo Data View dentro de la misma plataforma pero para diferentes modelos. Por ejemplo, si se quiere darle diferente ubicación para el modelo de Prototipo Fox y para el modelo de Producción Fox, debe seleccionarse DBFCDX(model2) y DBFCDX(model 3) indicando la ubicación para cada uno de los modelos. En cambio, si se quiere la misma ubicación para todos los modelos Fox debe seleccionarse la plataforma DBFCDX.

Platform Specific Information / Edit Estas propiedades varían dependiendo de la plataforma seleccionada. En este caso, por ejemplo, el archivo externo es un archivo de texto y por tanto las propiedades son referentes a un archivo de este tipo.

Associated Table - - - - - - - - - - - - - - - - - - - - - - - - - GENEXUS DEVELOPMENT ENVIRONMENT GENEXUS DATA VIEW EXTERNAL MODEL DEFINITION ENVIRONMENT - - - - - - - - - - INTERNAL EXTERNAL TABLE FILE - - - - - - - - - - Data View con Tabla Interna Asociada Se trata al archivo externo como una tabla más del modelo. Se pueden utilizar los mismos comandos utilizados para acceder a las Tablas Internas (For Each, etc.) Se deben mencionar los atributos internos y Genexus al generar los programas, utilizará los campos externos de forma transparente. - - - - - - - - - - - - - - - - INTERNAL EXTERNAL INDEX - - - INDEX - - - -

Associated Table - - - - - - - - - - - - - - - - - Tabla Interna = Tabla Externa - - - - - - - INTERNAL TABLE EXTERNAL FILE - - - - - - - - - - Existe una relación de uno a uno entre los atributos de la Tabla Interna del Data View y los del Archivo Externo.

Associated Table - - - - - - - - - - - Tabla Interna < Tabla Externa EXTERNAL FILE Not Accessed - - - INTERNAL - - - - - TABLE Los atributos definidos para la Tabla Interna y para el Data View coinciden, pero el Archivo Externo tiene atributos no declarados en el Data View. Estos atributos no pueden ser accedidos. - - -

Associated Table - - - - - - - - - - - - - Tabla Interna > Tabla Externa GENEXUS DATA VIEW EXTERNAL DATABASE DEFINITION ENVIRONMENT - - - - NOT ALLOWED Si la Tabla Interna tiene más atributos que el Archivo Externo no es válida la asociación. INTERNAL FILE EXTERNAL FILE - - - - - - - - -

Associated Table - - - - - - - - - - - Tabla Interna > Tabla Externa USO DE SUBTIPOS GENEXUS DATA VIEW EXTERNAL DATABASE DEFINITION ENVIRONMENT - - - - CliCod* CliNom Codigo Nombre ALLOWED - - - INTERNAL TABLE A EXTERNAL FILE En el ejemplo, se pide tener también como datos del Cliente el E-Mail y la dirección. - - - - Subtype CliCodSub* CliNom CliDir CliEMail INTERNAL TABLE B

Asociación Dinámica Las definiciones del Archivo Externo e índices asociados coinciden con las definiciones de la Tabla Interna y sus índices (tanto en nombres como en la composición). En este caso coincide todo. Si ocurre esto no hay que detallar composición ni de índices del Data View. Lo único que hay que hacer es asociar el Data View a la tabla externa (Platform Specific Information). Tener en cuenta que el índice y archivo externo deben estar ubicados en el mismo directorio.

Arbol de Definición Archivos Externos Data View Definición Global SIN Tablas Asociadas CON Tablas Asociadas Asociación Dinámica Asociación Definida

REORGANIZACIONES - DATA VIEWS 1. EXISTE TABLA ASOCIADA Si cambia la estructura de la tabla asociada, el cambio es detectado en el Análisis de Impacto. No se generan programas de reorganización. 2. NO EXISTE TABLA ASOCIADA No aparece en el análisis de impacto.

EFICIENCIA Y PERFORMANCE DE LAS APLICACIONES

Puntos a Considerar Optimización de la Entrada-Salida Uso de Calls Open y Close de archivos Uso de Indices Temporales Optimización de Entrada-Salida: Dado que el acceso a las tablas es costoso, vamos a ver cómo minimizarlo. Uso de Calls: Vamos a ver cuándo debemos empezar a preocuparnos por el uso de este comando. Open y Close de archivos: Cuánto y cómo influyen las operaciones de apertura y cierre de archivos en el tiempo de respuesta de nuestra aplicación. Uso de índices temporales: Evaluación del costo de creación de índices temporales vs. el costo de mantenimiento de índices permanentes.

Optimización de Entrada-Salida Definición de Filtros Peor Estrategia Estrategia Optima Begin of File Begin of File READ READ < Start Point READ READ READ READ READ < End Point READ End of File End of File Normalmente los programas procesan registros agrupando aquellos que tengan ciertas caracteristicas comunes, por ejemplo, todas las facturas de un determinado cliente, o las ventas de una clase de artículos. Estas caracteristicas comunes, se establecen a traves de condiciones que determinan un filtro sobre los registros. Tales condiciones se especifican en GeneXus de diversas formas; asi pueden ser por ejemplo WHEREs en un FOR EACH, condiciones en una formula Aggregate/Select, parametros , etc. Ejemplo: De todos los Clientes, quiero imprimir los datos de aquellos cuyo código este en un rango determinado. El tiempo necesario para realizar el proceso con los registros que cumplen las condiciones, determina el grado de "optimización" que tiene la estrategia de acceso elegida. Decimos que una estrategia de acceso esta más "optimizada" que otra, cuando es necesario un menor tiempo para leer todos los registros que cumplen las condiciones establecidas. La optimización consiste en posicionarse lo mas cerca posible del primer registro del grupo que cumple las condiciones y desde alli leer secuencialmente hasta el último que las cumpla. Lo que se establece en definitiva, es un intervalo que cubre todos los registros que cumplen las condiciones. En este intervalo no necesariamente todos los registros cumplen la condición.En estos casos, la mejor estrategia consiste en tener el menor intervalo tal que cubra a todos los registros que cumplirán la condición. Igualmente las lecturas se realizarán para todos los registros de este intervalo, pero solamente se considerarán aquellos que cumplan con las condiciones.

Cláusula Where en For Each Definición de Filtros Cláusula Where en For Each Conditions en Prcs, Rpts, Wkps. Parm() en Trns, Prcs, Rpts, Wkps Where: La clausula "Where" permite filtrar registros en la navegación de un determinado grupo FOR EACH. Por ejemplo: Para establecer los filtros descritos anteriormente, utilizaríamos la siguiente especificación: FOR EACH W HERE CliCiu = 'Montevideo' .AND. CliCod >= 1 .AND. CliCod<= 100 ... ENDFOR Conditions: Las "Conditions" sirven para establecer un filtro en forma global, es decir que solamente se podrá acceder a los registros que cumplan con esta condición. Cuando se establece una condición sobre atributos, afecta a todos los grupos FOR EACH que contengan ese atributo. Reports, Work-panel y Procedures poseen esta posibilidad. Se prevee la implementación a nivel de Transacciones en próximas versiones. Parámetros: Es otra forma de establecer una condición en forma global, pero solamente por igualdad. Cuando se recibe un parámetro en un atributo, obtenemos una especificación equivalente a una condición, por ejemplo: Tenemos un procedimiento que tiene la siguiente regla: Parm(CliCod); esta regla es equivalente a tener: parm(&Cliente);y la condición:CliCod = &Cliente;

Definición de la estrategia de acceso. 1ero.) Se define el orden en que se recorrerá el archivo 2do.) Se elige el punto de comienzo (Starting point) 3ero.) Elegir la posición final ( End Point). 4to.) Leer secuencialmente los registros entre el punto inicial y el punto final, seleccionando los registros que cumplen las condiciones y descartando los restantes. Definición de la estrategia de acceso con GeneXus Para definir una buena estrategia de acceso, GeneXus cuenta con una inteligencia razonable. A contínuación se explica cómo se decide la estrategia a partir de las especificaciones realizadas. Se determinará, estableciendo ( de acuerdo a las condiciones y el orden en que deban considerarse los registros), una posición inicial y una posición final en el archivo, leyendo en forma secuencial en este intervalo. Se realizará entonces lo siguiente: 1. Determinar el orden de recorrida del archivo 2. Fijar la posición de comienzo (Start). Posicionarse lo más cerca posible del primer registro que cumple las condiciones. 3. Leer secuencialmente, descartando los registros que no cumplan las condiciones, hasta alcanzar la posición de fin. 4. Fijar la posición de fin (End). Se dice de aquellas condiciones, tales que a partir del primer registro que no las cumple, no existen más registros que sí la cumplan.

Orden de Recorrida Importancia del Orden en que se leen los registros. Ejemplo: Condiciones de Filtro compatibles con el Orden For each Order CliCod Where CliCod >= &IniCod .and. CliCod <= &FinCod .... Endfor Cod Nombre 1 Smith * 2 Jones <----- Starting Point Read &IniCod = 2 * 3 Ball Read &FinCod = 4 * 4 King <----- Ending Point Read 5 Ander El orden en que deban considerarse los registros, junto con las condiciones de "filtro" determinarán la mejor estrategia de acceso. El orden puede considerarse como una condición previa, para la definición de la optimización de las condiciones de filtro. Es decir, que la estrategia de acceso se define, tomando en cuenta como primera cosa el orden que se haya definido.

Orden de Recorrida Importancia del Orden en que se leen los registros. Ejemplo: Condiciones de Filtro no compatibles con el Orden For each Order CliNom Where CliCod >= &CodIni .and. CliCod <= &CodFin . . . Endfor Cod Nombre *3 Ander <----- Starting Point Read &CodIni = 2 5 Ball Read &CodFin = 4 6 Churchill Read 1 King Read *4 Smith Read *2 William <----- Ending Point Read

Orden de Recorrida Si no se define un Orden se elige el de la Primary Key Ejemplo: Nombre inicial : &IniNom Nombre final : &FinNom For each Where Clinom >= &IniNom .and. Clinom <= &FinNom Endfor Orden elegido --> CliCod Cuando no se define un orden: Se debe tener en cuenta que el no especificar un orden, no implica que GeneXus lo elegirá de forma que optimice las condiciones definidas. Sino que se tomará el orden de la clave primaria y en base a este orden se optimizarán las condiciones que sean posibles. Excepción: Existe un caso en el que se puede elegir un índice diferente al de la clave primaria, y es en el de anidamiento de FOR EACHs, cuando existe una relación entre atributos primarios de los mismos. En este caso el FOR EACH anidado elegirá el orden de acuerdo a las condiciones de filtro establecidas por su relación con FOR EACHs anteriores. Ejemplo: Clientes CliCod* Tipos TypCod* CliNom TypNom TypCod Tenemos Clientes y Tipos de clientes, y queremos listar los tipos de clientes y los clientes de cada tipo, haremos la siguiente especificación: For each [TypCod] [TypNom] [CliCod] [CliNom] Endfor Como primera cosa, GeneXus infiere que los clientes que queremos recorrer son aquellos del tipo (TypCod) que acabamos de considerar en el FOR EACH anterior. Es decir, que hay una condición implícita que indica que:Tipos.TypCod =Cliente.TypCod

Posición de Comienzo Consideraciones para su definición. Se consideran las condiciones compatibles con el orden y que sean por: Si el orden es ascendente Mayor (>) Mayor o Igual ( >=) Igual (=) Si el orden es descendente Menor (<) Menor o Igual (<=) Igual(=) Las condiciones deben estar relacionadas por .And.

Posición de Comienzo Ejemplos: Orden: A B C Condiciones : A>= 5 .and. C > 3 Posición de comienzo: A>=5 Condiciones : A > 5 .and. B < 2 .AND. C > 3 Posición de comienzo: A > 5

Consideraciones para su definición La Posición Final Consideraciones para su definición Se consideran las condiciones por: Si el orden es ascendente Menor (<) Menor o Igual (<=) Igual (=) Si el orden es descendente Mayor (>) Mayor o Igual (>=) Las condiciones deben estar relacionadas por .And.

Diagrama de Navegación For each CliCod Where CliCod >= &IniCli .AND. CliCod <= &EndCli [ CliCod ] [CliNom ] Endfor FOR EACH Clientes Order : CliCod Index : ICliente Navigation filters: Start from: CliCod >= &IniCli Loop While CliCod <= &EndCli Constraints: CliCod >= &IniCli .AND. CliCod <= &EndCli ---->> CLIENTES ( CliCod ) END FOR

Diagrama de Navegación For each CliCod [ CliCod ] [CliNom ] Endfor FOR EACH Clientes Order : CliCod Index : ICliente Navigation filters: Start from: First record Loop while: Not end of table ---->> CLIENTES ( CliCod ) END FOR

También influyen en la performance: Calls Apertura y Cierre de Archivos Uso de Indices Temporales - Calls : ¿En qué casos deberíamos considerar el costo de la ejecución de un Call? En la gran mayoría de los casos no es necesario que nos preocupemos por esto. Sin embargo en algún caso eliminar ¨Calls” puede significar la diferencia entre una buena y una mala performance ( ya que no tiene el mismo costo que hacerlo todo en un único programa que en varios ). Generalmente, éstos comienzan a ser un problema cuando lo que se tiene no es una única llamada a otro programa sino que son varias. En C/S, el tiempo de un call no es considerable ya que se van abriendo cursores sin preocuparse de cerrarlos hasta el final de la ejecución de la aplicación o si.no si se llegó al límite de cursores para usar, los que ya fueron usados, son marcados como borrables, a fin de cerrarlos sólo si es necesario, si se vuelven a utilizar la definición ya está, por lo que el tiempo de creación disminuye. En File/Server, se cierran o abren los índices dependiendo de los indices utilizados. En NTX e IDX, si es necesario usar un indice que esta abierto, primero se cierra y luego se vuelve a abrir. Si es CDX, no cierra el indice sino que se reposiciona usando el mismo-. Ejemplo:Para cada cuenta, que cumpla las condiciones se llama a otro programa. Supongamos que las cuentas en las condiciones establecidas son 10.000, entonces se realizarán 10.000 "Calls", lo que seguramente tendrá una costo importante en el tiempo total del proceso.

MULTIPLES FORMS

Múltiples Forms por Objeto Poder tener N pantallas por objeto. Permitir dentro de una misma KB tener modelos en los que se genera para ambiente gráfico y otros en los que se genera para ambiente caracteres. 41 42 45 45

Form Classes Create automatically in new objects: Significa que cada vez que se crea un nuevo objeto, automáticamente se crea un form de esa clase en el mismo. Cuando se importa, se genera automáticamente un form para cada clase que sea Autocreate. Puede haber una o más classes Autocreate. Create Reports and Procedures using “Form que se seleccione”: Como en reports y procedures no hay multi-form, se elige entre el Graphic y Text. New Class: Classes definidas por el usuario que pueden ser tanto Graphic como Text.

Múltiples Forms por Objeto Form Classes Graphic y Text (son del sistema) Definidas por el usuario (modo texto o gráfico) Cada objeto tiene forms que pertenecen a alguna de las form classes y cada Modelo tiene asociado una lista de Form Classes para cada generador del mismo. Opción: File/ Edit Model/ Model Forms Las Form Classes y sus propiedades son globales a la KB (File/Form Classes), pero se pueden editar desde cualquier modelo. A su vez, en cada modelo se puede definir una lista de form classes de preferencia (File/Edit Model/Model Forms) para cada generador del modelo. El default de un form puede ser en base a otro form o en base al default de Genexus.

¿Cuándo decide GX el form a utilizar ? En tiempo de Especificación Apertura del objeto Apertura del objeto: para decidir cual mostrar en forma inicial. La lista de forms del modelo se tiene en cuenta en 2 casos: 1.- Al especificar un objeto, para decidir cuál form considerar Para cada objeto, se toma la primer form class de la lista del modelo y se busca si existe en el objeto un form de esa clase. Si no existe, se busca de la form class que sigue en la lista y así hasta encontrar o que se acabe la lista. Si se acaba la lista y no se encontró, entonces de acuerdo al generador (gráfico o de caracteres) se busca un form que sea de ese tipo, si tampoco se encuentra entonces se especifica cualquiera y en el caso que haya que convertir, se convierte a texto. En cualquier caso, en el reporte de la especificación aparece cuál fue la form class que se eligió para cada objeto. 2.- Al abrir el objeto, para decidir cuál mostrar en forma inicial

STYLES

Propiedades de los Styles Permiten la definición de standards. La definición es “por tipo” de objetos (transacciones, work panels, etc). Objeto GeneXus no tenido en cuenta al normalizar. Los Styles son otro objeto GeneXus, su forma de definir es similar a la de los otros objetos, pero con la particularidad de que NO son tenidos en cuenta en la normalización o generación de programas. Sólo se utilizan para definir standards, sin la necesidad de tener que diseñar Form por Form. Pueden ser modificados, y automáticamente se reactualizan los forms necesarios. Hay Styles para transacciones, work panels, etc. , pero un style es de un solo tipo. Las excepciones a esta regla son los Styles de Work Panels que sirven también para Prompts y los Styles de Report y Procedure que pueden usarse para cualquiera de los dos. Nota: No existen Styles de Styles

Definición de un Style Object/New Object. Ejemplo de un Style de transacción.

Style Style Area Data Area Se ven en los forms unas líneas que definen diferentes áreas. Lo que está dentro del rectángulo es la denominada "Data Area" (área de datos). El resto del form es la "Style Area". A su vez, la Style Area está dividida en 8 sectores (ver figura). Cuando el desarrollador empiece a usar styles las lineas de la data area aparecerán solas. De todas maneras también se pueden hacer aparecer con un botón de la toolbar. Los controles que están completamente comprendidos en un sector conservan su posición relativa a éste, cuando se mueven las líneas. Aquellos controles que pasan desde un lado de una línea hacia el otro, conservan su posición relativa a la línea (se mueven junto con la línea). Si un control pasa por encima de 2 líneas paralelas (o dicho de otra manera, comienza antes de la línea de borde izquierdo de la data area y termina después de la línea del borde derecho, o bien la misma situación con respecto a los bordes superior e inferior), pueden suceder dos cosas: A). Es un control con "autoresize". En este caso, el control mantiene su posición relativa a la primera de las líneas que cruza. B). Es un control sin "autoresize". El control se agranda o se achica tanto como se separen o acerquen las líneas, manteniendo cada uno de los extremos del control su posición relativa a la línea más cercana. Este espacio se puede usar para poner comentarios

Tres Tipos de Controles Controles que vienen de la default Data Area Los que vienen del Style Controles del Usuario Los que agrega el usuario al objeto. Los que vienen de la data area del Style. Los controles en la Data Area del style se pasan al objeto sólo en caso de inicialización (cuando el objeto es creado basado en el style y no en futuras reaplicaciones) y una vez en el objeto es considerado como un control de usuario dentro de éste.

Creación de un objeto basado en un Style Al momento de crear el objeto, en el Information/Style se elige el Style deseado. Relación entre las partes del objeto y del Style: Form y Properties: Relación dinámica Otras partes del objeto: Relación estática Dinamismo con las properties Los objetos heredan las propiedades del style asociado El dinamismo es “por property” Cuando se crea un objeto con un Style asociado, el objeto se inicializa con todas las partes del Style (a excepción del Information, obviamente). Excepto para el Form y las properties, la relación entre las partes del objeto y del Style es estática (si se cambia el Style no se cambia el objeto). Pero tanto para el Form como para las properties puede ser dinámica (que por ejemplo, cuando se cambie el Form del Style se cambie el form del objeto). En el caso de las properties, el dinamismo se mantiene en forma independiente para cada property. Cuando el objeto es creado sin especificar un Style asociado, GeneXus considera de todas maneras para el form la asociación a un Form Style Default. Es decir que aunque el objeto no tenga Style asociado, a los efectos del form es como si estuviera asociado a un Style Default. Cuando se crea un objeto, se tiene Syle dinámico, pero dinamismo con la default data area sólo si el objeto es un transacción. En las próximas transparencias veremos cómo es que se pierde el dinamismo. El estado de dinamismo se puede ver por el color con el que están dibujadas las líneas. Si son rojas, está dinámico. Si no está dinámico, son azules.

Creación de un objeto basado en un Style Las líneas de la data area estan en azul indicando que se perdió el dinamismo con la default data area. Las lineas de la style area estan en rojo indicando que existe dinamismo entre la style area de la transacción de clientes y la style area del style. NOTA: Se puede perder el dinamismo con la style area del Style y seguir teniendo dinamismo con las properties del Style (siendo esto último “por property”; es decir, teniendo dinamismo con algunas properties y no con todas).

Cómo asociar Styles a objetos existentes Opciones Information/Style Reapply Form Style Cuando se crea un objeto nuevo con un Style asociado, el objeto es inicializado con todas las partes del Style. Cuando el objeto ya existe, y se le asocia un Style, lo único que hereda de éste es el Form y las Properties (sólo las properties que tienen en el objeto los valores por default), siendo el dinamismo de las properties “por property” (se respetan las otras partes del objeto: Event, Rules, etc.). En otras palabras, es útil asociar un Style a un objeto existente cuando se quiere utilizar sólo los Form del Style y las properties del Style en el objeto. Para asociar un Style (o cambiar el Style asociado) a un objeto ya existente se debe editar la "Information" del mismo, seleccionando alli el Style deseado. Para aplicar el Style a cualquiera de los forms del objeto se usa el menu Edit / Reapply Form Style. Antes de aplicar el Style, hay que tener en cuenta que aquellos controles que no provenían del Style asociado anteriormente (controles del usuario), permanecerán en el form del objeto, con lo que pueden ocurrir superposiciones.

Qué pasa con el dinamismo ? Cuando se pierde ? Cuando se modifican los controles que vienen de la DDA los controles que vienen de la “style area” del Style el seteo de una property Opciones: Edit \ Default Data Area Edit \ Reapply Style Form Si se modifica un control que figura en el form como resultado del cálculo de la Default Data Area (control que viene de la DDA), se pierde el dinamismo en ésta (por ej.: si en una transacción se modificó uno de los controles correspondientes a los atributos de la estructura, al agregar nuevos atributos en la misma no aparecerán automáticamente en la Data Area). Análogamente, si se modifica cualquiera de los controles que vienen de la style area del Style, se pierde el dinamismo con el Style. Si se modifica el valor de una property en el objeto, entonces se pierde el dinamismo con “esa property” del style. No se pierde ninguno de los dinamismos al agregar nuevos controles (ya sea en la Data Area o en el Style Area) del objeto que se está diseñando. Estos controles se consideran “de usuario” . Tampoco se pierde ninguno de los dinamismos al modificar o borrar cualquiera de los controles “de usuario”. Una vez que se pierde el dinamismo con la Data Area o con el Style, se puede recuperar utilizando las opciones de menu Edit – Default Data Area y Edit – Reapply Form Style, respectivamente.

Cambio en el tamaño de la Data area Para agrandar o achicar la data area, sólo sirve mover los bordes derecho y/o inferior. El form del Style tiene la capacidad de adaptarse al tamaño de la Data Area del objeto en el que se lo utiliza. Cuando la Data Area se agranda (ya sea debido al calculo de Default Data Area o a la accion del usuario) el mecanismo de aplicacion dinamica del Style se encarga de agrandar tambien el frame, y mover hacia la derecha y hacia abajo los controles que estan a la derecha y abajo de la Data Area respectivamente. Similar comportamiento se observa al achicar la Data Area (se achica el frame y los controles se mueven hacia la izquierda y hacia arriba). El tamaño de la data area definido en el form del style (y por lo tanto también el tamaño del frame) se considera como tamaño mínimo de la data area del form del objeto.

Consideraciones para el diseño de Styles Los controles que queden dentro de la Data Area del Style son considerados como “Controles del usuario”. Definir forms para diferentes form classes si los objetos que lo usan tienen múltiples forms. (Ej.: definir un form gráfico y uno de texto en el style). Cuando se ponen Eventos y Rules incluir comentarios al principio sobre que cambios se deben realizar en el objeto. Cuando se ponen Evento y Rules, incluir comentarios al principio sobre qué cambios se deben realizar en el objeto. Por ejemplo, en las rules de un Style para transacciones poner: //sustituir “clave” por el nombre del atributo clave noaccept(clave)

Master Style Objetivo: Style default Se define por modelo Por “tipo de objeto” salvo: Prompt - Workpanel Report/procedure - report/procedure definidos en forma independiente para cada modelo dentro de la KB. File/Edit Model/Master Styles Master Style Existe la posibilidad de declarar, para cada tipo de objeto, cuál de los styles existentes en el modelo se desea que sea considerado como Master Style (es decir, cuál se desea utilizar en lugar del “default style”). No es que se tenga que “crear un Master Style” sino que entre aquellos que ya existen, se puede elegir uno y declararlo como Master. Esta declaración es de caracter opcional: es posible no declarar a ninguno como Master y simplemente funcionará todo como hasta ahora (utilizando el “default style”). En File/Edit Model/Master Styles se designa el Master Style para cada tipo de objeto. En cada caso están disponibles los styles existentes y la opción “(None)”. Si bien al momento de crear un objeto style, se puede elegir tanto crear un Report Style como un Procedure Style, el tipo del style que en definitiva se crea es siempre Procedure Style. Los Procedure Style pueden ser usados como style tanto para Reports como para Procedures. De la misma manera pueden ser elegidos tanto como para Master Style de Reports como para Master Style de Procedures. Por otro lado, los Work Panel Style pueden ser usados como style tanto para Work Panels como para Prompts.

Master Style Precedencia: Style asociado Master Style Default

MENU BAR Y TOOL BAR

Tipo de objeto Menu Bar Para definición de Menu Bar y Tool Bar Object/New Object/Menu Bar Add y Delete de Items Edit/Insert y Edit/Delete respectivamente Subitems Personalización del item Help/About Sólo en generadores gráfico: VB, VFP JAVA (en un futuro) Cada objeto GeneXus que tenga Form puede tener su propio Menu Bar y Tool Bar. Para definirlos, se usa el tipo de objeto GeneXus Menu Bar. Para agregar o borrar opciones (items) del Menu Bar, se utilizan las opciones Edit/Insert y Edit/Delete respectivamente. La definición de la Tool Bar es exactamente igual a la del Menu Bar, sólo que en los items de la Tool Bar se debe definir también el bitmap correspondiente. El item Help/About llama a un work panel GX_ABOUT. GeneXus por defecto ya provee este work panel, en caso de querer personalizarlo se debe crear un nuevo work panel con este mismo nombre con la información deseada.

Tipo de objeto Menu Bar Definición de Eventos Cada item sin subitems puede tener asociado un evento (Object/Events). Nombre del evento: palabra Menu Bar + nombre del Item Son generales No se permiten atributos. En transacciones y work panels Property Windows Interface/Menubar : *Default, *None, lista de Menu Bars existentes Pueden programarse eventos para los items del Menu Bar. Son particulares Se permiten atributos. Los eventos definidos en el Menu Bar son generales, por lo cual se ejecutarán en todos los objetos que utilicen el Menu Bar. Por esta razón es que no se permite el uso de atributos en los mismos. Luego de definido un Menu Bar, se debe indicar en que objetos se utilizará. Esto se indica con la property Windows Interface de las transacciones y work panels. En las transacciones y work panels que utilicen el Menu Bar definido, se pueden programar eventos para los items del Menu Bar . Como estos eventos son particulares de cada objeto, sí se pueden usar atributos. Si un mismo evento se programa en el Menu Bar y en el objeto, se ejecuta el del objeto.

PROPIEDADES, EVENTOS Y METODOS ASOCIADOS A LOS CONTROLES

PROPIEDADES DE LOS CONTROLES Cada control en un Form tiene un ‘nombre’ y ‘propiedades’ asociadas. Insert/Property: despliega la lista de propiedades válidas para cada control. Según el tipo de control, las properties que tiene asociadas. Sólo en generadores gráficos: VB, VFP JAVA (en un futuro) Algunos controles tienen un nombre por defecto, pero hay otros que no; por lo cual si se les quiere aplicar alguna property hay que asociarles un nombre ya que de lo contrario no aparecen en la columna “Control” al hacer Insert/Property. En el caso del Form el nombre del control (por defecto) es Form. Si se desea cambiar el título de un Form, la forma es: Form.Caption=‘Datos del Cliente’ + CliNom En el caso de un control tipo texto, se le debe dar un nombre.

Propiedades de los Controles El ‘nombre del control’ para atributos/variables es el nombre del atributo/variable. NOTA: Si una variable es un vector, debe indicarse un nombre a cada posición del vector para diferenciarlas.

Diálogo: Select Property Se accede a través de la opción Insert/Property cuando se editan: Rules, Eventos, Subrutinas, etc en transacciones, work panels y web panels No disponibles en reports y procedures

Diálogo: Select Property Form: Permite seleccionar para que tipo de form (Graphic, Text o de Usuario) se le asignará una propiedad a un control. Control: Muestra la lista de controles que hay en el form que se está diseñando y que tienen un nombre asociado. Property: Despliega la lista de propiedades que se pueden aplicar al control seleccionado y en la segunda columna se despliegan los tipos de cada property. El Help trae el Help de la property seleccionada

EVENTOS EN CONTROLES Insert/Events Permite asociar Eventos a cada Control. DblClick Click RightButton IsValid GotFocus OnLineActivate DblClick: El código asociado a dicho evento se ejecuta al hacer “doble click” sobre el campo. Click: El código asociado a dicho evento se ejecuta al hacer “click” sobre el campo. Right Button: Se dispara cuando se presiona el botón derecho del mouse. IsValid: Se dispara cuando se hace la validación del control. GotFocus: Se dispara al entrar al campo después de validar el campo anterior.

Evento OnLineActivate Evento asociado al control “subfile” Se dispara cuando se activa una línea en el subfile: al clickear una línea con el mouse moverse a través de la grilla con el teclado cuando se hace refresh de la grilla. Los valores son los de la línea “nueva” Los for each incluidos en este evento se anidan a la tabla base del workpanel. Disponible en transacciones y work panels. OnLineActivate Es un evento asociado al tipo de control subfile. Los For Eachs que se incluyan en dicho evento estarán anidados a la tabla base del work panel, es decir, se comportan igual a los For Eachs del evento Enter.

Eventos en Controles Form: Permite seleccionar para que tipo de form se le asociará una evento a un control. Control: Muestra la lista de controles que hay en el form que se está diseñando. Event: Despliega la lista de eventos que se pueden aplicar al control seleccionado.

METODOS Se aplican a los controles. Sintáxis <Nombre del Control>.<Method> ([<Parms>]) Según el tipo de control (edit, check box, etc) son los métodos que se pueden asociar. Se accede a través de la opción Insert/Methods cuando se editan: Rules, Eventos, Subrutinas en transacciones, work panels y web panels. Sólo en generadores gráfico:VB, VFP, JAVA (en un futuro) A excepción del método SetFocus que será implementado en todos los generadores. La forma de trabajar es similar a la de Properties y Eventos. NOTA: Los generadores texto ignoran los métodos en tiempo de especificación.

OBJETOS MAIN

Objetos Main GeneXus genera ejecutables por cada objeto Main. Cualquier objeto se puede definir como el principal de un ejecutable. Esto, se define en el tab Options del Information del objeto que quiero definir como ejecutable. El ejecutable contiene al objeto en sí y todos los que este llama.

Llamadas a objetos Main Cuando desde un objeto se llama a otro objeto que es Main: GeneXus genera un call a un ejecutable (en lugar de un call común) Son compilables Cuando desde un objeto se llama a un Main, GeneXus genera un call a un ejecutable.

¿Qué ocurre si un objeto que no es Main pasa a serlo? Ejemplo: Trn A Wpanel B Call(PImpClis) Call(PImpClis) PImpClis no es main: GeneXus generó entonces en los programas asociados a la Trn A y Wpanel B un call al programa PImpClis El Proc ImpClis pasa a ser Main: En los programas asociados a la Trn A y Wpanel B GeneXus debería cambiar el call al programa PImpClis por un call a un ejecutable “ImpClis”, con lo que deberíamos regenerar estos objetos. Para evitar la regeneración de todos los objetos llamadores: GeneXus usa un concepto llamado STUBS

STUBS Cuando el objeto ImpClis pasa a ser Main, GeneXus en lugar de generar un único programa asociado al objeto, realiza lo siguiente: Genera el programa “PimpClis” que sólo contiene el Call al Ejecutable correspondiente Genera otro programa que es el que contiene la lógica del objeto ImpClis y será el principal del ejecutable. Esto permite no tener que regenerar todos los objetos que llaman al objeto ImpClis. Al programa que contiene sólo el llamado al ejecutable se le denomina STUB.

STUBS Tenemos entonces 2 programas generados, asociados a un mismo objeto GX: GeneXus necesita internamente nombrarlos diferentes. Para la denominación del programa STUB se siguen las convenciones de siempre (P=Procs, W=Work Panels etc.) Para la denominación del programa que será el principal del ejecutable (el que contiene realmente el código) se usan las siguientes convenciones: Transacción N Work Panel U Report O Procedure A Menu L Web Panel H Siguiendo con el ejemplo, para el objeto ImpClis, GX generará 2 programas: PImpClis.xxx y AImpClis.xxx (xxx= extensión del generador corresp.) y el ejecutable se llamará AImpClis.exe

WEB PANEL Permite construir páginas WEB dinámicas que interactúan con la base de datos. C/SQL Con todos los DBMS, excepto AS/400 Visual Basic Access RPG/400 AS/400 Los web panels pueden generarse tanto con Visual Basic como con C/SQL. Por lo tanto, pueden ejecutarse en un servidor Windows NT (VB, C/SQL) o en servidores UNIX (usando C/SQL). En caso de generar con RPG, el servidor de Internet debe ser al AS/400 Pueden usar todas las bases de datos soportadas. Restricción: Con el generador C/SQL no puede usarse el dbms AS/400.