apostila completa

5/7/2018 Apostila Completa - slidepdf.com

http://slidepdf.com/reader/full/apostila-completa-559abd811f98c 1/425

Curso GeneXus 9.0Diciembre de 2006

MONTEVIDEO – URUGUAY Av. 18 de Julio 1645 P.4 +598 2 402-2082

CHICAGO – USA 400 N. Michigan Ave. Suite 1600 +(312) 836-9152

MEXICO CITY – MEXICO Calle Leibnitz N°20, desp. 801 +52 55 5255-4733

SAO PAULO – BRAZIL Rua Samuel Morse 120 Conj. 141 +55 11 5502 6722



Copyright © ARTech Consultor es S. R. L. 1988-2006.

Todos los derechos reservados. Este documento no puede ser reproducido de ninguna forma sin el consentimiento expresode ARTech Consultores S.R.L. La información contenida en este documento es para uso personal del lector.

MARCAS REGISTRADAS

ARTech y GeneXus son marcas registradas de ARTech Consultores S.R.L.Todas las otras marcas mencionadas en este documento son propiedad de sus respetivos titulares.



Contenido

Introducción teórica........................................................................................................1

Objeto transacción........................................................................................................ 31

Nomenclatura GIK ............................................................................................ ...45

Tipos de datos..................................................................................................... 51

Dominios ............................................................................................................ 55

Análisis de impacto, reorganizar, especificar, generar...............................................64

Modos en ejecución.............................................................................................. 72

Integridad referencial........................................................................................... 73

Índices ............................................................................................................... 76

Manejo de nulos ................................................................................................. 81

Tabla base y tabla extendida ................................................................................ 85

Descripciones en vez de códigos ........................................................................... 89

Reglas................................................................................................................ 94

Tipos de diálogo ................................................................................................ 106

Atributos fórmula ....................................................................................................... 115

Fórmulas horizontales ....................................................................................... 120

Fórmulas verticales ........................................................................................... 123

Comunicación entre objetos......................................................................................... 130

Orden de ejecución de reglas y fórmulas ....................................................................... 139

Eventos de disparo ........................................................................................... 145

Orden de ejecución ....................................................................................151, 152

Eventos en transacciones ................................................................................... 160

Integridad transaccional .............................................................................................. 169

Objetos reporte y procedimiento .................................................................................. 181

Objeto web panel ....................................................................................................... 252

Patterns .................................................................................................................... 312

Subtipos.................................................................................................................... 335

Structured Data Types (SDTs)...................................................................................... 359

Business Components ................................................................................................. 379

Knowledge Manager.................................................................................................... 391

Puesta en producción .................................................................................................. 396

Introducción a metodología GeneXus ............................................................................ 400



Nota al estudiante

Con el objetivo de brindar a los desarrolladores GeneXus una fuente única de información potenciada con unaingeniería de búsqueda que les permita acceder rápida y fácilmente a la información técnica (release notes,manuales, tips, whitepapers, etc.) sobre los diferentes productos que desarrolla ARTech, se creó la GXDL(GeneXus Developer Library), una biblioteca que centraliza toda esta información técnica.

Puede ser consultada online o puede ser utilizada en forma local mediante una sencilla instalación:http://www.gxtechnical.com/gxdl.

Por sugerencias o comentarios acerca de la presente edición, escríbanos a la direcció[email protected].

Departamento de CapacitaciónARTech



INTRODUCCIÓN TEÓRICA



BASE

DE DATOS PROGRAMAS

REALI DAD

Herramientas y Metodologías

Nuestra tarea como profesionales de la informática consiste en desarrollar y mantener aplicacionespara apoyar al usuario en su actividad. Para realizar esta tarea existen diferentes herramientas ymetodologías.

GeneXus es una herramienta para el desarrollo de aplicaciones sobre bases de datos. Su objetivo espermitir la implantación de aplicaciones en el menor tiempo y con la mejor calidad posible.

A grandes rasgos, el desarrollo de una aplicación implica tareas de análisis, diseño eimplementación. La vía de GeneXus para alcanzar el objetivo anterior es liberar a las personas delas tareas automatizables (como el diseño de la base de datos), permitiéndoles así concentrarse enlas tareas realmente difíciles y no automatizables (como comprender los problemas del usuario).

GeneXus emplea una metodología que tiene un enfoque muy diferente al de las metodologías máscomúnmente utilizadas. Por tanto, aprender a utilizar GeneXus adecuadamente va más allá deconocer un nuevo lenguaje: lo más importante es aprender su metodología.



VI SI ONES

DE USUARI OS

Sat is face MODELO DE

LA REALI DAD I ngen ier ía I nversa

Modelado de la realidad apartir de las visiones de

los usuarios

BASE

DE DATOS PROGRAMAS

El primer problema al que nos enfrentamos en el desarrollo de aplicaciones es la obtención delconocimiento de la realidad.

Nadie dentro de la empresa conoce los requerimientos y el alcance de la aplicación a desarrollarcomo un todo. Entonces, ¿cómo logramos obtener el conocimiento de la realidad de una forma losuficientemente objetiva y detallada al mismo tiempo, que nos permita construir un modelocorporativo?

Este conocimiento se encuentra en cada una de las visiones de los usuarios. Cada usuario conocebien los objetos con los que trabaja cotidianamente, la información que se maneja en ellos, lasreglas que deben seguirse, los cálculos que deben realizarse.

Por lo tanto, el punto de partida de la metodología GeneXus es: describir las visiones de losusuarios para modelar el sistema; y a partir del modelo de la realidad definido, GeneXusconstruye el soporte computacional -base de datos y programas- en forma totalmenteautomática.



Comparaciónde

Metodologías

Para fijar ideas, comparemos las metodologías tradicionales más utilizadas actualmente, con lametodología utilizada por GeneXus, conocida como metodología incremental.

Las metodologías tradicionales difieren entre sí en varios aspectos, pero tienen una característica encomún: separan el análisis de los datos del de los procesos .

A continuación veremos un esquema general que podría aplicarse a cualquiera de las metodologías

tradicionales actuales y estudiaremos sus problemas.



Metodología Tradicional



ANÁ LI SI S DE

DATOS

BASE DE

DATOS

ANÁ LI SI S FUNCI ONAL

PROGRAMACI ÓN

PROGRAMAS

GENERACI ÓN/ I NTERPRETACI ÓN

ESPECI FI CACI ÓN

FUNCI ONAL

MODELO DE

DATOS

REALI DA D

La primera tarea que se realiza generalmente es el Análisis de Datos, donde se estudia larealidad en forma abstracta, identificando los objetos existentes y sus relaciones y se obtienecomo resultado un Modelo de Datos con las entidades y relaciones encontradas (ModeloER). Es fácil ver que existe una correspondencia muy simple entre el modelo de datos y labase de datos necesaria para soportarlo. La siguiente tarea entonces, es diseñar esa base dedatos, partiendo del modelo de datos.

Construir un sistema integrado, requiere de un modelo de datos corporativo, y dependiendodel tamaño de la empresa, ésta puede resultar una tarea de enorme complejidad.

Cuando esto ocurre, la complejidad suele atacarse dividiendo el sistema en módulos (“divideand conquer”), cada uno de los cuales soluciona los problemas operativos de un áreaespecífica de la empresa. De esta forma la tarea de modelado se simplifica notablemente,pero como contrapartida los módulos operan sin una real integración, lo que provoca queexista información redundante, con todos los problemas que ello acarrea.

En caso de que luego se intente realizar la integración de esos módulos, habrá que realizarmodificaciones sobre los modelos de datos, lo que a pesar de su complejidad es una tarearealizable. Sin embargo las modificaciones que deberán efectuarse sobre los programasasociados tienen un costo tan elevado que suelen tornar inviable la integración.

Con la división del sistema en módulos la empresa tendrá resueltos sus problemas operativos,

pero aparecerán indefectiblemente problemas de carencia de información que permitaorientar la gestión y la toma de decisiones de alto nivel. En la órbita gerencial la informaciónque se necesita es principalmente de naturaleza corporativa, por lo que la división del sistemaen módulos no satisface las necesidades actuales de obtención de información.

GeneXus soluciona este problema, brindando herramientas y una metodología que hacenposible y sencilla la creación y mantenimiento de sistemas corporativos.



Una vez obtenido el modelo de datos, el siguiente paso de una metodología tradicional es diseñar la base de datos.Existe una transformación trivial entre un buen modelo de datos y el diseño de la base de datos necesaria parasoportarlo.

Sin embargo, el modelo de datos no es suficiente para desarrollar los programas de aplicación, ya que el mismodescribe los datos, pero no los comportamientos. Se recurre, entonces, a una tarea llamada Análisis Funcional,donde se estudia la empresa desde el punto de vista de las funciones existentes, y el resultado de dicha tarea es unaEspecificación Funcional.

Sería deseable que la especificación funcional fuera independiente de la especificación de datos, lo que no ocurre enlas metodologías estudiadas. Las modificaciones en el diseño de la base de datos implican la necesidad de revisar lasespecificaciones funcionales, siendo esta la causa fundamental de los grandes costos de mantenimiento que tienenestos sistemas.

Una vez que se cuenta con la base de datos y la especificación funcional, ya están dadas las condiciones para crear losprogramas de la aplicación.

Para ello se cuenta hoy en día con varias alternativas:

• Programación en lenguajes de tercera y cuarta generación (L3G, L4G)

• Generación/Interpretación

Desde un punto de vista conceptual no hay diferencia entre la programación en lenguajes de 3ra. y de 4ta. generación.En ambos casos el analista debe estudiar el problema, transformarlo en un algoritmo y codificarlo en el lenguaje deprogramación elegido.

La principal diferencia radica en que en los lenguajes de 4ta. generación se escribe mucho menos código(aproximadamente 10 veces menos) y, como consecuencia, la productividad es mucho mayor y el número de errorescometidos es mucho menor.

El problema de que las descripciones de los procesos dependen de la base de datos afecta a ambos por igual, por loque se concluye que los lenguajes de 4ta. generación permiten aumentos de productividad muy grandes sobre los de3ra. en la tarea de desarrollo, pero no ayudan en la etapa de mantenimiento.

Otra alternativa es la utilización de un “generador”: una herramienta que puede interpretar una especificaciónfuncional y producir automáticamente los programas. Aquí existe una diferencia conceptual importante con el casoanterior. En este caso el analista describe el problema de una forma declarativa (no existe algoritmo ni codificaciónprocedural alguna). Por ello la especificación funcional debe ser formal y rigurosa. Existen actualmente en el mercado

varias herramientas de esta clase.

Existe asimismo otra categoría de herramientas conceptualmente idéntica: la de aquellas que simplemente “interpretan” la especificación. La programación en ambos casos es totalmente automática, por lo que el aumento deproductividad sobre las herramientas de 3ra. y 4ta. generación es muy grande.

El problema visto -las descripciones de los procesos dependen de la base de datos- afecta también a las aplicacionesgeneradas mediante estas herramientas. Como consecuencia, los Generadores e Intérpretes (como los lenguajes de4ta. generación) no ayudan lo suficiente en la tarea de mantenimiento.

En definitiva, desde el punto de vista del mantenimiento ninguna de las herramientas ayuda mucho, dado que entodas ellas se utilizan descripciones de procesos que pueden perder su validez cuando existen modificaciones dearchivos y que, por ello, deben ser revisadas y mantenidas manualmente. El costo de mantenimiento, claro está,difiere enormemente entre las distintas alternativas vistas, ya que en el caso de la utilización de Generadores oIntérpretes, una vez modificadas las especificaciones funcionales la generación de los programas es automática.

Si el siguiente postulado: “puede obtenerse una base de datos estable” fuera verdadero, los problemas anterioresserían irrelevantes. Sin embargo, sobran contraejemplos que hablan de lo contrario.

Conclusiones:

No es posible hacer de forma abstracta un modelo de datos detallado de la empresa y con el suficiente nivel de detalley objetividad porque nadie la conoce como un todo. Por el contrario, es necesario recurrir a múltiples interlocutores,cada uno de los cuales aporta su propia subjetividad. Como consecuencia, durante todo el ciclo de vida de la aplicaciónse producen cambios en el modelo.



Aun si se considerara la situación ideal, en la cuál se conocen exactamente las necesidades y por tanto es posibledefinir la base de datos óptima, el modelo, de todas formas, no podrá permanecer estático, ya que debe acompañarla evolución de la empresa.

Todo esto sería poco importante si la especificación funcional y la base de datos fueran independientes. Sinembargo, dado que la especificación funcional se refiere a la base de datos, las inevitables modificaciones en estaúltima, implican modificaciones (manuales) en la primera.

Las principales consecuencias de lo anterior son los altos costos de mantenimiento: en la mayoría de las empresasque trabajan de una manera convencional se admite que el 80% de los recursos que teóricamente están destinadosal desarrollo, realmente se utilizan para hacer mantenimiento de las aplicaciones ya implementadas.

Dado que es muy difícil en este contexto determinar y propagar las consecuencias de los cambios de la base dedatos sobre los procesos, es habitual que en vez de efectuarse los cambios necesarios, se opte por introducirnuevos archivos redundantes con la consiguiente degradación de la calidad de los sistemas y el incremento de loscostos de mantenimiento.



Metodología GeneXus

Los fundadores de ARTech han desarrollado una amplia actividad de consultoría internacional endiseño de grandes bases de datos, trabajando con verdaderos modelos corporativos con cientos detablas.

En su trayectoria, se convencieron de que no debía perderse más tiempo buscando algo que noexiste: las bases de datos estables.

Luego de importantes investigaciones, desarrollaron una teoría, organizaron una metodología eimplementaron una herramienta para posibilitar el desarrollo incremental y permitir la convivenciacon las bases de datos reales –inestables- a un costo mínimo.



Desarrollo con GeneXus

REALI DA D

DESCRI PCI ÓN DE OBJETOS

Utilizando GeneXus, la tarea básica del analista es la descripción de la realidad. Sólo el ser humanopuede desarrollar esta tarea ya que sólo él puede entender el problema del usuario.

El analista GeneXus trabaja en alto nivel, en vez de realizar tareas de bajo nivel como: diseñararchivos, normalizar, diseñar programas, programar, buscar y eliminar los errores de los programas.

Para comenzar el desarrollo de una aplicación con GeneXus, el primer paso consiste en crear unnuevo proyecto o base de conocimiento.

Una vez creada una nueva base de conocimiento (en inglés: knowledge base; abreviado: KB), elsiguiente paso es describir las visiones de los usuarios. Para ello se deben identificar los objetos dela realidad (prestando atención a los sustantivos que los usuarios mencionan en sus descripciones,como por ejemplo: clientes, productos, facturas) y pasar a definirlos mediante objetos GeneXus.

Con la definición de estos objetos, GeneXus puede extraer el conocimiento y diseñar la base dedatos y los programas de la aplicación en forma automática.



REALI DA D

Desarrollo con GeneXus


BASE DE

DATOS

PROGRAMAS

BASE DE CONOCI MI ENTO

A partir de los objetos definidos en la base de conocimiento, GeneXus generaautomáticamente tanto los programas de creación / reorganización de la base dedatos como los programas de la aplicación.

Luego, si un objeto de la realidad cambia, si se identifican nuevas o diferentes característicasdel mismo, o si se encuentran objetos aún no modelados, el analista GeneXus debe reflejar

dichos cambios en los objetos GeneXus que correspondan, y la herramienta se encargaráautomáticamente de realizar las modificaciones necesarias tanto en la base de datos como enlos programas asociados.

La metodología GeneXus es una metodología incremental, pues parte de la base de que laconstrucción de un sistema se realiza mediante aproximaciones sucesivas.

En cada momento el analista GeneXus define el conocimiento que tiene y luego cuando pasaa tener más conocimiento (o simplemente diferente) lo refleja en la base de conocimiento yGeneXus se ocupará de hacer automáticamente todas las adaptaciones en la base de datosy programas.

Si GeneXus no fuera capaz de realizar automáticamente las modificaciones en la base dedatos y programas conforme se realicen cambios que así lo requieran, el desarrolloincremental sería inviable.



Comparación de Metodologías

ANÁ LI SI S DE

DATOS

ANÁ LI SI S FUNCI ONAL

MODELO DE

DATOS

REALI DA D

PROGRAMACI ÓN PROGRAMAS

GENERACI ÓN/ I NTERPRETACI ÓN

ESPECI FI CACI ÓN FUNCI ONAL


BASE DE CONOCI MI ENTO

BASE DE

DATOS

Como se ha visto, existen varios caminos para la implementación de aplicaciones:

1. Programación utilizando lenguajes de 3era. generación.

2. Programación utilizando lenguajes de 4ta. 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 seconsigue con el desarrollo incremental.



Reportes(Rpts)

Procedimientos(Procs)

Work Panels(Wkps)

Web Panels(Wbps)

Objetos GeneXus(más importantes)

Transacciones(Trns)

y hay más, que veremos...

Una vez creada una base de conocimiento, el siguiente paso consiste en comenzar a describirlos objetos de la realidad mediante objetos GeneXus.

Los objetos GeneXus más importantes son:

TransaccionesPermiten definir los objetos de la realidad que el usuario manipula (ej: clientes, productos,

proveedores, facturas, etc.). Son los primeros objetos en definirse, ya que a través de lastransacciones, GeneXus infiere el diseño de la base de datos.Además de tener por objetivo la definición de la realidad y la consecuente creación de la basede datos normalizada, cada transacción tiene asociada una pantalla para ambiente windows yotra para ambiente Web, para permitir al usuario dar altas, bajas y modificaciones en formainteractiva a la base de datos. El analista GeneXus decidirá si trabajar en ambiente windows,Web, o ambos, y GeneXus generará los programas para ello.

ReportesPermiten recuperar información de la base de datos, y desplegarla ya sea en la pantalla, en unarchivo o impresa en papel. Son los tí picos listados o informes. No permiten actualizar lainformación de la base de datos1.

ProcedimientosTienen las mismas caracterí sticas que los reportes, pero a diferencia de éstos, permiten ademásla actualización de la información de la base de datos.

Work PanelsPermiten al usuario realizar interactivamente consultas a la base de datos, a través de unapantalla. Ejemplo: un work panel permite al usuario ingresar un rango de caracteres, ymuestra a continuación todos los clientes cuyos nombres se encuentran dentro del rango.Son objetos muy flexibles que se utilizan exclusivamente en ambiente windows y se prestanpara múltiples usos. No permiten la actualización de la base de datos, sino solo su consulta1.

------------------------------------------------------------------------------------------------------1 No es inherente a este tipo de objetos la modificación de la base de datos, pero comoveremos más adelante, existen unos componentes llamados “business components” que loharán posible, rompiendo con su naturaleza de solo consulta.



Web PanelsSon similares a los work panels, salvo que son usados a través de browsers en ambienteInternet/Intranet/Extranet.

Existen algunos tipos más de objetos GeneXus, algunos de los cuales veremos en este curso, comolos Subtype Groups y los Structured Data Types, que si bien son objetos que se definen en labase de conocimiento (KB) mediante el mismo procedimiento que los ya mencionados, tienen

algunas caracterí sticas que los diferencian de la mayorí a de ellos, como el hecho de no generarprogramas propios, sino que su conocimiento es reutilizado dentro de los otros objetos.



Proceso de desarrollo de unaaplicación con GeneXus

Base de Conocimiento


BaseBasedede

DatosDatos

Transacciones(Trns)

Reportes(Rpts)


Work Panels(Wkps)

Web Panels(Wbps)

Los primeros objetos que se definen son las transacciones, ya que es a partir de ellas queGeneXus extrae el conocimiento necesario para diseñar el modelo de datos normalizado (en3era. forma normal). Luego se van definiendo los demás objetos que correspondan.



Creación de la Base de Datos

BaseBasededeDatosDatos

ProgramasCreaciónBD

Reportes(Rpts)


Work Panels(Wkps)

Web Panels(Wbps)



Transacciones(Trns)

GeneXus genera automáticamente los programas necesarios para crear la base de datos ylos ejecuta. De esta manera obtenemos la base de datos creada por GeneXus en formaautomática.



Programas de Aplicación

(Trns, Rpts, Procs, Wkps, Wbps, DVs)

Generación de losProgramas de la aplicación

BaseBase

dedeDatosDatos

Reportes(Rpts)


Work Panels(Wkps)

Web Panels(Wbps)



Transacciones(Trns)

Luego, GeneXus genera programas de aplicación para interactuar con la base de datospreviamente creada.



Resultado final en la Etapa de Desarrollo






Reportes(Rpts)


Work Panels(Wkps)

Web Panels(Wbps)

Transacciones(Trns)

Una vez creada la base de datos y generados los programas, contamos con una aplicación prontapara ejecutar.



Las visiones de los usuarios cambian

NuevaNueva


BaseBase

dedeDatosDatos



Nuevos

Reportes

Nuevos

Procedimientos

Nuevos

Work Panels

Nuevos

Web Panels

NuevaNuevaBaseBasedede

DatosDatos

Nuevas

Transacciones



Durante el ciclo de vida de la aplicación, surgirá repetidamente la necesidad de hacer modificacionesen la base de conocimiento, ya sea porque las visiones de los usuarios cambian, porque se debenhacer correcciones, o simplemente agregar nuevo conocimiento.

Las modificaciones que se realicen sobre la base de conocimiento serán analizadas por GeneXuspara evaluar si es necesario efectuar cambios en la base de datos (por ejemplo:modificación/creación de tablas/í ndices), o no.

En caso de detectar cambios para efectuar en la base datos, GeneXus detallará los mismos en unreporte de aná lisis de impacto (IAR: Impact Analisis Report), que es un reporte que explicitatodos los cambios sobre tablas, í ndices, datos, etc. que habrí a que realizar para reflejar la nuevarealidad.

Asimismo, en el reporte de análisis de impacto se informan los eventuales problemas que loscambios en cuestión podrí an ocasionar, como inconsistencias o redundancias.



Análisis de Impacto Totalmente Automático

Análisisde

impacto

NuevaNueva


BaseBase

dedeDatosDatos



NuevaNuevaBaseBasedede

DatosDatos

Nuevos

Reportes

Nuevos

Procedimientos

Nuevos

Work Panels

Nuevos

Web Panels

Nuevas

Transacciones



Algunas veces la nueva base de datos coincide con la anterior. Otras veces esto no ocurre, y la basede datos debe sufrir alguna modificación para representar la nueva realidad.

El analista debe estudiar el reporte de análisis de impacto y resolver si desea realizarefectivamente los cambios en la base de datos, o renunciar a ello dejando la base de datos comoestaba.



Generación de Programas deReorganización de la Base de Datos

Programasde

Reorganiz.

Nuevos

Reportes

Nuevos

Procedimientos

Nuevos

Work Panels

Nuevos

Web Panels

Nuevas

Transacciones



NuevaNueva

BaseBasedede

DatosDatos

BaseBasedede

DatosDatos

NuevaNueva

BaseBasedede

DatosDatos



Si el analista opta por aplicar los cambios propuestos, decimos que optó por reorganizar la base dedatos. Utilizamos este término para referirnos a la acción de aplicar cambios f í sicos sobre la base dedatos.

GeneXus generará los programas que implementan las modificaciones sobre lasestructuras f í sicas de la base de datos, y mediante su ejecución nos brindará la nueva versiónde la base de datos con los cambios efectuados.



Análisis automático del impactode los cambios sobre los programas

Análisisde Impactosobre losprogramas

Nuevos

Reportes

Nuevos

Procedimientos

Nuevos

Work Panels

Nuevos

Web Panels

Nuevas

Transacciones

Nuevos Programas deAplicación


NuevaNueva




Ya sea que se requiera reorganizar la base de datos o no, considerando las nuevas definicionesintroducidas y a pedido del analista, GeneXus estudiará el impacto de los cambios sobre losprogramas actuales.

El analista podrá seleccionar sobre cuáles objetos quiere realizar el análisis (si sobre todos, los quehayan sufrido cambios, o algunos en particular) y para cada objeto analizado, GeneXus indicará si

es necesario realizar cambios en su programa de aplicación, o no.



Generación automática de nuevos programas

Nuevos

Reportes

Nuevos

Procedimientos

Nuevos

Work Panels

Nuevos

Web Panels

Nuevas

Transacciones

NuevaNueva


Nuevos Programas deAplicación


Generaciónde

programas



Por último, a pedido del analista, GeneXus proseguirá con la generación/ regeneración delos programas de aplicación que sean necesarios, obteniendo así una nueva versión de laaplicación.



Nueva realidad, con los cambios en la aplicación

NuevosReportes

NuevosProcedimientos

NuevosWork Panels

NuevosWeb Panels

NuevasTransacciones

NuevaNueva

BaseBasedede

DatosDatos

Nuevos Programas de Aplicación



De modo que nuevamente contaremos con una aplicación pronta para ejecutar, con los cambiosaplicados.



Consiste en construir una aplicación mediante aproximacionessucesivas.

DEFINICIONINICIAL

Metodología Incremental

La construcción automática de la base de datos y programas, permite a GeneXus aplicaresta metodología de desarrollo, conocida como metodología incremental.

Como ya hemos explicado, este proceso se realiza mediante aproximaciones sucesivas.



Modelos

Dentro de una base de conocimiento coexisten varios modelos

En particular, existe un modelo que se crea automáticamente alcrear una nueva base de conocimiento: el modelo de Diseño

BASE DE CONOCIMIENTO

modelode

Diseño

El modelo de Diseño corresponde a la representación lógica del sistema, esto es, permitedescribir la aplicación sin implementarla.

Esto significa que no existirá una base de datos física asociada a este modelo, así comotampoco programas de aplicación ejecutables. Estos últimos existirán solo a un nivelconceptual o lógico.

Son los objetos GeneXus que el analista haya definido dentro de este modelo los que

principalmente describen al sistema. En particular, de las transacciones especificadas1

GeneXus obtiene el diseño lógico de la base de datos, y ellas, en conjunto con el resto delos objetos definidos, constituyen la descripción lógica de los programas.

Los programas serán el resultado de la codificación de los objetos GeneXus en el lenguajede programación elegido por el analista, sobre una base de datos física.

Pero esta implementación (base de datos y programas), que es enteramente realizada porGeneXus, ¿dónde se realiza?

Aquí es donde entran en juego los otros modelos que pueden definirse dentro de la base deconocimiento. Cada uno de estos otros modelos, contendrán una implementación delsistema.

--------------------------------------------------------------------------------------------------1 En conjunción con los grupos de subtipos (objetos Subtype Group) y los índices deusuario.



Existen otros modelos que son creados en forma explícita por elanalista

¿Por qué tener varios de estos modelos, en lugar de uno solo? Entre otras razones: para tener cualquier número de implementaciones del

mismo sistema, asociadas a diferentes plataformas o ambientes (porejemplo: iSeries, PC, Client/Server, Web, etc.).

BASE DE CONOCIMI ENTO

modelode

Diseño

otromodelo

otromodelo

otromodelo

Modelos

A diferencia del modelo de Diseño que es creado automáticamente, estos otros modelosson creados en forma explícita por el analista. Al hacerlo, éste debe ingresar los datos de laplataforma o ambiente de implementación correspondiente (lenguaje de programación,DBMS, etc.) para que GeneXus pueda implementar el sistema para ese modelo.

Los objetos GeneXus definidos en el modelo de Diseño se copian al nuevo modelo y éstosson los que GeneXus codifica para dicho modelo de acuerdo a su plataforma.



Tipos de Modelo

Cada modelo tiene un tipo:

Design (Diseño):Un sólo modelo en la misma base de conocimiento.

No tiene base de datos ni programas de aplicaciónasociados.

Prototype/ Production (Prototipo/ Producción):Puede haber varios modelos en la misma base de

conocimiento.

Cada uno de estos modelos tiene una base de datosasociada y programas de aplicación que se generan para laplataforma o ambiente elegido.

Por cada base de conocimiento, habrá un y solo un modelo de Diseño, cuya característicafundamental es que representa al sistema conceptualmente.

Los otros dos tipos se parecen mucho entre sí, dado que todo modelo de Prototipo o Produccióntiene asociada una plataforma o ambiente que le permite implementar físicamente el sistema,siendo ésta la característica fundamental que diferencia a estos modelos del de Diseño. La principaldiferencia entre ellos es conceptual (no funcional) y radica en el uso que se hace de los mismos:

- Un modelo de Prototipo se utiliza en la etapa de desarrollo, justamente para prototipar laaplicación –de allí su nombre- probando lo modelado, haciendo modificaciones, volviendo a probar.

-Un modelo de Producción, por el contrario, se utiliza en la etapa de puesta en producción, cuandoel prototipo fue aprobado y la aplicación o los cambios efectuados ya pueden ser llevados al cliente.

Cuando una aplicación implementada en GeneXus ha sido puesta en producción, necesariamentedeberá haber al menos 3 modelos definidos en la base de conocimiento:

- el de Diseño, pues se crea automáticamente al crear la base de conocimiento,

- uno de Prototipo, utilizado para ir desarrollando y probando la aplicación,

- uno de Producción, pues es necesario tener una imagen fiel de la aplicación que se lleva alcliente, en la plataforma de producción, como veremos oportunamente.



Diseño Prototipo Producción

Ciclos de desarrollo

En el desarrollo incremental de una aplicación, pasaremos repetidamente del modelo deDiseño al modelo de Prototipo con el que estemos probando la aplicación, y de éstenuevamente al modelo de Diseño. Con menor frecuencia se pasará al modelo de Producción.

Ciclo de prototipaciónEl bucle Diseño-Prototipo se recorre repetidamente, construyendo y probando sucesivosprototipos.

Ciclo de producciónEl bucle Diseño-Producción se recorre menos frecuentemente, ya que este ciclo correspondea la puesta en producción del sistema y esto se realiza solamente cuando el prototipo hasido aprobado o luego de haber instrumentado y probado algún cambio.



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 susceptible de errores:

• El usuario olvida ciertos detalles• El analista no toma nota de algunos elementos• El usuario se equivoca en algunas apreciaciones• El analista malinterpreta algunas explicaciones del usuario

Como la implementación de sistemas es habitualmente una tarea que insume bastante tiempo, y muchosde estos problemas sólo son detectados en las pruebas finales del sistema, el costo en tiempo y dinero desolucionarlos se torna muy grande. Sabido es que la realidad no permanece estática, por lo que no esrazonable suponer que se pueden mantener congeladas las especificaciones mientras se implementa elsistema. Sin embargo, debido al tiempo que suele insumir la implementación, muchas veces esto se hacey se acaba implementando una solución relativamente insatisfactoria.

El impacto de estos problemas disminuiría mucho si se consiguiera probar cada especificacióninmediatamente y saber cuál es la repercusión de cada cambio sobre el resto del sistema. Una primeraaproximación a esto, ofrecida por diversos sistemas, es la posibilidad de mostrar al usuario formatos depantallas, informes, etc., animados por menús. Esto permite ayudar al usuario a tener una idea de quésistema se le construirá, pero al final siempre se presentan sorpresas.

Una situación bastante diferente sería la de poner a disposición del usuario para su ejecución, unaaplicación funcionalmente equivalente a la deseada hasta en los mínimos detalles. Y esto es lo que ofreceGeneXus! Un prototipo GeneXus es una aplicación pronta funcionalmente equivalente a la aplicación de

producción.

Así es que la aplicación puede ser totalmente probada antes de ponerse en producción; y durante laspruebas, el usuario final puede probar de una forma natural no solamente formatos de pantallas,informes, etc., sino también fórmulas, reglas del negocio, estructuras de datos, etc., y trabajar con datosreales.

Esto solo es posible gracias a la construcción automática que realiza GeneXus del soporte computacional(base de datos y programas).



OBJETO TRANSACCIÓN

El análisis de toda aplicación GeneXus comienza con el diseño de las transacciones.

Las transacciones permiten definir los objetos de la realidad.

Para identificar cuáles transacciones deben crearse, se recomienda prestar atención a lossustantivos que el usuario menciona cuando describe la realidad.

Además de tener por objetivo la definición de la realidad y la consecuente creación de labase de datos normalizada, las transacciones, al igual que la mayorí a de los objetosGeneXus que estudiaremos, provocan la generación de programas. En particular losprogramas correspondientes a las transacciones tienen por objeto permitir dar altas, bajas ymodificaciones en forma interactiva en las tablas que tengan implicadas, controlando estosprogramas la integridad referencial de los datos (ya sea en ambiente Win y/o Web según loindique el analista GeneXus).



Elementos

Para una transacción se definen:

• Estructura• Form GUI-Windows• Form Web• Reglas• Eventos• Subrutinas• Propiedades• Documentación

• Ayuda

Algunos elementos de las transacciones, que iremos viendo son:

Estructura: Permite definir los atributos (campos) que componen la transacción y la relación entreellos. A partir de la estructura de las transacciones, GeneXus inferirá el diseño de la base de datos:tablas, claves, índices, etc.

Form GUI-Windows: Cada transacción contiene un Form (pantalla) GUI-Windows (Graphical UserInterface Windows) mediante el cual se realizarán las altas, bajas y modificaciones en ambiente

Windows.Form Web: Cada transacción contiene un Form (pantalla) Web mediante el cual se realizarán lasaltas, bajas y modificaciones en ambiente Web.

Reglas: Las reglas permiten definir el comportamiento particular de las transacciones. Por ejemplo,permiten definir valores por defecto para los atributos, definir chequeos sobre los datos, etc.

Eventos: Las transacciones soportan la programación orientada a eventos. Este tipo deprogramación permite definir código ocioso, que se activa en respuesta a ciertas accionesprovocadas por el usuario o por el sistema.

Subrutinas: Permiten definir rutinas locales a la transacción.

Propiedades: Permiten definir ciertos detalles referentes al comportamiento de la transacción.

Documentación: Permite la inclusión de texto técnico, para ser utilizado como documentación delsistema.

Ayuda: Permite la inclusión de texto de ayuda, para ser consultado por los usuarios en tiempo deejecución de la transacción.

Algunos de estos elementos también están asociados a otros tipos de objetos GeneXus.



Estructura

Ejemplo: Se necesita registrar información de proveedores.

Se define transacción “Supplier”, con estructura:

Supp l ier I d * Identificador de proveedorSupp l ierNam e Nombre de proveedorSupp l ie rAddress Dirección de proveedorSupp l ie rPhone Teléfono de proveedor

La estructura de una transacción permite definir qué atributos la integran y cómo estánrelacionados.

A modo de ejemplo, si en una aplicación se necesita registrar información de proveedores, claramentehabrá que definir una transacción, a la que podemos dar el nombre “Supplier”, y su estructura podría serla siguiente:

SupplierId*SupplierName

SupplierAddress

SupplierPhone

Esta lista de nombres (uno de los cuales está sucedido del símbolo asterisco) corresponde a los atributosque interesa mantener acerca de los proveedores.

Entonces, creamos una transacción de nombre “Supplier” cuya estructura se compone de los atributosSupplierId, SupplierName, SupplierAddress y SupplierPhone.

Esto significa que cada proveedor se identificará por un código SupplierId (lo que queda determinado porel asterisco a continuación del atributo1), tendrá un nombre SupplierName, una direcciónSupplierAddress y un teléfono SupplierPhone.

Para cada atributo definido en la estructura, deberemos indicar cosas tales como su tipo de datos,descripción y algunos detalles más que veremos.

--------------------------------------------------------------------------------------------------------------1 El asterisco corresponde a una notación teórica que utilizamos para indicar que el atributo esidentificador. Como veremos, nuestro asterisco en GeneXus aparece representado por un ícono de llavey el usuario podrá configurarlo mediante un menú contextual que le ofrecerá esta posibilidad.



Estructura

Vista de la estructura en GeneXus:

Atributos Clave

En la página anterior hemos explicado que el asterisco a continuación del atributo SupplierId indica que se tratadel identificador de la transacción. Toda transacción debe tener un identificador, esto es, un atributo o conjuntode atributos que definan la unicidad.

En el ejemplo no podrán existir dos proveedores con el mismo valor de SupplierId. En definitiva se trata del

concepto de clave primaria, en tanto, para hacer la elección de los atributos que la componen, se deben teneren cuenta los requisitos del objeto de la realidad.

En los casos en los cuales no se pueda determinar un identificador, se debe optar por crear un atributo artificial(no existente en la realidad), y que su valor se asigne internamente, por ejemplo, en forma correlativa.

Como se puede observar en el editor de transacciones de GeneXus, un ícono de llave representa el asterisco quenosotros utilizamos como notación teórica.

Atributo “descriptor”

El ícono con una lupa representa al atributo que mejor describe o representa a la transacción. En otras palabrassería el atributo que tiene mayor carga semántica en la transacción.

Por defecto el primer atributo en la estructura de la transacción que sea de tipo de datos character, se definirácomo “atributo descriptor”. Es posible definir a otro atributo como descriptor utilizando el menú popupcorrespondiente, así como no definir ninguno.



Ejemplo: Se necesita registrar información referente afacturas de venta.

Se define transacción “Invoice”, con estructura:

I nvoiceI d * Identificador de facturaCust om er I d Identificador de clienteCust om erNam e Nombre de clienteI nvo iceDat e Fecha de facturaI nvo iceTota l Importe total de factura

( Product I d * Identificador de productoProduc tDescr i p t i on Descripción de productoProductPr ice Precio de producto

I nvo iceL ineQuant i ty Cantidad de producto llevada en la líneaI nv oiceLin eAm oun t ) Importe de línea de factura

Estructura

Niveles de una transacciónLa transacción “Invoice” consta de dos niveles: el primer nivel queda implícito por lo que no necesita un

juego de paréntesis; el segundo nivel corresponde al conjunto de atributos que se encuentra entreparéntesis1.

El hecho de definir un segundo nivel significa que existen varias instancias del mismo, para cadainstancia del nivel anterior. En el ejemplo, un cabezal de factura tiene varios productos.

Cada nivel de una transacción define un grupo de atributos que deben operar en conjunto, es decir, seingresan, se eliminan o se modifican conjuntamente en la base de datos.

Llamaremos transacción plana a una transacción de un solo nivel. Así, la transacción “Supplier” es unatransacción plana.

En cambio, la transacción “Invoice” tiene dos niveles. Es común hablar de “cabezal” para referirnos alprimer nivel y de “líneas” para referirnos al segundo.

Para cada nivel de la transacción, se debe indicar cuáles de sus atributos actúan como identificador. Elidentificador de cada nivel puede estar compuesto de un solo atributo, como es el caso de lastransacciones que hemos visto hasta ahora, o puede estar conformado por varios atributos.

En la transacción “Invoice” el atributo InvoiceId es el identificador del primer nivel, y el atributoProductId es el identificador del segundo nivel. Esto último significa que para un número de facturadado, InvoiceId, no puede repetirse el valor del atributo ProductId en distintas líneas.

Una transacción puede contener varios niveles paralelos, así como anidados.

--------------------------------------------------------------------------------------------------------------1 Al igual que el asterisco es una notación teórica que representa que el atributo que lo antecede esidentificador en la transacción, el juego de paréntesis también es utilizado como notación teórica, pararepresentar que los atributos contenidos forman parte de un nivel anidado, y que tiene unarepresentación visual en GeneXus distinta, pero que indica lo mismo.



Vista de la estructura en GeneXus

Estructura

En GeneXus queda visualmente claro el nivel correspondiente a las líneas de la factura.A cada nivel de una transacción se le debe asignar un nombre, tipo1 y descripción (salvo al primer nivel,que recibe como nombre el de la transacción).

Niveles paralelos y anidadosUna transacción puede tener varios niveles de anidación, así como niveles paralelos.Por ejemplo, en el hipotético caso de que una factura pueda abonarse en varios pagos, podríamos definirdos tipos de estructura, dependiendo de lo que se quiera representar:

InvoiceId* InvoiceId*

CustomerId CustomerId

CustomerName CustomerName

InvoiceDate InvoiceDate

InvoiceTotal InvoiceTotal

(ProductId* (ProductId*

ProductDescription ProductDescription

ProductPrice ProductPrice

InvoiceLineQuantity InvoiceLineQuantity

InvoiceLineAmount) InvoiceLineAmount

(InvoicePaymentDate* Fecha de pago (InvoicePaymentDate*

InvoicePaymentAmount) Importe pagado InvoicePaymentAmount))

Con la estructura de la izquierda se define que una factura tiene muchos productos y muchos pagos, perono hay una relación directa entre los productos y los pagos (a no ser el hecho de pertenecer a la mismafactura). En la estructura de la derecha se registran los pagos por producto llevado.Es sencillo comprender que el segundo y tercer nivel de la transacción de la izquierda, son paralelos.Ambos se encuentran anidados al primer nivel, pero entre ellos, son paralelos. En la estructura de laderecha, son todos niveles anidados.

--------------------------------------------------------------------------------------------------------------1 Como veremos luego, el tipo que se define para un nivel de una transacción, será utilizado para trabajarcon business components, concepto relacionado a las transacciones.



Definición del modelo de datos a partir de lasestructuras de las transacciones

InvoiceId*CustomerIdCustomerNameInvoiceDateInvoiceTotal

( ProductId*ProductDescriptionProductPriceInvoiceLineQuantityInvoiceLineAmount )

Transacción “Invoice”

Transacción “Supplier”

SupplierId*SupplierNameSupplierAddressSupplierPhone

TablaSUPPLIER

SupplierId*SupplierName

SupplierAddressSupplierPhone


TablaINVOICE

InvoiceId*ProductId*ProductDescription

ProductPriceInvoiceLineQuantityInvoiceLineAmount

TablaINVOICELINE

GeneXus utiliza la estructura de las transacciones para capturar el conocimiento necesario para definirautomáticamente cuál es el modelo de datos que debe crear.

Para poder realizar la normalización de la base de datos llevándola a 3era. forma normal, GeneXusdebe extraer las dependencias funcionales existentes entre los atributos definidos en la base deconocimiento.

En la base de conocimiento de nuestro ejemplo, hemos definido a la transacción “Proveedores” y de suestructura GeneXus extrae las siguientes dependencias funcionales:

SupplierId {SupplierName, SupplierAddress, SupplierPhone}

Dadas estas dependencias funcionales, GeneXus determina que debe crear una tabla que tendrá pordefecto el mismo nombre que la transacción (SUPPLIER)1, y que estará conformada ni más ni menosque por los cuatro atributos anteriores, siendo SupplierId la clave primaria de la misma:

Diremos que la transacción “Supplier” tiene asociada la tabla SUPPLIER en el entendido de que cuandose ingresen, modifiquen o eliminen datos por medio de la transacción, éstos se estarán almacenando,modificando o eliminando físicamente en la tabla asociada.

------------------------------------------------------------------------------------------------------------1 En la documentación, para distinguir el nombre de una tabla del nombre de una transacciónescribiremos el nombre de la tabla todo en mayúscula.

SupplierPhoneSupplierAddressSupplierNameSupplierIdSUPPLIER



A partir de la estructura de la transacción “Invoice”, GeneXus determina que debe crear dos tablas:

Tabla INVOICE, correspondiente al primer nivel de la transacción:

Clave primaria: InvoiceId

Tabla INVOICELINE correspondiente al segundo nivel de la transacción:

Clave primaria: {InvoiceId, ProductId}

Clave foránea: InvoiceId

ya que las dependencias funcionales son:

InvoiceId {CustomerId, CustomerName, InvoiceDate, InvoiceTotal}{InvoiceId, ProductId} {ProductDescription, ProductPrice, InvoiceLineQuantity,

InvoiceLineAmount}

Observemos que la clave primaria de la tabla INOVICELINE es la concatenación del identificador delprimer nivel, InvoiceId, con el identificador del segundo nivel, ProductId. El caso es general: la claveprimaria de la tabla correspondiente a un nivel n de una transacción se obtiene de concatenar losidentificadores de los n-1 niveles anteriores anidados, con el identificador de ese nivel.

GeneXus asigna un nombre predeterminado a las tablas que crea. A la tabla asociada al primer nivel deuna transacción le asigna el mismo nombre que el de la transacción; y a las tablas de nivelessubordinados les asigna la concatenación de los nombres de los niveles. Por esto es que la tablaasociada al segundo nivel de la transacción “Invoice” recibe el nombre INVOICELINE, dado que elnombre del primer nivel es el de la transacción, INVOICE, y el del segundo nivel es LINE. Los nombres

de las tablas pueden ser modificados por el analista GeneXus cuando así lo desee.

INVOICE InvoiceTotalInvoiceDateCustomerNameCustomerIdInvoiceId

InvoiceLineAmountInvoiceLineQuantity

ProductPriceProductDescriptionProductIdInvoiceIdINVOICELINE



Al definir las nuevas transacciones:

Transacción “Customer”

CustomerId*CustomerNameCustomerAddressCustomerGender

Transacción “Product”

ProductId*ProductDescription

ProductPriceProductStock

Sexo del cliente

Luego de haber modelado la transacción “Invoice”, nos damos cuenta que hay información de clientes y deproductos que nos interesa mantener independientemente de las facturas. Es decir, los clientes y losproductos son dos objetos de la realidad independientes de las facturas, por lo tanto creamos las dosnuevas transacciones “Customer” y “Product” detalladas arriba.

Dependencias funcionales

Con estas nuevas transacciones definidas, aparecen nuevas dependencias funcionales:

CustomerId {CustomerName, CustomerAddress, CustomerGender}ProductId {ProductDescription, ProductPrice, ProductStock}

que conducen directamente a la creación de dos nuevas tablas:

Clave primaria: CustomerId

y:

Clave primaria: ProductId

CustomerGenderCustomerAddressCustomerNameCustomerIdCUSTOMER

ProductStockProductPriceProductDescriptionProductIdPRODUCT



Normalización: cambios en las tablas


TablaINVOICE

InvoiceId*ProductId*ProductDescriptionProductPrice

InvoiceLineQuantityInvoiceLineAmount

TablaINVOICELINE

TablaSUPPLIER

SupplierId*SupplierNameSupplierAddressSupplierPhone

Tabla CUSTOMERCustomerId*CustomerNameCustomerAddressCustomerGender

Tabla PRODUCT

ProductId*ProductDescriptionProductPriceProductStock

El conjunto total de dependencias funcionales existentes requiere que deban realizarse algunasmodificaciones en las tablas INVOICE e INVOICELINE diseñadas previamente para que el diseño de la basede datos permanezca en 3era. forma normal1.

Si representamos sobre las tablas CUSTOMER e INVOICE las dependencias funcionales encontradas para susatributos:

podemos ver claramente que INVOICE viola la 3era. forma normal (existe una dependencia funcionaltransitiva):

InvoiceId CustomerId

CustomerId

CustomerNameInvoiceId CustomerName

por lo tanto GeneXus normaliza, quitando el atributo CustomerName de la tabla INVOICE:

Ahora CustomerName solo estará en la tabla CUSTOMER.

-------------------------------------------------------------------------------------------------------------------1 Por más información sobre las formas normales (3era. forma normal, etc.) le recomendamos la lectura deldocumento “Fundamentos de bases de datos relacionales”, el cual está incluido en el capítulo de “Anexos” del curso GeneXus no presencial. De lo contrario, puede pedírselo al docente.



Ahora veamos las dependencias funcionales encontradas en las tablas PRODUCT e INVOICELINE:

podemos percibir claramente que la tabla INVOICELINE está violando la 3era. forma normal (existen atributos questán dependiendo en forma parcial de la clave primaria):

ProductId ProductDescription ProductId ProductPrice

{InvoiceId, ProductId} ProductDescription {InvoiceId, ProductId} ProductPrice

Por lo tanto GeneXus normaliza, quitando los atributos ProductDescription y ProductPrice de la tabla INOVICELINE:

ProductDescription y ProductPrice solo quedarán en la tabla PRODUCT.



GeneXus establece las relacionespor los nombres de atributos

CONCEPTOS IGUALES DEBEN TENER EL MI SMO NOMBRECONCEPTOS IGUALES DEBEN TENER EL MI SMO NOMBRE

Transacción “Invoice” Transacción “Customer” InvoiceId* CustomerId*CustomerId CustomerName

CustomerName

Transacción “ Invoice” Transacción “Customer” InvoiceId* CustomerId*InvoiceCustomerId

CONCEPTOS DIFERENTES NO DEBEN TENER EL MI SMO NOMBRECONCEPTOS DIFERENTES NO DEBEN TENER EL M ISMO NOMBRE

Transacción “Invoice” Transacción “VendorInvoice” InvoiceId* VendorInvoiceId*Date Date

CustomerId SupplierId

CustomerName SupplierName

SI

NO

NO

Conceptos iguales deben tener el mismo nombre y conceptos diferentes deben ser nombradosdiferentes.

GeneXus establece las relaciones a través de los nombres de los atributos, de modo que cuandoencuentra atributos de igual nombre en distintas transacciones, entiende que se trata del mismoconcepto, y mediante dicho conocimiento es que puede normalizar.

En el ejemplo que venimos viendo, cuando GeneXus encuentra el atributo de nombre CustomerId

tanto en la transacción “Customer” como en la transacción “Invoice”, analiza que: el atributo se llamaigual en ambas transacciones, así que se refiere al mismo concepto. En la transacción “Customer”,CustomerId está marcado como identificador, lo que significa que será clave primaria en la tablafísica CUSTOMER; entonces en la tabla física INVOICE será clave foránea.

El atributo CustomerName, por su parte, también se encuentra tanto en la transacción “Customer” como en la transacción “Invoice”, pero a diferencia de CustomerId, no está marcado comoidentificador en ninguna transacción del modelo; por tanto GeneXus entiende que se trata de unatributo secundario. Las dependencias funcionales indican que a CustomerName lo determinaCustomerId:

InvoiceId CustomerId

CustomerId CustomerName

así que GeneXus incluirá CustomerName en la tabla física CUSTOMER (y no en la tabla física

INVOICE).

Atributos primarios y secundariosUn atributo se califica como primario cuando el mismo es identificador en alguna transacción delmodelo. En el ejemplo que venimos viendo, CustomerId es un atributo primario ya que esidentificador en la transacción “Customer”.

CustomerName, en cambio, es un atributo secundario ya que no es identificador en ningunatransacción del modelo.



Atributos almacenados e inferidos

Al definir las transacciones “Customer” y “Product”, hemos incluido en ellas ciertos atributos que nohemos eliminado de la transacción “Invoice”.

Los atributos CustomerId y ProductId, se incluyeron en las transacciones “Customer” y “Product” respectivamente, y al ser denotados como identificadores de las mismas, pasaron a ser atributosprimarios.

El atributo CustomerName, por su parte, se agregó en la transacción “Customer”; y los atributosProductDescription y ProductPrice se incluyeron en la transacción “Product”. Estos son atributossecundarios.

Todos estos atributos han quedado en más de una transacción: se han dejado en la transacción “Invoice” tal como se habían definido en un principio, y se han incluido en las transacciones “Customer” y “Product” respectivamente, porque nos hemos percatado de la necesidad de crear estosobjetos.

A continuación presentamos las 3 estructuras de las transacciones en cuestión, para podervisualizarlas juntas:

Probablemente usted no comprenda la razón por la cual los atributos secundarios CustomerName,ProductDescription y ProductPrice se han dejado en la estructura de la transacción “Invoice”.

La explicación es la siguiente: las estructuras de las transacciones no son equivalentes aestructuras de tablas físicas. En las estructuras de las transacciones se pueden incluir ciertosatributos que no estarán en la o las tablas físicas asociadas, ya que a la hora de reorganizar la base

de datos GeneXus analizará el conjunto total de dependencias funcionales existentes en la base deconocimiento, y creará -o modificará, según el caso- las tablas físicas, dejándolas en 3ª formanormal.

Ahora, ¿con qué finalidad hemos dejado los atributos secundarios CustomerName, ProductDescriptiony ProductPrice en la estructura de la transacción “Invoice”? Los hemos dejado para poder incluirlos enalguno de los forms (GUI-Windows y/o Web) asociados a la transacción “Invoice” y así podervisualizar los valores de dichos atributos en tiempo de ejecución.

Dichos atributos, como hemos explicado, no quedarán almacenados ni en la tabla INVOICE, ni en latabla INVOICELINE; sin embargo, en tiempo de ejecución cuando el usuario ingrese a través dealguno de los forms (GUI-Windows y/o Web) un valor de CustomerId (atributo que sí se almacenaráen la tabla INVOICE siendo clave foránea), a continuación se mostrará el CustomerNamecorrespondiente. Decimos que el atributo CustomerName es un atributo inferido en la transacción

“Invoice” , ya que su valor no se encuentra almacenado en ninguna de las tablas asociadas a latransacción, sino que se infiere –es decir, se obtiene- de la tabla CUSTOMER, dado el valor delatributo CustomerId.

Análogamente, los atributos ProductDescription y ProductPrice también son inferidos en latransacción “Invoice” , ya que no se encuentran almacenados en las tablas asociadas a la misma, sinoque sus valores se infieren de la tabla PRODUCT, para ser mostrados en pantalla.



Es conveniente usar padronespara los nombres de atributos

• Facilitan la tarea de nombrado

• Facilitan la tarea de integración de bases deconocimiento

• Facilitan la lectura del código generado



Nombrado de atributos:Nomenclatura GIK

Componente de Entidad + CategorComponente de Entidad + Categorí í aa

[+ Calificador + Complemento][+ Calificador + Complemento]

…y en inglés:

ARTech ha definido un estándar para la nomenclatura de atributos: el GeneXus Incremental KnowledgeBase (GIK) que es utilizado por la comunidad de usuarios GeneXus.

En esta nomenclatura, el nombre de un atributo se forma con 4 componentes (algunos opcionales,señalados entre paréntesis rectos):

Componente de Entidad + Categoría [+ Calificador + Complemento] 1

A continuación describimos en qué consiste cada componente:

Componente de Entidad (u Objeto):Una Entidad es un actor (ej: Customer), objeto o evento (ej:Vendor Invoice, factura de venta) que interviene en una aplicación dada, representado por unatransacción Genexus2. Un Componente de Entidad, representa a cualquier nivel subordinado o paraleloque defina la entidad.

Ejemplo: la factura tiene los siguientes componentes, Invoice (cabezal), InvoiceLine (líneas de lasolicitud).Se sugiere un largo de un entorno de 10 caracteres para representar el componente de la Entidad.

Categoría: Es la categoría semántica del atributo, es decir, define el rol que el mismo asume dentro del

objeto y dentro del entorno de la aplicación. Se sugiere que no supere los 10 caracteres.

Ejemplos: Id (identificador), Code (código), Name (nombre), Date (fecha), Description (descripción),Price (precio), Stock.

--------------------------------------------------------------------------------------------------------------1 Para países que utilicen lenguas en las que los adjetivos suelan colocarse después del sustantivo. En elinglés esto es al revés, por lo que la categoría (el sustantivo) va al final.2 O un conjunto de Transacciones paralelas y/o subordinadas, de las que hablaremos más adelante.



Calificador: Es cualquier adjetivo o adverbio, en el entorno de 10 caracteres, que agreguediferenciación conceptual al nombre del atributo para hacerlo único.

En general refiere al texto que califica la categoría: Fecha de vencimiento,

Ejemplos: Start (inicial), End (final), Due (vencimiento)

Complemento: Texto libre hasta completar la cantidad de caracteres significativos (30) para el nombre.

Tal como se muestra en la transparencia, algunos ejemplos de nombres de atributos son:

Nota 1: Las letras mayúsculas permiten establecer fronteras entre los componentes que forman a losnombres de atributos.

Nota 2: Para cada componente se pueden utilizar la cantidad de caracteres que se deseen, aunque sesugiere utilizar 10 y que el nombre completo del atributo no supere los 30.



Demo

Creación de base de conocimientoCreación de transacciones

Para crear una base de conocimiento, se debe seleccionar en la barra de menú de GeneXus, el ítemFi le / New Knowledge Base. A continuación aparecerá un diálogo que solicitará la ubicación ynombre de la base de conocimiento a crear.

Una vez creada la base de conocimiento, la misma quedará abierta en el modelo de Diseño, paraque se empiecen a crear las transacciones.

Antes que nada debemos posicionarnos (haciendo clic simplemente) en la carpeta “Objects” delárbol que se encuentra en la división izquierda de la pantalla, ya que los objetos que vayamoscreando irán quedando dentro de dicha carpeta.

La creación de objetos, se realiza mediante el ítem Object / New Object de la barra de menú deGeneXus.

Al seleccionar el ítem Object / New Object se desplegará un diálogo en el cual se deberá elegir eltipo de objeto que se desea crear (en este caso el tipo de objeto: transacción), dar un nombre alobjeto que se está creando (por ejemplo: “Customer”), una descripción larga, y se podrán indicaralgunas cosas más que iremos viendo.

Una vez creada la transacción, la misma quedará abierta para que se defina su estructura.



Definición de atributos

Para definir un atributo, simplemente se debe digitar en el primer campo de una línea (o rama)de la estructura, el nombre del atributo que se desea crear. Mediante la tecla de tabulación sepuede pasar a los siguientes campos para indicar el tipo de datos del atributo, así como sudescripción, si admitirá valores nulos de la base de datos, y en el caso que el mismo vaya a seruna fórmula (concepto que veremos en breve), cómo calcularla. Con la tecla Enter se puedepasar a la siguiente línea, para definir otro atributo.

Una vez definidos los atributos en la estructura de la transacción, solamente restará guardar /salvar los cambios.

Si se necesita modificar el nombre de un atributo, su tipo de datos, descripción, nulabilidad, ofórmula, bastará con hacer doble clic sobre el campo implicado, y el mismo se habilitará y sepodrá editar. Luego se deberán guardar/salvar los cambios, nuevamente.

Para indicar que uno o más atributos son identificadores en la transacción, se los debeseleccionar y presionar CTRL + K; en consecuencia aparecerán con un símbolo de llave.

Para definir que comienza otro nivel en la transacción, se debe digitar CTRL + L, yautomáticamente se producirá una indentación y el usuario deberá darle nombre a ese nivel,así como definir el nombre de su tipo de datos1 y una descripción para el nivel.

Para indicar que un atributo de uno de los niveles de la transacción será el atributo “descriptor”, se lo debe seleccionar y presionar CTRL+D.

GeneXus cuenta con menús pop up2, que son menús que se abren cuando el usuario estáposicionado en determinado contexto y da clic con el botón derecho del mouse. Por ejemplo, alhacer clic con el botón derecho del mouse sobre un atributo de la estructura, se abre un

menú pop up sobre el atributo seleccionado, que ofrece varias utilidades, como por ejemploindicar que el atributo es clave (opción “Toggle key”), quitarlo de la estructura, pasarlo a unsiguiente nivel de anidación, etc.

Cada atributo tiene propiedades. Algunas de ellas (las fundamentales y obligatorias) son lasque se ofrecen directamente en la estructura para su ingreso “inline”. Para acceder al diálogoque permite configurar todas las propiedades de un atributo, se debe seleccionar el ítemProperties del menú contextual.

----------------------------------------------------------------------------------------------------1 Veremos su utilidad cuando estudiemos los “business components”.2 También llamados “contextuales” dado que varían según el contexto.



La posibilidad de modificar las propiedades de un atributo solo estará disponible en el modelo de Diseño, ya quees en este modelo de la base de conocimiento en el que se diseñan y editan las transacciones y atributos.

El diálogo de configuración de las propiedades de un atributo tiene 4 solapas: General, Control Info, Help yDocumentation.

1) General: Contiene información general del atributo.

Name: Es el nombre del atributo. Se utiliza para identif icarlo.

Description: La “Descripción” o más propiamente “Nombre largo” es una descripción ampliada del atributo. Debe

identificar bien al atributo, con independencia del contexto, y principalmente debe ser entendible por el usuario final.Debe ser un identificador global del atributo, es decir, no se le debe asignar a dos atributos en la base de conocimientola misma descripción, ya que será a través de esta descripción que el usuario final podrá seleccionar atributos paradefinir sus propias consultas a la base de datos, con GeneXus Query, ejecutando “reportes dinámicos” (tema bastantesimple, pero que no se abordará en este curso).

Relacionadas a esta propiedad, están las propiedades Title y Column Title, que por defecto toman el mismo valor quese especifica en Description, pudiéndose modificar. Estas propiedades se describen a continuación:

Title: La descripción que se ingrese aquí será colocada por defecto al lado del atributo cada vez que se utilice ensalidas “planas” como en el primer nivel de los forms de las transacciones, o en reportes generados con el ReportWizard. El valor de esta propiedad inicialmente se hereda de la propiedad Description del atributo, pudiendo sermodificada por el programador.

Column Title: La descripción que se ingrese aquí será colocada por defecto como título del atributo cada vez que se loincluya en la columna de un grid (grilla). El valor de esta propiedad inicialmente se hereda de la propiedadDescription del atributo, pudiendo ser modificada por el programador.

Domain: Permite asociarle un dominio1 al atributo. Al hacerlo, ciertas propiedades del atributo se deshabilitarán (comoData Type y Length) tomando los valores del dominio. En caso de que el atributo no pertenezca a un dominio, elprogramador dejará el valor [none] en esta propiedad, y las correspondientes al tipo de datos del atributo estaránhabilitadas para ser ingresadas.

Data Type: Permite indicar el tipo de datos del atributo. Aquí se podrá elegir uno de los tipos de datos soportados porGeneXus. Dependiendo del tipo de datos que se seleccione habrá ciertas propiedades, u otras, para configurar.

Length: Permite indicar el largo del atributo. Si en la propiedad Data Type se indica que el atributo es numérico,entonces se deberá tener en cuenta que el largo incluya las posiciones decimales, el punto decimal y el signo. Estapropiedad estará deshabilitada cuando el tipo de datos elegido no requiera establecer un largo (por ejemplo, si se tratadel tipo de datos Date).

Decimals: Si en la propiedad Data Type se indica que el atributo es numérico, se ofrecerá esta propiedad, para quese especifique la cantidad de decimales. El valor 0 en este campo, indicará que se trata de un entero.

Signed: Si en la propiedad Data Type se indica que el atributo es numérico, se ofrecerá esta propiedad para que se

indique si manejará signo o no. El valor por defecto es “False”, lo que indica que no se representarán valoresnegativos.

Value Range: Permite indicar un rango de valores válidos para el atributo. Por ejemplo:• 1:20 30: - significa que los valores válidos son entre 1 y 20; y 30 o mayor.• 1 2 3 4 - significa que los valores válidos son 1, 2, 3 o 4.• 'S' 'N' - significa que los valores válidos son 'S' o 'N'.

Picture: Permite indicar el formato de edición para la entrada y salida del atributo. Dependiendo del tipo de datos delatributo, aparecerán determinadas propiedades bajo esta categoría.

GeneXus provee más propiedades para los atributos que las recién mencionadas. Dependiendo del valor que se elijapara determinada propiedad, se ofrecerán ciertas propiedades relacionadas, u otras. Recomendamos para la lectura deotras propiedades, acceder al Help de GeneXus.

-------------------------------------------------------------------------------------------------------------------------------1 Losdominios se abordarán más adelante en el curso, pero a modo de resumen, el objetivo de los dominios es realizardefiniciones de datos genéricas. Por ejemplo: se puede definir un dominio de nombre Precio y tipo de datosNumeric(10,2) y luego asociarle este dominio a todos los atributos que almacenan precios. Esto tiene la ventaja de quesi después se desea modificarlo a por ejemplo Numeric(12,2), hay que modificar solamente la definición del dominio yautomáticamente todos los atributos basados en ese dominio heredan el cambio.



2) Control Info

A un atributo se le puede asociar un tipo de control. Los tipos de controles posibles son:- Edit- Radio Button- Check Box- Combo Box- List Box- Dynamic Combo Box- Dynamic List Box

La asociación de cierto tipo de control a un atributo, sirve para especificar el tipo de control por defecto que se utilizarápara el atributo cada vez que se lo incluya en un form.

Cuando se define un atributo el tipo de control que tiene asociado es Edit, pudiendo el programador cambiarlo acualquiera de los otros tipos.

En la solapa Control Info del diálogo de edición de las propiedades de un atributo es donde el programador podrácambiar el tipo de control asociado al atributo y dependiendo del tipo de control seleccionado, se solicitará distintainformación complementaria.

Luego, cada vez que se agregue el atributo en un form se presentará automáticamente con el tipo de control quetenga asociado aquí.

N o t a

En caso de asociar al atributo el tipo Edit, se podrá especificar que “disfrace” sus valores, mostrando los de otroatributo (propiedad InputType), e incluso que sugiera los valores posibles al usuario, a medida que éste vayadigitando (propiedad Suggest), entre otras, como veremos luego, cuando estudiemos “Descripciones en lugar decódigos”.

También se puede elegir el color de la fuente de letra que se desea asociar por defecto al atributo, así como el color defondo, de modo que cada vez que se agregue el atributo en un form, se presente automáticamente con los colores quese le hayan asociado.

3) Help

Esta solapa permite que el programador ingrese un texto de ayuda asociado al atributo, para que el usuario final puedaconsultarlo en tiempo de ejecución. Si el usuario final solicita ayuda (presionando F1), estando posicionado en elatributo, se le desplegará el texto que se haya ingresado aquí.

Más adelante, veremos otros temas relacionados al help de una aplicación GeneXus.4) Documentación

Esta solapa permite que el programador ingrese documentación técnica del atributo, útil para los desarrolladores.



Tipos de Datos

Numeric, Character, Date

VarChar- Equivalente a Character, salvo en la forma en que se almacena en la BD.- Propiedades Maximum Length y Avarage Length asociadas.

Long Varchar

- Permite almacenar textos largos, comentarios, etc. (memo).

DateTime

- Permite almacenar una combinación de fecha y hora.

Blob- Permite almacenar cualquier tipo de información: texto, imágenes,

videos, planillas, etc., en la base de datos.- Win / Web ofrecen manipulación distinta de este tipo de datos

Numeric: Permite almacenar datos numéricos. Cuando se selecciona este tipo de datos se debe indicarla cantidad total de dígitos del número, la cantidad de posiciones decimales, y si permite signo o no.

Ejemplo:Si definimos que el tipo de datos del atributo InvoiceTotal es numérico de largo 10, con decimales 2, ysin signo, estamos especificando que representará números con hasta 7 dígitos en la parte entera y 2decimales (7 dígitos en la parte entera + punto + 2 dígitos para los decimales = 10 dígitos).

Character: Permite almacenar cualquier tipo de texto (caracteres y dígitos). Para este tipo de datos,se debe indicar el largo.

Ejemplo: El atributo CustomerName que utilizamos para almacenar el nombre de un cliente, es de tipoCharacter y si sabemos que nunca un nombre tendrá más de 20 caracteres, podemos fijar el largo: 20.

Date: Permite almacenar una fecha.

Ejemplo: El atributo InvoiceDate que utilizamos para almacenar la fecha de una factura, será de estetipo de datos.

El formato a utilizar para las fechas (día-mes-año, mes-día-año), se configura en forma genérica paratodo el modelo dentro de un tipo especial de objeto, el objeto Language correspondiente al lenguaje enel que se generará el modelo. El objeto “language” existe para poder tener una misma aplicacióntraducida en cualquier lenguaje.

La elección de presentar el año con 2 dígitos o 4, se configura con la propiedad Picture de cadaatributo.



• VarChar: Permite almacenar texto de largo variable. Su función, en contraposición al Character, es optimizar elalmacenamiento en la base de datos.

Cuando se selecciona el tipo de datos VarChar en el diálogo de definición del atributo se agregan las 2 siguientespropiedades: Maximum Length y Average Length.

La primera es para indicar el largo máximo de caracteres que se podrán almacenar, mientras que la segunda espara indicar el largo promedio de caracteres que se suele almacenar por lo general.

Ejemplo: Cuando se define un atributo de tipo Character y largo 60, si se le ingresa un dato que ocupa 25caracteres, la capacidad restante de almacenamiento del atributo (35 caracteres) se rellena con blancos. El tipo

de datos Varchar, en cambio, optimiza el almacenamiento de la siguiente forma: se le define Average Length(por ejemplo: 25), y Maximum Length (por ejemplo: 60); entonces, si el dato tiene largo menor o igual que 25,se lo almacena en el campo (rellenado con blancos) mientras que en los casos que el dato sea de largo mayor que25, se almacenan los primeros 25 caracteres en el campo, y el resto en un área de overflow.

Como contrapartida a la ventaja de la optimización del almacenamiento, para los casos en que se utilice el área deoverflow, será necesario realizar un acceso adicional tanto para la lectura como para la escritura del dato.

El tipo de datos Varchar es equivalente al tipo Character en todos los sentidos, salvo en la forma en que sealmacena en la base de datos. Se le pueden aplicar todas las funciones y operadores existentes para el tipo dedatos Character. Si el DBMS no soporta este tipo de datos, se creará el atributo de tipo Character.

Long Varchar: Permite definir un atributo memo; es decir, se utiliza normalmente para almacenar textoslargos, comentarios, etc. Al seleccionar este tipo de datos, se debe indicar un largo máximo.

Existen dos funciones para manipular este tipo de datos: GXMLines y GXGetMLi.

GXMLines retorna la cantidad de líneas que tiene un atributo Long Varchar, teniendo como parámetros el nombre

del atributo, y la cantidad de caracteres que se desea considerar por línea.Ejemplo: &cantlin = GXMLines( AtribMemo, 40 ).

GXGetMLi por su parte, extrae una línea del atributo Long Varchar (para luego imprimirla, por ejemplo); teniendocomo parámetros el nombre del atributo, el número de línea deseado, y la cantidad de caracteres que se deseaconsiderar por línea.

Ejemplo: &txt = GXGetMLi( AtribMemo, 1, 40 ).

Generalmente se usan estas 2 funciones en combinación, ya que primero se suele consultar la cantidad de líneasque tiene cierto atributo Long Varchar, indicando la cantidad deseada de caracteres por línea, y luego se prosigueextrayendo el contenido de las líneas, utilizando un bucle hasta llegar a la última línea, y de esta forma seimprimen, por ejemplo.

DateTime: Permite almacenar una combinación de fecha y hora.

La propiedad Picture de este tipo de datos, permite elegir qué se desea mostrar de la fecha, y qué se desea

mostrar de la hora.Acerca de la fecha se puede elegir: no manejarla, manejarla y presentar el año con 2 dígitos, o manejarla ypresentar el año con 4 dígitos. Acerca de la hora se puede elegir: manejar solo 2 dígitos para la hora (nomanejando minutos ni segundos), manejar 2 dígitos para la hora y 2 dígitos para los minutos (no manejandosegundos), o manejar 2 dígitos para la hora, 2 dígitos para los minutos y 2 dígitos para los segundos.

Los valores anteriores no afectan la forma de almacenar el tipo de datos sino específicamente la forma deaceptar o mostrar su contenido.

Nota: En caso de no manejar la fecha, sino solo la hora, el valor de fecha que quedará en el campo será elmínimo soportado por el DBMS, y será reconocido por GeneXus como fecha vacía o nula. En lo que respecta a lahora, los valores no aceptados (minutos y/o segundos) serán almacenados con valor cero.

Blob: Ante el creciente manejo de imágenes digitalizadas, videos, planillas así como documentos de todo tipo,las aplicaciones requieren cada vez más mantener y trabajar con este tipo de información.

El tipo de datos Blob permite almacenar esta diversidad de información en la propia base de datos, aprovechandoasí los diferentes mecanismos de integridad y control que proveen los DBMSs.

Este tipo de datos solamente se puede utilizar cuando se cuenta con un DBMS.

Dependiendo de si se implementa la aplicación en ambiente Win o Web, será la forma de manipulación de unatributo de este tipo de datos. El ambiente Web ofrece más funcionalidades para trabajar con atributos de tipoBlob de forma muy amigable.

Para profundizar en el conocimiento de este tipo de datos puede dirigirse al Help de GeneXus.



Definición de variables

En todo objeto GeneXus es posible definir variables.

Las variables son únicamente visibles dentro del objeto; esdecir, son locales.

Para definir variables en determinado objeto, estando dentro del mismo, se debe presionar el botón

de la barra de herramientas “Fast Access” de GeneXus, y se abrirá el diálogo de definición devariables, mostrado en la transparencia.

Este diálogo muestra variables definidas por defecto (como por ejemplo la variable Today que contiene lafecha del sistema) para el objeto, y permite definir variables nuevas mediante los botones “Add” y “AddBased On”.

Botón “ Add”

Al seleccionar el botón “Add”, se abre el siguiente diálogo para la definición de una variable:

Este diálogo solicita el nombre de la variable, su descripción, tipo de datos y largo, o dominio, de formaanáloga a cuando se define un atributo.La propiedad Dimensions permite indicar si la variable será escalar o si se tratará de un vector (1dimensión) o matriz (2 dimensiones). El valor que ofrece por defecto esta propiedad es escalar.



Botón “ Add Based On”

El botón “Add Based On” ofrece una forma rápida de definir una variable. Cuando se selecciona, se despliega undiálogo que muestra todos los atributos definidos en la base de conocimiento; en dicho diálogo, simplemente se debeseleccionar un atributo, y a continuación se definirá automáticamente una variable con el mismo nombre y la mismadefinición que el atributo. Vale aclarar que se pueden seleccionar varios atributos, creándose en tal caso una variablepor cada atributo seleccionado, con sus mismas características.

Bot on es “ Edi t ” , “ Rem ov e” , “ Copy” , Past e”

El botón “Edit” permite editar una variable que se haya seleccionado previamente, mientras que el botón “Remove”,

permite borrar una o más variables que se hayan seleccionado a la vez.

El botón “Copy” ofrece la posibilidad de copiar en el portapapeles la definición completa de las variables que se hayanseleccionado previamente, para luego poder pegar dichas definiciones de variables en otro objeto de la base deconocimiento, con el botón “Paste” de este mismo diálogo; es decir, en el objeto destino, se deberá entrar a estemismo diálogo, y presionar el botón “Paste”.

Por otra parte, es posible definir variables dentro del editor de código de cada objeto (source, eventos, etc.), haciendouso del menú contextual (botón derecho) luego de escribir el nombre de la variable. Esto es, al escribir&nombreDeVariable (ej: &x) y presionar botón derecho del mouse, se abrirá el siguiente menú contextual:

También es posible editar variables luego de definidas, de esta misma forma. Si al escribir &nombreDeVariable (ej:&x), la misma ya existe definida para el objeto, el menú contextual mostrará:

Al seleccionar la opción “Define” se abrirá el mismo diálogo que al presionar el botón “Add”. Análogamente, alseleccionar la opción “Edit” de este menú, se abrirá el mismo diálogo que al presionar el botón “Edit” del diálogo dedefinición de variables mostrado en la transparencia.



Dominios

• Objetivo: Realizar definiciones genéricas.

• ¿Cuándo debemos usar dominios?• Atributos y/o variables con la misma definición

Ejemplo:

Atributos

Dominio Price : Numeric(10.2)

I nvo iceL ineAm oun t : Importe total de línea

ProductPr ice : Precio de producto

Es común tener en una base de conocimiento atributos que comparten definiciones similares peroque no tienen relación entre sí. Por ejemplo, es común definir todos los nombres como atributos detipo character y largo 20; o todos los importes, como atributos de tipo numérico y largo 10.2.

El objetivo de los dominios es permitir realizar definiciones genéricas. A modo de ejemplo, elatributo InvoiceLineAmount es de tipo numérico y largo 10.2, y al mismo tiempo, el atributoProductPrice es del mismo tipo y largo, en la misma base de conocimiento. De modo que podríamos

definir un dominio de nombre Price, que sea de tipo numérico con largo 10.2, y a cada uno de losatributos anteriores le asignaríamos dicho dominio. La ventaja de hacerlo así es que si en el futurosurge la necesidad de cambiar la definición de los atributos que representan importes, haríamos elcambio una sola vez (en el dominio Price), propagándose éste automáticamente a los atributosInvoiceLineAmount y ProductPrice por pertenecer a él.

Así como podemos asociarle a un atributo un dominio, también lo podemos hacer para una variable.Un mismo dominio puede asignarse tanto a atributos como a variables, ya que su objetivo esexactamente el mismo.

¿Cómo definir un dominio?Existen varios caminos:1) El ítem: Advanced / Domain de la barra de menú de GeneXus ofrece un diálogo para realizar elmantenimiento de los dominios de la base de conocimiento; esto es: crear dominios, modificarlos yeliminarlos (la eliminación de un dominio solo se permitirá si el mismo no está asignado a ningúnatributo ni variable).2) Dado que en la pantalla de configuración de las propiedades de un atributo es donde se le asignaa un atributo un dominio existente, en dicha pantalla se ofrece un botón para crear un dominionuevo. Ídem con el diálogo de definición de variables.3) En la estructura de la transacción es posible definir un nuevo domino en el campo de definicióndel tipo de datos de un atributo, simplemente escribiendo sobre esa misma línea, el nombre deldominio, y asignándole el tipo de datos. Por ejemplo, digitando Price = Numeric(10.2) sobre lacolumna Type del atributo que se está definiendo, queda también definido el dominio de nombrePrice, con el tipo de datos Numeric(10.2).

Estos accesos para trabajar con dominios solo se encuentran habilitados en el modelo de Diseño dela base de conocimiento, al igual que todas las funcionalidades que puedan implicar modificacionesen la base de datos física.



Forms

Cada transacción tiene asociado un form GUI-Windows y un form Web.

Ambos forms son creados por defecto al grabar laestructura de la transacción, pudiendo sermodificados por el programador.

Para cada transacción, GeneXus crea un form GUI-windows y un form Web, los cuales serán la interfazcon el usuario, en ambiente windows y Web respectivamente.

Ambos forms son creados por defecto por GeneXus al momento de grabar la estructura de latransacción, y contienen todos los atributos incluidos en la misma, con sus respectivas descripciones,además de algunos botones.

Si bien son creados por defecto, es posible modificarlos para dejarlos más vistosos, cambiar por ejemplocontroles de tipo edit a otros tipos de controles, agregar y/o quitar botones, etc.

Para editar el form GUI-windows de una transacción, se debe seleccionar la solapa Form que seencuentra en la barra de edición del objeto, mientras que para editar el form Web, se debe seleccionar lasolapa Web Form en la misma barra.



Form GUI-Windowsde la transacción “Invoice”

GRID

A través del form de la transacción (GUI-Windows o Web según el ambiente de trabajo) el usuario podráingresar, modificar y eliminar registros en tiempo de ejecución.

En el ejemplo se muestra el form GUI-Windows correspondiente a la transacción de facturas (“Invoice”).



Form Webde la transacción “Invoice”

GRID

Control “Error Viewer” exclusivo de Web

botón “Get”

En el ejemplo se muestra el form Web correspondiente a la transacción “Invoice”. A través de este form elusuario final podrá ingresar, modificar y eliminar facturas en la aplicación Web.

Pueden verse algunas diferencias en el diseño gráfico del form Web respecto al form Win, pero podemos verque todos los controles que están en el form Win, también lo están en el Web. El recíproco no se cumple: elbotón “Get” al lado de la clave primaria aparece en el form Web y no en el Win que hemos visto1. El control

“Error Viewer” aparece también solamente en el form Web. Y el grid correspondiente a las líneas de la factura,contiene en el form Web una primera columna con un check box, que el grid del form Win no la incluye.

Comentaremos a continuación el control Error Viewer. Sobre el botón “Get” entenderemos el por qué de estadiferenciación un poco más adelante, cuando estudiemos el diálogo con validación a nivel del cliente. Conrespecto al check box también veremos este tema más adelante, cuando estudiemos la ejecución.

En una aplicación con interfaz Win, los mensajes que deban mostrarse al usuario en tiempo de ejecución sedesplegarán en una ventana de Windows independiente, que no programamos nosotros. En Web, en cambio,los mensajes2 deben mostrarse dentro de la página HTML que contiene el form de la transacción. Es por estemotivo que existe el control Error Viewer, para poder ubicar y programar el lugar donde queremos que losmensajes generales le sean desplegados al usuario final de una transacción Web.

Podremos especificar entre otras cosas el lugar donde queremos que este control se ubique dentro del form, sutipo de letra, color, etc.

Existen algunas diferencias más entre ambos forms, pero son menores dado que representan formas distintasde realizar lo mismo: por ejemplo, mientras que el botón para confirmar las acciones y comenzar la grabaciónde los registros de la transacción en el form Win tiene como texto “Confirm”, en el Web su texto es “ApplyChanges”. Análogamente, mientras el botón para eliminar todo (cabezal y líneas) tiene como texto solo

“Delete” en el form Win, en el Web dice “Delete All”. La funcionalidad es la misma.

Por último vale mencionar que en el form Web se puede percibir el botón Check, que permite chequear quetodo lo que ha ingresado el usuario hasta el momento sea correcto.

Más adelante, cuando estudiemos cómo se trabaja en ejecución con las transacciones, arrojaremos más luzsobre estos asuntos.

-----------------------------------------------------------------------------------------------------------------------1 Más adelante cuando estudiemos el diálogo con validación a nivel del cliente, veremos que en ambiente Winse podrá optar por trabajar con dicho diálogo o no, y dependiendo de ello, el botón “Get” estará presente en elform o no.2 Cuando estudiemos el diálogo con validación a nivel del cliente en Web, veremos que muchos de los mensajesse desplegarán en cajas de texto sobre la pantalla, específicamente sobre los campos que el usuario hayaingresado y en los que se deba informar de algo al usuario. Es decir, funcionarán de manera combinada elcontrol Error Viewer junto con los mensajes interactivos en cajas de texto.



Paletas de herramientas paradiseño de forms Win y Web

Insertar controles:

Cortar, copiar y pegar controles :

Alinear, distribuir y uniformizar los tamaños de los controles(solo disponible para form GUI-Window s):

Podemos definir un control como un área de la interfaz con el usuario, que tiene una forma y uncomportamiento determinado.Existen distintos controles:

- Form: Un form puede verse en sí mismo como un control.- Texto: Permite colocar texto fijo (por ejemplo las descripciones de los atributos en el form Win: “Customer Name”, “Customer Id”, o cualquier otro texto).- Atributo/ Variable: Permite colocar atributos o variables.- Línea: Con este control se dibujan líneas horizontales o verticales (form Win).- Recuadro: Permite definir recuadros de distintos tamaños y formas (form Win).- Grid: Permite definir grillas de datos.- Botón: Permite incluir botones en los forms.- Bitmap: Permite definir bitmaps estáticos.

La mayoría de los controles anteriores (salvo línea y recuadro) están disponibles tanto para ser utilizados eninterfaz GUI-Windows como Web. A su vez el “tab control” es un control que solo está disponible para serutilizado en interfaz GUI-Windows, mientras que otros controles solo pueden utilizarse en interfaz Web (textblocks, tablas, grids freestyle, Error Viewer, etc.).

Tab Control: tiene una o varias solapas, en las cuales se pueden distribuir controles. Cada solapa tiene untítulo y un área útil para que se le incluyan controles. El uso de este control es útil para los casos en los

cuales se quiere distribuir los datos en distintos grupos, para presentarlos de forma amigable para el usuario.Por ejemplo, si queremos dividir la información de la transacción “Customer” en 2 solapas: una para ingresarlos datos generales del cliente, y otra para ingresar los datos comerciales, podemos insertar en el form unTab Control con dos solapas, y distribuir los controles de texto, atributo, etc. en cada una de ellas.

Paleta de herramientas para insertar controles: Cuando se está editando un form, se encuentradisponible una paleta de herramientas que ofrece los controles posibles de insertar en el mismo.Simplemente se deberá seleccionar en la paleta de herramientas el control que se desee insertar en el form,para lo cual se deberá hacer clic en el ícono que lo represente; seguidamente se deberá hacer clic en el form,en el lugar que se desee ubicar el control, y se insertará el control elegido en el lugar del form que se hayaindicado; en caso de ser necesario, se abrirá el diálogo correspondiente a las propiedades del control, paraque se indiquen aquellas que sean de carácter obligatorio.



Controles en form Web

• Cada control del form Web podrá tener una clase asociada, deun objeto theme (tema) determinado, asociado al objeto.

• Al crear una KB, se crea por defecto el tema “Default” y todoslos objetos que se creen tendrán este tema.

• Esto permitirá independizar el diseño de la interfaz, de laprogramación.• Existe el Editor de temas, un utilitario que usarán los diseñadores

gráficos del sitio• Cada tema tendrá definidas muchas clases para cada tipo de control• El analista solo asocia un tema al objeto, y una clase a cada control

del form y puede olvidarse del diseño de los mismos.

• El control hereda el diseño de la clase del tema al que estéasociado

Una de las ventajas de las aplicaciones con interfaz Web frente a las mismas aplicaciones con interfaz GUI-Windows, refiere a los aspectos de diseño. Las aplicaciones Web, programadas en HTML, pueden llegar aser verdaderamente vistosas.

Para lograr separar los aspectos de diseño gráfico de un sitio web, de los aspectos de programaciónpropiamente dichos, existe un tipo de objeto llamado Theme (Tema, en español), y un utilitarioindependiente para editar objetos de este tipo, el Editor de Temas. Este utilitario puede también invocarse

desde GeneXus mediante el ítem Tools /Theme Editor estando en el modelo de diseño.

El objetivo de esta separación es poder paralelizar el desarrollo de un sitio Web, permitiéndole alprogramador abocarse a las tareas de programación, y apoyarse en un diseñador gráfico para que definalas cuestiones de diseño. De esta manera el diseñador gráfico configurará el “tema” elegido por elprogramador, utilizando este utilitario independiente, y el programador sólo deberá aplicarlo a los objetosde su base de conocimiento (para esto existe una propiedad de nombre “Theme” a nivel de modelo y otrapropiedad de nombre “Theme” a nivel de cada objeto1 ).

Un objeto “tema” contendrá un conjunto de clases, para cada tipo de control de los que pueden apareceren el form Web de un objeto GeneXus. Por ejemplo, tendrá varias clases para el control botón, algunaspara el control atributo, una clase para el control Error Viewer, etc.

Cuando se crea una base de conocimiento, automáticamente aparecerá dentro de la carpeta “Objects” (que contendrá todos los objetos GeneXus que se vayan creando) un objeto de tipo Theme cuyo nombrees “Default”. Este tema contiene un conjunto de clases asociadas a los distintos controles existentes2.

Los objetos con form Web que se vayan creando tendrán por defecto asociado este Theme, y cadacontrol que aparezca en sus forms tendrá asociado una clase de ese tema, para este control.

-------------------------------------------------------------------------------------------------------------1 Al final de este capítulo se mencionará que al igual que cada atributo tiene un conjunto de propiedadesconfigurables por el programador, así cada modelo y cada objeto. Por ejemplo, la propiedad Theme seencontrará para configurar en los diálogos de propiedades asociados a cada modelo Web y a cada objetoque tenga form Web (transacciones y Web Panels).2 No solo existen clases para los controles en un tema, pero de esto no nos ocuparemos en este curso.



Controles en form Web

Ejemplo: transacción “Customer” con tema “Default”

De este modo, cuando el analista crea la transacción “Customer” e ingresa su estructura, al grabarpodrá apreciar que el form Web tendrá automáticamente el aspecto que se muestra en la pantalla dearriba a la izquierda. ¿Quién dio formato a todos los controles si no lo hizo el analista explícitamente?

Pues bien, todas las transacciones tendrán asociado por defecto el theme “Default” y todos los controlesque se coloquen en el form, tendrán clases de este tema asociadas.

Si sobre el botón “Apply Changes”, con el botón derecho del mouse se editan sus propiedades, se abriráun diálogo (que se presenta abajo a la izquierda) y en el mismo se puede observar la propiedad Class,que tiene configurada la clase BtnEnter que es una clase de botón. Esta propiedad puede ser cambiadapor el analista (podemos ver que se trata de un combo box). All cliquear el combo box podremos veruna lista de clases posibles para ese botón (son las que figuran en el tema asociado), pero tambiénaparece la opción “(none)” para no asociarle clase alguna. Esto es lo que hemos seleccionado en lapantalla de la derecha (el valor “none” para la propiedad Class del botón) y podemos ver su repercusióninmediata en el botón en el form.

Si se comparan los dos diálogos de propiedades del control “Apply Changes”, donde lo único que ha sidomodificado explícitamente por el analista ha sido la clase, podemos ver que implícitamente se hanmodificado algunas propiedades (el BackColor, ForeColor, BorderWith, etc.). Esto se debe a que estaspropiedades se heredan de la clase una vez definida, pero si el analista así lo desea, puede modificarlaspara ese control botón, independizándolo de seguir el comportamiento de su clase.

Sobre este tema podrá profundizar si así lo desea en el curso “Desarrollo de Aplicaciones para Internet”,tanto presencial como no presencial.

Aquí solamente pretendemos tener un barniz del uso de los temas y las clases de los controles.



Demo

¿Cómo crear un modelo dentro de la base deconocimiento?

WIZARD MANUAL

Para definir un nuevo modelo -a excepción del de Diseño, que se crea automáticamente-, debeseleccionarse la opción F ile / New Model.

GeneXus provee de un wizard para guiar al usuario en los pasos de creación del nuevo modelo.

Si el usuario prefiere no utilizar el wizard e ingresar los distintos datos sin esta guía, deberápresionar el botón Manual Creation de la primera pantalla del wizard, y éste se cerrará y se abriráel diálogo Model Properties.

A continuación se detalla parte de la información que se deberá ingresar:

Information

Name: Nombre del modelo que se está definiendo.

Type: Tipo de modelo (Prototipo o Producción).

Language: Idioma en el que saldrán impresos los textos de los botones, mensajes, etc., que songenerados automáticamente por GeneXus en los programas de la aplicación. Los lenguajessoportados son: Español, Inglés, Italiano, Portugués y Chino. El valor del lenguaje solo puedemodificarse en el modelo de Diseño de la base de conocimiento; los demás modelos heredaráneste valor y no podrán modificarlo.

Se debe suministrar información del ambiente o plataforma para el modelo que se está definiendo:

EnvironmentLanguage: Este es el lenguaje en el cuál serán generados los programas usados para la creacióny reorganización de la base de datos, y también es el lenguaje predeterminado en el que serángenerados todos los objetos. Pueden definirse ambientes secundarios en la solapa Environmentsdel diálogo, que permitirán generar algunos de los objetos en otros lenguajes. Los lenguajessoportados por GeneXus son: .NET, .NET Mobile, C/SQL, Cobol para iSeries, Java, RPG paraiSeries, Visual Basic, Visual FoxPro.



User Interface: Una vez que el lenguaje ha sido elegido, se puede seleccionar el tipo de interfaz que se quiere usarpara el ambiente principal: Win o Web Form. Existen lenguajes que solo soportan un tipo de interfaz.

DBMS: Aquí se debe seleccionar el DBMS (Database Manager System) sobre el cuál operarán los programas enejecución. La lista solo incluirá aquellos soportados por el lenguaje e interfaz previamente seleccionados.

Target Path: Directorio donde estarán ubicados los programas generados. Este directorio será creado bajo eldirectorio de la base de conocimiento. El valor predeterminado es DATAnnn, donde nnn representa el número demodelo (GeneXus numera secuencialmente los modelos a medida que se van creando).

A continuación se muestra una tabla con los valores de DBMSs posibles para cada lenguaje:

PropertiesHaciendo clic en el botón Properties se pueden configurar las propiedades para el lenguaje seleccionado. Solemosllamar a estas propiedades: propiedades a nivel del modelo o más reducido: propiedades del modelo.

DBMS OptionsHaciendo clic en el botón DBMS Options se puede configurar la información requerida para el acceso a la Base deDatos (Data Source, etc.) para el lenguaje y DBMS seleccionados.

ExecutionHaciendo clic en este botón, se pueden especificar configuraciones de ejecución para el lenguaje seleccionado.

Save/ LoadEstos botones permiten almacenar la información de las propiedades del modelo en un archivo (y luego recuperarlo).La extensión predeterminada de este archivo es GMP (GeneXus Model Properties).

From ModelPermite copiar la información en forma directa, desde otro modelo de Prototipo / Producción dentro de la base deconocimiento.

Una vez creado un modelo, es posible modificar sus propiedades. Para ello, se debe seleccionar la opción File / EditModel, y se presentará el diálogo Model Properties.

Suele ser usual acceder al diálogo Model Properties, en especial para utilizar los botones Propertie s, DBMS Optionsy Execution para configurar sus propiedades con los valores particulares que se requiera para el modelo. Sinembargo no es usual cambiar en el diálogo Model Properties lo configurado en la sección Enviroment (ya que si sedesea probar la aplicación para otra plataforma / ambiente, la forma correcta de proceder es crear otro modelo para laplataforma deseada).



¿Qué son los conceptos...?

Análisis de Impacto

Reorganizar

Especificar

Generar

Cuando se pasa a un modelo de Prototipo o Producción en una base de conocimiento, GeneXuscompara las definiciones realizadas en el modelo de Diseño, con respecto a las definiciones queexistan en el modelo al cual se está ingresando.

Por ejemplo, si se está ingresando a un modelo de Prototipo o Producción recientemente definido (ypor ende vacío), todos los objetos definidos en el modelo de Diseño serán nuevos para dichomodelo. Y las transacciones definidas, tal como es su objetivo, provocarán la creación de las tablasque corresponda en la base de datos asociada al modelo de Prototipo o Producción.

Esta comparación que hace GeneXus entre las definiciones del modelo de Diseño de una base deconocimiento y las definiciones de cierto modelo de Prototipo o Producción al cual el programadorpasa, se llama análisis de impacto. Este nombre es autodescriptivo: GeneXus analiza el impactocausado por las definiciones del modelo de Diseño sobre un modelo de Prototipo o Producción. Elresultado del análisis de impacto es un reporte de análisis de impacto (IAR: Impact AnalisisReport) que informa al programador qué cambios físicos o estructurales habría que realizar en labase de datos asociada al modelo de Prototipo o Producción en cuestión.

Si el programador está de acuerdo con los cambios estructurales informados en el reporte deanálisis de impacto, podrá proseguir, pasando a reorganizar la base de datos . El términoreorganizar refiere a efectuar cambios físicos en la base de datos.

Si en cambio el programador encuentra que algo de lo informado en el reporte de análisis deimpacto no era lo que pretendía lograr, podrá no efectuar la reorganización, y volver al modelo de

Diseño para realizar las redefiniciones que crea convenientes.

Cuando se decide efectuar una reorganización GeneXus genera programas (en el lenguaje elegidoen la definición de la plataforma del modelo) que implementan las modificaciones a realizar en labase de datos. La ejecución de estos programas tiene por resultado la obtención de una nuevaversión de la base de datos con los cambios efectuados.



Inmediatamente después de reorganizar la base de datos, se copiarán automáticamente las nuevas definicionesdel modelo de Diseño al modelo de Prototipo o Producción en el cual se esté trabajando (destino); esto se llamaCopy Model y significa que el modelo de Prototipo o Producción quedará con exactamente las mismas definicionesque el modelo de Diseño.

El siguiente paso será obtener los programas de aplicación asociados a los objetos GeneXus. Para ello elprogramador GeneXus deberá especificar y generar los programas de aplicación.

Especificar un objeto significa que GeneXus analizará todo lo definido en cada uno de los elementos que locomponen: estructura, forms, u otros elementos según corresponda. GeneXus verificará la sintaxis de las

definiciones, la validez de lo definido, y como resultado de la especificación mostrará al usuario un listado denavegación, en el cual informará la lógica que ha interpretado, y si hay alguna advertencia o error.

Luego de especificar un objeto (o conjunto de objetos) y verificar el listado de navegación resultante, elprogramador podrá indicar a GeneXus que prosiga con la generación de los programas de aplicación.Generar un objeto, significa que GeneXus escribirá lí neas de código que implementen la programación del mismo,en el lenguaje elegido.

Otro e jem p lo

Como hemos explicado, cuando se pasa a un modelo de Prototipo o Producción GeneXus realiza una comparaciónde las definiciones del modelo de Diseño con respecto a las definiciones que existan en el modelo al cual se estápasando. Esto es, un análisis de impacto.

Si se pasa a un modelo de Prototipo o Producción al cual ya se habí a pasado anteriormente alguna vez,seguramente dicho modelo ya tenga algunas definiciones1 , a diferencia del ejemplo anterior en el cual se tratabade un modelo nuevo y vací o.

Si por ejemplo el modelo de Prototipo o Producción al cual se está pasando tiene definida una transacción “Customer” con la estructura:

CustomerCustomerId* - Numeric(6)CustomerName - Character(20)CustomerAddress - Character(30)CustomerGender - Character(1)

y en el modelo de Diseño se encuentran definidas las transacciones “Customer” y “Product” con las siguientesestructuras:

Customer Product

CustomerId* - Numeric(4.0) ProducId* - Numeric(4.0)CustomerName - Character(30) ProductDescription - Character(20)CustomerAddress- Character(30) ProductPrice - Numeric(10.2)CustomerGender - Character(1) ProductStock - Numeric(4.0)CustomerEMail - Character(30)

el análisis de impacto determinará que en el modelo de Prototipo al cual se está ingresando, se deberá:

1.Agregar el atributo CustomerEMail en la tabla CUSTOMER de la base de datos.2.Agrandar el largo del atributo CustomerName a Character(30) en la tabla CUSTOMER de la base de datos.3.Crear la tabla PRODUCT con sus atributos en la base de datos.

Estos cambios se informarán en un reporte de análisis de impacto (IAR: Impact Analisis Report), y elprogramador deberá estudiarlo para decidir si efectuar la reorganización o no.

-------------------------------------------------------------------------------------------------------------------------1 Cabe la posibilidad de que en una base de conocimiento haya algún modelo de Prototipo o Producción sin objetos.Esto puede ocurrir por el simple motivo de que se haya creado un modelo, pero luego no se haya ejecutado unareorganización en el mismo, ni se hayan copiado las definiciones del modelo de Diseño (Copy Model) tampoco. Sinembargo, el ejemplo trata de un modelo Prototipo en el cual ya se ha ejecutado una reorganización y seguidamentese han copiado las definiciones del modelo de Diseño (Copy Model) al mismo.



En el caso de decidir reorganizar la base de datos, seguidamente se copiarán automáticamente las nuevasdefiniciones del modelo de Diseño al modelo de Prototipo, quedando éste con exactamente las mismas definicionesque el modelo de Diseño. (Copy Model).

Por último sólo restará que el programador GeneXus especifique y genere los programas correspondientes a losobjetos que hayan sufrido cambios.

Concluyendo, hemos explicado varios conceptos que son muy importantes, viendo una primera aplicación de ellos,

y luego una segunda aplicación de los mismos, con el objetivo de entender qué realiza cada una de estasoperaciones y en qué orden se ejecutan.



Ítem “Build” de la barra de menú de GeneXus

Opciones del ítem “Build” para especif icar y generar

El ítem Specify se habilitará cuando se esté en un objeto abierto; el objetivo de este ítem es especificar elobjeto activo.

El ítem Specify..., abrirá un diálogo de selección de objetos para seleccionar cuáles objetos se deseanespecificar.

Y el ítem Build All..., permitirá especificar todos los objetos del modelo.

Vale aclarar que será exactamente lo mismo seleccionar el ítem Specify... y elegir todos los objetos delmodelo para ser especificados, que seleccionar directamente el ítem Build All....

¿Cómo indicar que se desea generar los objetos?

Luego de especificar uno o varios objetos -mediante cualquiera de los ítems anteriores- GeneXus presentaráun listado de navegación por cada objeto especificado; cada listado de navegación informará cuál fue la lógicainterpretada para el objeto, y si será necesario generar el programa de aplicación asociado al mismo, o no1. Laventana que contiene los listados de navegación incluirá un botón de nombre Generate, que podrá serseleccionado por el programador para continuar con la generación de los programas de aplicación que seannecesarios.

Además del botón Generate, se ofrecerá también un botón Cancel. Es importante tener claro que en caso de

seleccionarlo, quedará pendiente la generación de los programas de aplicación asociados a los objetos quefueron especificados; esto significa que en la siguiente oportunidad que el programador seleccione el botónGenerate –así haya especificado en ese momento un solo objeto o varios- se generarán además de losprogramas que correspondan ser generados en esa ocasión, todos los programas pendientes de generación,por haberse especificado anteriormente sin continuar con la generación2.

--------------------------------------------------------------------------------------------------------------------1 El motivo por el cual un listado de navegación podrá informar que no será necesario generar el programaasociado a un objeto, es que el objeto no haya sufrido cambios con respecto a la última vez que se generó, ypor ende el programa generado antes seguirá estando vigente ahora.

2 Por esto solemos decir que podemos elegir qué objetos especificar, pero no cuáles generar.



¿En qué modelos se especifican y generan los objetos? ¿Diseño? ¿Prototipo? ¿Producción?

En los tres tipos de modelos es posible especificar los objetos, pero solamente en los modelos de Prototipo yProducción se podrán generar los programas de aplicación asociados a ellos.

Recordemos que todo modelo de Prototipo o Producción tiene asociada una plataforma (base de datos,lenguaje de programación, interfaz GUI-Windows / Web). En cambio, el modelo de Diseño no tiene asociadauna plataforma y por tanto no se generará para el mismo base de datos ni programas. Es por esto que en elmodelo de Diseño el programador podrá especificar objetos con el único objetivo de estudiar los listados de

navegación resultantes y con ello poder analizar la lógica interpretada por GeneXus para los mismos. Sinembargo, luego de estudiar listados de navegación en el modelo de Diseño, no será posible generar (no seofrecerá el botón Generate).

Es en los modelos de Prototipo y Producción en los que a continuación de la especificación de los objetos seofrecerá el botón Generate en la ventana que contiene los listados de navegación, para que el programadorpueda continuar con la generación de los programas de aplicación, en la plataforma definida para el modelo.

¿Qué objetos GeneXus se suelen especificar y generar? ¿Todos? ¿Algunos?

Solamente es necesario especificar los objetos que hayan sufrido cambios; esto es, objetos nuevos que sehayan definido, u objetos existentes que se hayan modificado.

Surge la necesidad en este momento de explicar un punto de suma importancia: en qué modelo de una basede conocimiento se deben realizar las distintas definiciones y/o modificaciones de objetos.

Únicamente en el modelo de Diseño de una base de conocimiento se podrán definir o editartransacciones, definir o editar atributos, y realizar modificaciones en las estructuras de lastransacciones en general (incluyendo definiciones de dominios, índices y subtipos1).

Para ser más exactos diremos que todas las operaciones que puedan provocar cambios estructuralesen las tablas de la base de datos podrán realizarse solamente en el modelo de Diseño. En modelos dePrototipo y Producción estarán deshabilitadas las operaciones de este tipo, y para realizarlas el programadordeberá pasar al modelo de Diseño de la base de conocimiento.

En modelos de Prototipo / Producción se podrán realizar definiciones que no provoquen cambios estructuralesen las tablas de la base de datos (por ejemplo, crear o modificar objetos reportes, procedimientos, workpanels, etc.; modificar reglas o forms de las transacciones, etc.1) y automática e instantáneamente seestarán realizando las mismas definiciones en el modelo de Diseño.

¿Cuál es la forma de trabajo entonces? Inicialmente se comienza a trabajar en el modelo de Diseño de unabase de conocimiento. Se definen las primeras transacciones y demás objetos y definiciones que se considerenoportunas. Luego el analista deberá crear un modelo de Prototipo para probar la ejecución de las definicionesrealizadas; habrá un análisis de impacto, reorganización, actualización del modelo de Prototipo (Copy Model), yel analista especificará y generará los programas de aplicación.

Se podrá ejecutar la aplicación definida hasta el momento, y luego de ello se continuará trabajando en elmodelo de Prototipo.

Todas las definiciones y/o modificaciones de objetos que se efectúen en el modelo de Prototipo, se efectuaránautomáticamente en el modelo de Diseño también; de modo que ambos modelos irán quedandoinstantáneamente con exactamente las mismas definiciones (sincronizados). Por este motivo es queaconsejamos trabajar en el modelo de Prototipo.

Cuando surja la necesidad de realizar definiciones que puedan afectar el diseño de la base de datos (porejemplo, crear una nueva transacción, modificar la estructura de una transacción existente, modificar un

dominio, etc.), habrá que pasar necesariamente al modelo de Diseño; pero si no, recomendamos trabajaren el modelo de Prototipo, ya que automáticamente el modelo de Diseño se estará actualizandotambién.

--------------------------------------------------------------------------------------------------------------------1 Más adelante en el curso se irán introduciendo estos temas.



¿Qué pasa si trabajamos en el modelo de Diseño? Si en el modelo de Diseño realizamos al menos unadefinición que implique modificar el diseño de la base de datos, cuando el programador pase al modelo dePrototipo, GeneXus detectará que habrá cambios físicos para hacer. Habrá un análisis de impacto,reorganización y actualización del modelo de Prototipo (Copy Model), y lo único que le restará hacer al analistaserá especificar y generar los objetos nuevos (que nunca hayan sido especificados y generados), y losobjetos existentes que hayan sido modificados luego de su última especificación.

Sin embargo si se trabaja en el modelo de Diseño solamente definiendo objetos que no implicarán modificarestructuralmente la base de datos, cuando el programador pase al modelo de Prototipo, GeneXus no detectarácambios físicos para hacer, y no efectuará ninguna operación, ni siquiera la actualización del modelo dePrototipo (Copy Model). De modo que las definiciones y modificaciones que se hayan hecho en el modelo deDiseño, no se copiarán automáticamente al modelo de Prototipo, y será responsabilidad del programadorhacerlo, seleccionando uno de los ítems posibles para ello1.

Es sumamente importante que un modelo de Prototipo/Producción con el cual se esté trabajando endeterminada etapa (veremos que podrán haber modelos en una base de conocimiento con los cuales no se estétrabajando momentáneamente), esté actualizado con respecto al modelo de Diseño (es decir, que siempre quese trabaje en el modelo de Diseño, al pasar al modelo de Prototipo, se ejecute la operación Copy Model, ya seaautomáticamente luego de ejecutar una reorganización, o a pedido del analista si no hubo reorganización).

Si se pasa a un modelo de Prototipo/Producción y éste no se actualiza con las definiciones del modelo deDiseño (Copy Model), los objetos del modelo de Prototipo/Producción al cual se pasó estarán desactualizados.Si se especifican y generan estos objetos, deberá comprenderse que se tratará de definiciones viejas; y si seejecuta la aplicación generada, no se verán las nuevas definiciones realizadas, ya que las mismas quedaronhechas en el modelo de Diseño, pero faltó que fueran copiadas al modelo de Prototipo, y recién luego de ello,se tendrían que haber especificado y generado.

Además, si el analista llegara a modificar objetos desactualizados en el modelo de Prototipo, la próxima vezque realice una actualización del modelo de Prototipo (Copy Model), se perderán las modificaciones realizadasen versiones viejas de los objetos, ya que se traerán las versiones de los objetos del modelo de Diseño.

Concluyendo, hemos recomendado en qué modelo definir qué objetos, cuándo habrá que pasar de un modelo aotro, y cuáles pasos seguir.

Como dijimos anteriormente, si bien es posible hacerlo en Diseño, la especificación de los objetos suelerealizarse en el modelo de Prototipo. En el modelo de Diseño no se generan programas a continuación de lasespecificaciones, y el único motivo por el cual se podría necesitar especificar algún objeto, sería porque se vayaa seguir trabajando en el modelo de Diseño realizando definiciones, y se necesite corroborar la lógicainterpretada por GeneXus acerca de uno o varios objetos que se hayan definido. De modo que no es necesario,ni mucho menos obligatorio, estar especificando los objetos en el modelo de Diseño.

En los modelos de Prototipo y Producción, en cambio, lógicamente será necesario especificar y generar losobjetos que hayan sufrido cambios, previamente a la ejecución de la aplicación.

Otras opciones del ítem “Build”

Todas las opciones que se describen a continuación se encuentran disponibles únicamente para modelos dePrototipo y Producción.

Bui l d / I m pact Dat abase

Al seleccionar esta opción, se ejecutará un análisis de impacto para el modelo en el cual se esté trabajando.Seguidamente se desplegará el reporte de análisis de impacto correspondiente.

Bui l d / I m pact Fro m

Un análisis de impacto siempre se efectúa comparando las definiciones del modelo de Diseño con lasdefiniciones del modelo actual o destino. No obstante, esta opción permite realizar un análisis de impactotomando cualquier modelo definido en la base de conocimiento como base, en relación al modelo actual.Al seleccionar esta opción se desplegará un diálogo para seleccionar cuál de todos los modelos definidos en labase de conocimiento se desea tomar como base para realizar un análisis de impacto para el modelo actual.

Es fundamental tener bien claras todas las acciones posibles que pueden desencadenarse al efectuar unanálisis de impacto:

-------------------------------------------------------------------------------------------------------------------1 Existen algunas opciones del menú que permiten hacer esto, con algunas variaciones y son las que sepresentan al final de esta página, bajo el título “Otras opciones del ítem Build”.



Sin embargo, puede ocurrir que no se desee ejecutar un análisis de impacto, ni reorganización consecuente, niactualización total del modelo actual, sino que solo se deseen copiar algunos de los objetos del modelo de Diseñoal modelo actual.

Bui ld / I m pac t Ob jec t s

Se desplegará la lista de objetos que tengan diferencias en el modelo de Diseño con respecto al modelo actual yse podrán seleccionar algunos de ellos, para copiarlos al modelo actual.

Importante: Deberá tenerse en cuenta que aunque la lista muestre todos los objetos que tengan diferencias enel modelo de Diseño con respecto al modelo actual, sólo podrán ser copiados aquellos objetos que usen la mismaestructura de base de datos en ambos modelos. Por ejemplo, una transacción no podrá copiarse al modelo actuasi se le ha agregado un nuevo atributo (en el modelo de Diseño) y aún no se ha efectuado la reorganizacióncorrespondiente. Resulta sencillo de entender que no sea posible solamente copiar una transacción al modeloactual, si la misma tiene implicada una reorganización pendiente para hacer.Para cada objeto de la lista que se haya seleccionado e intentado copiar al modelo actual, se informará si fueposible realizar la copia o no (y en caso negativo, el motivo).

Bui ld / Crea te Database

Se ejecutará un análisis de impacto para el modelo en el cual se esté trabajando, con la particularidad de que seanalizará el impacto causado por las definiciones del modelo de Diseño, sobre el modelo actual como si estuvieravacío. En consecuencia el reporte de análisis de impacto informará que se deberán crear todas las tablas con susestructuras vacías.



Ejecución de las aplicaciones

Build / Run:

Bajo el ítem Build de la barra de menú de GeneXus, se encuentra la opción Run para ejecutar las aplicacionesgeneradas.

Al seleccionar Build/Run o F5, se desplegará el diálogo de ejecución (Execution Dialog) mostrado arriba.

El diálogo de ejecución ofrece todos los programas posibles de ser compilados y ejecutados.Estos son:

1) Developer Menu: Es un programa que GeneXus genera automáticamente, y el mismo contieneinvocaciones a todos los objetos del modelo, para poder ser ejecutados, y testeados.

2) Objetos que se hayan definido main: Todo objeto puede ser definido main, lo cual significa que será elprincipal de un ejecutable.

GeneXus generará un ejecutable que contendrá al objeto mismo y a todos los que éste llame. Esto permitiráejecutarlo independientemente (en lugar de ejecutarlo mediante el Developer Menu).



Modos de las transaccionesen tiempo de ejecución

• Al ejecutar una transacción se pueden distinguir los siguientesmodos, dependiendo de la operación que se realice:

Modo Insert: Indica que se está efectuando una inserción

Modo Update: Indica que se está efectuando una actualización

Modo Delete: Indica que se está efectuando una eliminación

Modo Display: Indica que se está efectuando una consulta

Dependiendo del ambiente de generación, habrá algunas diferencias en lo que se refiere a laoperativa de las transacciones en tiempo de ejecución. No obstante, más allá de la plataforma, cadavez que se realice una operación de inserción, actualización, eliminación, o consulta a la base dedatos a través de una transacción, habrá un modo asociado.



INTEGRIDADREFERENCIAL



Diagrama de Bachman

CUSTOMER

COUNTRY

CustomerId*CustomerName

………Coun t r y I d

CountryId*CountryName

1

N

El concepto de integridad referencial es un concepto que tiene que ver con las bases de datosrelacionales.

Se refiere a que debe haber consistencia entre los datos de las distintas tablas de una base de datosrelacional.

Las tablas de una base de datos relacional se encuentran relacionadas por atributos que tienen en

común. Estas relaciones implican que los datos de las tablas no son independientes, sino que alinsertar, modificar y eliminar registros en una tabla, se deben tener en cuenta los datos de las otrastablas para que siempre se conserve la consistencia de la información en la base de datos.

Si tenemos un modelo de datos relacional con las tablas:

COUNTRY (CountryId, CountryName)Clave Primaria: CountryId

CUSTOMER (CustomerId, CustomerName, CustomerAddress, CustomerGender, CountryId)Clave Primaria: CustomerIdClave Foránea: CountryId (COUNTRY)

El hecho de que el atributo CountryId en la tabla CUSTOMER sea una clave foránea con respecto a latabla COUNTRY, establece una relación entre ambas tablas. La relación entre ellas puede verse en eldiagrama que mostramos arriba (Diagrama de Bachman).

En el Diagrama de Bachman, la flecha simple representa la existencia de una instancia de la tablaapuntada, para cada instancia de la otra (es decir, que para cada cliente existe un y solo un país). Laflecha doble representa la ocurrencia de varias instancias de la tabla apuntada, para cada instancia dela otra tabla (es decir, que para cada país, existen muchos clientes).

Se dice que la relación entre la tabla COUNTRY y la tabla CUSTOMER es 1 a N (1 a muchos).

Recíprocamente, la relación entre CUSTOMER y COUNTRY es N a 1 (muchos a 1).



Diagrama de Bachman

CUSTOMER

COUNTRY

1

N

En transacción “Customer”:• si se inserta nuevo registro, o• si se modifica el CountryId de un registro

Hay que verificar existencia del COUNTRY referenciado.

En transacción “Country”:• si se quiere eliminar un registro

Hay que verificar la no existencia deningún CUSTOMER que lo referencie.

CUSTOMER

COUNTRY

1

N

En la terminología GeneXus, decimos que existe una relación de subordinación entre ambas tablas.Decimos que:

COUNTRY está superordinada a CUSTOMER

CUSTOMER está subordinada a COUNTRY

Significando que:

• Cuando se crea o modifica un registro en la tabla subordinada (CUSTOMER), debe existir elregistro relacionado en la tabla superordinada (COUNTRY).

• Cuando se elimina un registro en la tabla superordinada (COUNTRY), no deben existir registrosrelacionados en la tabla subordinada (CUSTOMER).

Debido a esta relación entre las tablas, la información contenida en ellas no es independiente, y esnecesario realizar controles para que los datos sean consistentes. A estos controles se les llama deIntegridad Referencial y básicamente son los siguientes:

• Cuando se inserta o modifica un registro en la tabla CUSTOMER, el valor ingresado en el atributoque es clave foránea (CountryId), debe existir como valor de clave primaria de un registro en latabla COUNTRY.

• Cuando se elimina un registro en la tabla COUNTRY, no deben existir registros en la tablaCUSTOMER cuyos valores de la clave foránea (CountryId), sean iguales al valor de la clave primariadel registro que se desea eliminar.

GeneXus genera los programas asociados a las transacciones, incluyendo en el código generadoestos controles de Integridad Referencial. Por esta razón, si el usuario final inserta (o modifica) uncliente a través de la transacción "Customer", se validará automáticamente que el valor ingresado enel código de país CountryId, exista como clave primaria de un registro en la tabla COUNTRY. En casode fallar este control de integridad referencial, un mensaje se le desplegará al usuario indicándoleque no se encontró ese país.



Índices

Los índices son vías de acceso eficientes a las tablas.

GeneXus crea automáticamente algunos de ellos, y los otros deberán ser creados por elprogramador cuando éste así lo determine, basándose en criterios de optimización.

Existen cuatro tipos de índices en GeneXus:

• Primarios• Foráneos• De usuario• Temporales

De todos ellos, los únicos que no son creados automáticamente por GeneXus son los “de usuario”.

En cuanto a los tipos de índices que son creados por GeneXus, la diferencia que hay entre ellos esel momento en que son creados y el tiempo durante el cual se mantienen.

- Los índices primarios y foráneos son creados al momento de crear o reorganizar lastablas que componen la base de datos, y de ahí en más son mantenidosautomáticamente por GeneXus.

- Los índices temporales, en cambio, son creados al ejecutar las aplicaciones, paraacceder a tablas ordenadas por algún atributo o conjunto de atributos para el/los que noexiste un índice de usuario creado; éstos se crean en tiempo de ejecución de lasaplicaciones, se utilizan, y luego se eliminan.

ÍNDICES PRI MARI OS Y FORÁNEOSGeneXus crea para cada tabla un índice por su clave primaria ( índice primario), y un índice porcada clave foránea que la tabla tenga ( índices foráneos). ¿Por qué crear índices primarios yforáneos para las tablas desde el comienzo en forma automática, siendo que luego deben sermantenidos?

Sean las tablas COUNTRY y CUSTOMER, que vimos un par de páginas atrás, creadas en nuestromodelo de datos a partir de las estructuras de las transacciones "Country" y "Customer”. Existeentre estas tablas una relación 1-N, que viene dada por el hecho de que el atributo CountryId enla tabla CUSTOMER es una clave foránea con respecto a la tabla COUNTRY.



Índices primarios y foráneos

CustomerId*CustomerName

...Coun t r y I d


ICountryPK PK

FK

ICustomer

ICustomer1

1 Uruguay2 United States3 China

CountryId CountryName CustomerId CustomerName CountryId

4 Ana Diez 11 Juan Pérez 13 María Donoso 12 Jessica Deep 2

Si en transacción “Country” queremos eliminar

“United States”:

El programa debe buscar sobre CUSTOMERsi ∃ registro con CountryId = 2 para hacer eficiente esta búsqueda:

índice foráneo (ICustomer1)

Por existir esta relación, GeneXus incluye en los programas asociados a las transacciones"Country" y "Customer", los controles de integridad referencial pertinentes. Estos controles son:

• Si el usuario final inserta o modifica un cliente a través de la transacción "Customer", sevalidará automáticamente que el valor ingresado en la clave foránea CountryId exista como claveprimaria de un registro en la tabla COUNTRY. En caso de fallar este control de integridadreferencial, se le indicará al usuario que no se encontró ese país.

Para controlar esto, se debe buscar en la tabla COUNTRY la existencia de un registro que tengaese valor de CountryId como clave primaria; dado que se debe consultar la tabla COUNTRY,buscando por la clave primaria, resulta evidente que la búsqueda puede optimizarse si existe uníndice por la clave primaria en dicha tabla.

• Si el usuario final intenta dar de baja un país a través de la transacción “Country”, se validaráautomáticamente que no existan clientes con dicho país asociado, como clave foránea; en caso deencontrar un registro en la tabla CUSTOMER, cuyo valor de clave foránea CountryId sea el que sedesea eliminar, se le indicará al usuario que no es posible eliminar el país (ya que de lo contrarioquedarían datos inconsistentes en la base de datos).

Para controlar esto se debe consultar la tabla CUSTOMER, buscando por la clave foráneaCountryId. Esta búsqueda será óptima si existe un índice por CountryId en la misma.

Control de unicidad de clave primaria

Otro control que GeneXus también incluye en los programas asociados a las transacciones es launicidad de la clave primaria; esto es, en ninguna tabla podrán existir dos registros con el mismovalor en la clave primaria.

Para controlar esto, cuando el usuario final intenta insertar un registro se valida automáticamenteque el valor ingresado para la clave primaria no exista ya como clave primaria de otro registro enla tabla.

Para hacer esta búsqueda con eficiencia, se debe utilizar el índice primario de la tabla.

Concluyendo, GeneXus al crear cada tabla de la base de datos crea también su índice primario, yun índice foráneo por cada clave foránea que la tabla contenga.

La creación de estos índices permite realizar los controles de integridad referencial y deunicidad de clave primaria accediendo a las tablas de forma eficiente .



Índices de usuario

• Los crea el analista sobre una tabla. Deberácategorizarlos según si aceptará valores repetidos(duplicate) o no (unique).

• Si en la realidad modelada, un mismo nombre se puede repetirpara dos clientes:

CustomerId CustomerName CountryId

1 Ana 12 Ana 23 María 1

ÍNDICES DE USUARIO

Estos índices deben ser definidos explícitamente por el analista. No son definidosautomáticamente. Se dividen en duplicate y unique.

Un índice de usuario duplicate es aquel que se define para atributos de una tabla para los que

pueden existir varios registros con el mismo valor en los mismos (es decir, se define paraatributos que no son una clave candidata).

Este tipo de índices se define fundamentalmente para acceder a los datos ordenados pordeterminados atributos de forma eficiente.

A modo de ejemplo, suponiendo que el nombre de cliente no es clave en la tabla CUSTOMER (susvalores se pueden repetir) podremos definir un índice de usuario duplicate por el atributoCustomerName, siendo muy útil para realizar consultas y listados que se necesite salganordenados por nombre.

Un índice de usuario unique se utiliza para especificar que un conjunto de atributos es clavecandidata en una tabla (diferente de la clave primaria).

Esta es la forma de representar claves candidatas en el modelo de datos. Con ello logramos queGeneXus incorpore automáticamente el control de unicidad correspondiente en las transaccionesasociadas.

A modo de ejemplo, si el nombre de cliente no se puede repetir, la forma de representarlo y lograrque GeneXus lo controle automáticamente es definiendo en la tabla CUSTOMER un índice deusuario unique por el atributo CustomerName.



Índices de usuario

• Si un mismo nombre no puede repetirse (es por tanto unatributo clave de la tabla)

• La forma de definir claves candidatas en el modelo de datos esa través de índices unique. GeneXus pasará a incorporarcontroles en las transacciones, utilizando el índice, para nopermitir la inserción de registros duplicados.

CustomerId CustomerName CountryId

1 Ana Diez 12 Ana Pérez 23 María Rua 1

Si se intenta ingresar un nuevo cliente con nombre “Ana Pérez” la transacción dará un error de registro duplicado.

Índices unique (claves candidatas)

En una tabla de la base de datos pueden existir varios conjuntos de atributos cuyos valores seanúnicos en la realidad. Se dice que cada uno de esos conjuntos es una clave de la tabla. Luego, elanalista elige una de las claves como la clave primaria.GeneXus identifica la clave primaria de la tabla de acuerdo a los atributos que fueron calificadospor el analista con el símbolo de llave.

Supongamos que en la realidad además de poder identificar a un cliente por su código, también selo puede identificar por su cédula de identidad. En este caso tanto el atributo CustomerId como elatributo CustomerSSN (donde se almacena la cédula de identidad) serían claves de la tablaCUSTOMER. Al indicar que CustomerId es el identificador de la transacción, GeneXus crearáautomáticamente un índice primario por dicho atributo y controlará la unicidad de los valoresingresados para el mismo.

¿Y qué sucederá con la cédula de identidad del cliente? Al ser este atributo clave, quisiéramos queGeneXus obrara de igual manera, no permitiendo que se ingrese un registro, si es que ya existeotro con el mismo valor de cédula de identidad (CustomerSSN). Para poder controlar esto deforma eficiente, GeneXus debería contar con un índice por cada atributo clave.

La forma de definir en GeneXus que un atributo o conjunto de atributos es clave alternativa ocandidata y que por lo tanto se debe chequear su unicidad, es definiendo un índice de usuariocompuesto por ese atributo o conjunto de atributos, y calificándolo de “unique” en lugar de

“duplicate”, que es el valor por defecto de un índice de usuario.

A partir de allí, GeneXus incluirá en la lógica de la transacción ese control de unicidad utilizandoese índice definido por el usuario.

En resumen, las transacciones GeneXus realizan automáticamente los siguientescontroles:• Integridad referencial• Unicidad de clave (tanto primaria como candidatas)



Índices temporales• Son creados automáticamente, bajo ciertas condiciones,

cuando son necesarios, y se eliminan cuando termina laejecución del objeto que los creó.

• Si se desea acceder a los datos ordenados por determinadosatributos, pero no se desea crear un índice permanente paraello: GeneXus creará un índice temporal.

• Se crean solamente en algunas plataformas (como Visual FoxProcon base de datos local, o en iSeries).

• En otras plataformas, las consultas para las cuales se quiereobtener el resultado ordenado por determinados atributos, y noexiste el índice de usuario, son resueltas por el DBMScorrespondiente sin la creación de índices temporales.

• El usuario puede resolver dejar de utilizar un índice temporal,creando un índice de usuario.

ÍNDICES TEMPORALES

Si se desea acceder a los datos ordenados por determinados atributos, pero no se desea crear uníndice permanente para ello (por ejemplo, porque se trata de una consulta que se realiza con muypoca frecuencia), entonces, dependiendo de la plataforma, se creará un índice temporal.



Manejo de nulos

• Para cada atributo no inferido, ni identificador en laestructura de una transacción, es posible definir si admitiránulos o no, en la tabla asociada

La permisión o no del valor <NULL> en la base de datos es muy importante en el modelo relacional.Permitir el “valor” null para un atributo dado, significa que puede, bajo ciertas circunstancias, ser

“ignorado” dado que es “valor no especificado”. Por otro lado, si un atributo no permite valor null,un valor válido siempre deberá asignarse a él.

La propiedad Nulls (presentada como columna en el editor de estructuras de transacciones),permite configurar para cada atributo si admite o no valor null en la tabla asociada. Los atributos

para los cuales puede configurarse esto, es para aquellos almacenados en la(s) tabla(s) asociada(s)a la transacción (es decir, no inferidos) siempre y cuando no sean atributos primarios en dichastablas (ya que por definición las claves primarias no soportan valor null).

Resumiendo: el objetivo de esta propiedad es definir qué valor se va a almacenar en la base dedatos cuando no digitemos nada en el campo (el valor <NULL> o el valor empty).



Manejo de nulos

• Valores posibles que ofrece la propiedad Nulls:- No: el atributo en la tabla asociada, no permitirá valor null- Y es: el atributo en la tabla asociada, sí admitirá valor null

• Atributos parte de la clave primaria no soportanvalor null (propiedad Nulls = No, siempre)

• Atributos clave foránea sí, y esto tendrá repercusiónen los controles de integridad referencial.

Valor por defecto

Los valores posibles de configurar para la propiedad Nulls son:

No : significa que el atributo no permitirá el valor null en la tabla asociada (valor por defecto)

Yes: significa que el atributo sí admitirá el valor null en la tabla asociada

La definición de nulls es utilizada por GeneXus al momento de crear / reorganizar las tablas de la

base de datos, ya que el soporte o no soporte de nulabilidad de los atributos en su tabla,se define a nivel de la base de datos.

O sea que modificar el valor de la propiedad Nulls para un atributo implicará ejecutar unareorganización (para redefinir a nivel de la base de datos el soporte de nulabilidad del atributo en sutabla).



Manejo de nulos

• Repercusión en controles de integridad referencial

1) CountryId y CityId con propiedad Nulls=No

• Se realizan los chequeos de IR mostrados arriba

2) CityId con propiedad Nulls=Yes

• Se agrega un control de IR en CUSTOMER si se deja nulo CityId, serealizará chequeo contra COUNTRY.


CountryId*CityId*CityName

CustomerId*CustomerNameCountryIdCityId

FKcompuesta

Repercusión en controles de integridad referencial

La definición de nulls para atributos que conforman una clave foránea le dice a GeneXus cuánfuerte es la referencia a la otra tabla.

Si ninguno de los atributos que componen una clave foránea permiten valores nulos (caso 1),se tratará de una referencia fuerte (también conocida como “not null reference”), ya que

establece que la FK deberá siempre apuntar a un registro existente de la tabla referenciada.

Por el contrario, una clave foránea que tenga al menos un atributo que soporte nulos (caso 2),establece una referencia débil (también conocida como “null reference”), ya que si alguno delos atributos que conforman la clave foránea son nulls, entonces la referencia no seráchequeada.

Cuando una clave foránea es compuesta y están permitidos los nulos para algunos de susatributos, pueden aparecer nuevas referencias (no chequeadas en caso de tratarse dereferencias fuertes) si los atributos que restan componen también una clave foránea. Unejemplo es el que presentamos arriba, donde en caso de que el usuario deje nulo el valor deCityId para un cliente, se realizará el chequeo de IR contra COUNTRY, para asegurarse que elpaís ingresado sea correcto.



Manejo de nulos

• Diferencia entre valor empty y null para atributos:

• empty: es un valor (0 para Numeric, “” para Character, etc.)

• null: si está permitido, no es un valor. Significa que el valor debeser considerado como:

• no especificado• no disponible• no asignado• desconocido

• Métodos según si atributo permite null o empty:

• IsEmpty

• IsNull• SetEmpty• SetNull

Métodos para trabajar con nulos y vacíos

IsEmpty, IsNull: devuelven true en caso de que el atributo contenga valor empty o nullrespectivamente.

SetEmpty, SetNull: configuran en el atributo el valor empty o null, respectivamente.

Ejemplos:

* error(‘You must specify a name’) if CustomerName.IsEmpty();

* msg(‘Warning: You didn’t specify a Country’) if ContryId.IsNull();



TABLA BASEY

TABLA EXTENDIDA



Tabla Base y Tabla Extendida

Definición

Dada una tabla X de la base de datos, a la cual llamamos “tablabase”, se denomina “tabla extendida” de la misma al conjunto deatributos conformado por:

• Atributos que pertenecen a la tabla X.• Atributos de toda tabla Y, tal que la relación entre la tabla

extendida determinada hasta el momento y la tabla Y seaN-1.

Los criterios de normalización del diseño de la base de datos apuntan a minimizar la posibilidad deinconsistencia en los datos. Una base de datos diseñada de esta manera tiene una serie de ventajasimportantes (tal es así que actualmente la normalización de datos es un estándar de diseño), perose 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 lotanto cuando se quieren hacer consultas más o menos complejas a la base de datos, se debeconsultar una cantidad importante de tablas.

Así, por ejemplo, si el siguiente Diagrama de Bachman representa nuestro modelo de datos:

para listar las facturas sería necesario consultar las tablas: INVOICE e INVOICELINE (líneas deFacturas), CUSTOMER, COUNTRY y PRODUCT.

Para simplificar esta tarea GeneXus utiliza el concepto de tabla extendida.

Llamamos tabla base a cualquier tabla de la base de datos en la cual estemos posicionados endeterminado momento; y dada cierta tabla base, su tabla extendida comprenderá a todos losatributos de la propia tabla base, más todos los atributos de las tablas que tengan informaciónrelacionada unívocamente con la tabla base (relación N-1 desde la tabla base, directa eindirectamente).



INVOICE CUSTOMER COUNTRY

INVOICELINE PRODUCT

InvoiceId*InvoiceDateCustomerId

CustomerId*CustomerNameCountryId


InvoiceId*ProductId*

InvoiceLineQuantityInvoiceLineAmount

ProductId*ProductDescription

ProductPriceProductStock


Utilizando el Diagrama de Bachman es fácil determinar cuál es la tabla extendida correspondientea una tabla base cualquiera:

Partiendo de la tabla base, se deben seguir las relaciones N-1, (es decir, se deben seguir las flechasque tienen punta doble partiendo desde la tabla base, y punta simple en el otro extremo).

Todas las tablas a las cuales se pueda llegar siguiendo las flechas que representan relaciones N-1desde la tabla base, formarán parte de su tabla extendida.




Para cada tabla de nuestro modelo de datos, describimos cuál es su tabla extendida.



Descripciones en vez de Códigos

Country TransactionCountryID*CountryName

Customer TransactionCustomerID*CustomerNameCountryIDCountryName

Este atributo no es CountryName, sinoCount ry I d disfrazado de Coun t r yName .Se muestra (y acepta) en ejecución el valor deCountryName, mientras que lo que se almacenaes CountryId.

Hasta ahora hemos visto que el usuario final debe manipular los códigos con los que el sistema identificaa sus entidades. Por ejemplo, a la hora de ingresar un nuevo cliente a un sistema, vimos que el usuariofinal ingresa el código del país de ese cliente y a continuación se le muestra en forma inferida, el nombrecorrespondiente a ese país.

Para ello debe memorizar un código que no tiene demasiada carga semántica (ninguna cuando éstos sonnuméricos) o apelar a prompts para poder buscar por descripción o nombre y recuperar así el código a sercolocado en el campo.

Sin embargo no es necesario condenar al usuario a que manipule códigos. Puede manipular lasdescripciones, que son las que contienen la semántica y el programa se encargará del resto. Es posible(tanto en Win como Web, Java y .Net) que el usuario trabaje en pantalla con la descripción,CountryName, y que automáticamente se resuelva la manipulación del código, CountryId.

¿Cómo? Modificando el valor de la propiedad InputType del atributo CountryId.

El usuario verá en pantalla el CountryName, pero el atributo que muestra esos valores ¡no esCountryName! Por el contrario, es el atributo: CountryId “disfrazado” de CountryName.

Mientras el usuario escribe “Uruguay” internamente se realiza una búsqueda en la tabla COUNTRY pararecuperar el código correspondiente a ese nombre. Ese valor, en nuestro ejemplo, 1, es el que realmentequeda almacenado allí. Pero para el usuario esto es absolutamente transparente.

Para que esto pueda lograrse, deberá haber una relación biunívoca entre el código (o identificador) y ladescripción. Es decir, para cada descripción solo existirá un código asociado. En el ejemplo, no deberáhaber dos o más países con el mismo nombre y distinto identificador, porque en ese caso no es posible

realizar el matcheo.

Dicho en otras palabras: el atributo descriptivo deberá ser una clave candidata de la tabla, es decir,deberá existir un índice unique para ese atributo.

En caso de no existir, en el listado de navegación de la transacción se mostrará la siguiente advertencia:

Spc0107 Candidate Key CountryName for CountryId may have duplicated values.

y en ejecución, si el usuario selecciona un valor duplicado (para el que existen varios CountryId) dará unerror “Country is ambiguous”, dado que no sabrá con cuál quedarse.



Propiedad InputType del atributo identificador

Valores posibles:

• Valuesatributo real: lo quemuestra es su contenido

• Descriptionsatributo disfrazado: tomalas descripciones deotro atributo, aunque sucontenido sigue siendo elpropio.

Descripciones en vez de Códigos

En la figura se muestra el diálogo de definición del atributo CountryId.

Como podemos ver, en la solapa Control Info del diálogo de definición del atributo, aparece lapropiedad InputType. Esta propiedad solo se ofrece cuando el atributo está asociando a uncontrol de tipo Edit (no Radio Button, Combo, etc.).

Esta propiedad puede tomar uno de dos valores:

• Values: representa el comportamiento conocido, es decir, el control en el form en ejecuciónmostrará los valores que contiene (códigos).

• Descriptions: aquí es donde le indicamos que queremos que “disfrace” sus valores en ejecución,mostrándole al usuario no sus valores reales, sino los asociados y definidos en la propiedad que sehabilita: Descriptions from.

En la propiedad Descriptions from se debe indicar de qué atributo se tomarán las descripciones.Evidentemente este atributo no puede ser cualquiera: debe tener una relación biunívoca con el queestamos definiendo, y además, debe ser un atributo de descripción , es decir, un atributo cuyotipo de datos sea Character o Varchar.

De lo contrario se arrojará el siguiente error de especificación:spc0112: Item value %1 for control %2 must be Character or VarChar.



Como en casi todos los casos, cuando una propiedad tiene que ver con la forma en que un atributofunciona a nivel de pantalla (control), existe la posibilidad de configurar su comportamiento:

1- En forma centralizada: Es decir, a nivel de la definición del atributo en sí (en la solapa Control Infoasociada a la definición del atributo), para que aplique por defecto en todos los forms en donde el atributoesté presente como control

2- En forma particular: Es decir, para un control atributo en concreto de un form determinado (en lasolapa Control Info asociada a la definición del control).

Definición en forma centralizada (a nivel del atributo)

En el caso de configurar la propiedad IntputType a nivel de atributo, en toda transacción en la que esteatributo sea clave foránea (FK), GeneXus colocará en el form de la transacción, el valor de la propiedadTitle, del atributo elegido como descriptor (en este caso el title de CountryName) y a su lado alatributo identificador (en este caso la FK CountryId), que mostrará los valores de CountryName, peroalmacenará los de CountryId.

Como resulta evidente, ya no es necesario que en el form se coloque el atributo real CountryName, porqueel atributo CountryId “se disfrazó” de él. El usuario no sabrá que mientras él está seleccionando oescribiendo un nombre de país, en realidad lo que se está grabando en ese atributo es el código oidentificador correspondiente.

GeneXus quita automáticamente del form el atributo descriptor al momento en que la FK es definida conInputType= Description.

Sin embargo, el atributo descriptor debe estar presente en la estructura de la transacción, pues de locontrario dará el siguiente error al especificar:

Spc0109 CountryName is (part of) a candidate key. It must be referenced in the transaction’sstructure.

En la transacción en la que el atributo identificador con InputType=“Description” es clave primaria, comoresulta evidente, no toma ningún efecto esta propiedad. Es decir, en la transacción “Country” el atributoCountryId se verá en ejecución conteniendo códigos, y el atributo CountryName esperará ser ingresado condatos del usuario.



Descripciones con autocomplete

Aquí estamos combinando 2 propiedades: InputType y Suggest, loque no es obligatorio.

Podemos hacer que en lugar de queel usuario tenga que recordar losvalores existentes para ingresar unocorrecto, se le sugieran los valoresposibles para ese control, de modoque él pueda elegir el que deseaba yque será necesariamente correcto.

Propiedad Suggest

La propiedad Suggest posibilita brindarle una ayuda útil al usuario final, para que elija en tiempo deejcución para un control edit, entre un conjunto de valores posibles y no tenga que recordar

“exactamente” el valor.

Al igual que la propiedad InputType, aplica a controles edit y puede ser usada tanto en transacciones,como en Web y Work panels, objetos de los que hablaremos más adelante.

Habilitando la propiedad Suggest en un control edit, se conseguirá que una lista de posibles valorespara ese control sea desplegada al usuario, debajo del control.

La lista de sugerencias puede ser calculada de un modo incremental (la lista será actualizada con lasentradas del usuario) o haciendo pedidos explícitos (el usuario manualmente tendrá que hacer unpedido para que se calculen las sugerencias y se le muestren). La actualización de la lista esasincrónica y los tiempos de cálculo dependen de la calidad de la conexión.

Esta propiedad es independiente de la propiedad InputType, aunque la utilización combinada deambas producirá aplicaciones con interfaces mucho más amigables para el usuario.



Valores posibles:• Incremental• No• OnRequest

El control para CountryIddisfrazará sus valores porlos de CountryName, queahora le serán sugeridos alusuario a medida que vayadigitando letras del nombre

Descripciones con autocomplete

Propiedad Suggest

Si miramos un par de páginas atrás, cuando vimos la propiedad InputType, teníamos la mismapantalla de propiedades para el atributo CountryId, solo que el valor que teníamos especificado en lapropiedad Suggest era el valor por defecto: “No”. En ese caso el usuario tenía que digitar el nombredel país sin recibir ayuda alguna. Si se cambia el valor de esta propiedad a “Incremental” u

“OnRequest” se brindará ayuda al usuario para que elija en tiempo de ejecución entre los valoresposibles y no tenga que recordar “exactamente” el valor.

Valores de la propiedad Suggest:

•Incremental: Se le irán sugiriendo al usuario los valores que correspondan con lo que hayadigitado hasta el momento. Es incremental, puesto que va reduciendo el rango de lo mostradointeractivamente a medida que el usuario va agregando letras a lo que lleva digitado hasta elmomento.

•OnRequest: La única diferencia que tiene el valor Incremental es que en este caso no esinteractivo. El usuario ingresará el substring que recuerde de la palabra y luego pedirá explícitamentelas sugerencias de las palabras que empiecen por o contengan esa cadena. Por ejemplo, si el usuariofinal sabe que un cliente que está buscando tiene apellido Pérez, pero no recuerda el nombre, puedeescribir “Pérez” y pedir las sugerencias.

Si tuviera configurado el valor “Incremental” en esta propiedad, entonces al digitar “P” de “Pérez” yase le traerían todos los nombres de clientes que empiezan con “P” y se iría afinando la búsqueda a

medida que siga escribiendo letras.

•No : no sugiere nada. Este es el valor por defecto, y en este caso el usuario no recibirá ningún tipode ayuda para ingresar el valor en el campo.

Para lograr que el usuario trabaje con descripciones en lugar de códigos, otra posibilidad esconfigurar que el atributo CountryId utilice el control: combo box dinámico (indicándose también eneste caso, que se muestren los nombres de los países existentes en la tabla COUNTRY(CountryName), mientras que al momento de seleccionar uno en el combo, quedará el códigocorrespondiente en el atributo CountryId.



Reglas

• Se utilizan para definir el comportamiento de las transacciones.• Algunas reglas:

• Pueden incluir: atributos, variables, constantes y funciones.

• Son LOCALES a la transacción.• Programación DECLARATIVA.

DefaultAsignaciónMsgErrorNoacceptAddSubtractSerialUpdate

Las reglas, en el objeto transacción, cumplen un rol muy importante ya que permiten programar sucomportamiento (por ejemplo: asignar valores por defecto, definir controles sobre los datos, etc.).

Se escriben de forma declarativa, es decir que el orden en el que se escriben no significa que sea elorden en el que se ejecutarán.

Pueden involucrar a los atributos definidos en la estructura de la transacción1, así como a

variables definidas dentro del objeto, constantes y funciones.

Son solo válidas dentro de la transacción en la que están definidas, es decir, son locales.

--------------------------------------------------------------------------------------------------------1 Todas las reglas de transacciones pueden involucrar atributos de las tablas base asociadas a latransacción; y la mayor parte de ellas puede también involucrar atributos de las tablas extendidas dedichas tablas base. Para poder referenciar un atributo en una regla, el mismo deberá estar incluido enla estructura de la transacción (ya sea que pertenezca a alguna de las tablas base asociadas a latransacción, o a sus tablas extendidas).



Algunas reglas válidas para transacciones son:

Default

OBJETIVO: Permite asignar un valor por defecto a un atributo o variable; el valor por defecto inicializará al atributo ovariable si se está realizando una inserción por medio de la transacción (modo Insert), pero el usuario final podrácambiarlo si ese valor no es el que desea.

SINTAXIS: Default( att | & var, exp );

DONDE:• att: es un atributo perteneciente a alguna de las tablas base asociadas a la transacción.• var: es el nombre de una variable.• exp: es una expresión que puede involucrar constantes, funciones, variables u otros atributos.

FUNCIONALIDAD: Esta regla asigna el valor de la expresión exp como valor por defecto del atributo att o variable var,cuando la transacción se ejecuta en modo Insert.

Esta regla no es válida para atributos que forman parte de la clave primaria de alguno de los niveles de la transacción,porque es disparada luego de que la clave es ingresada (ya que solo en ese momento el modo es conocido y estaregla se dispara solo en modo Insert).

EJEMPLOS:Default( InvoiceDate, &today ); /*Regla definida en la transacción “Invoice”*/

Cuando se está insertando una factura nueva, se sugiere como valor de InvoiceDate el valor contenido en la variabledel sistema today.

Default( InvoiceDate, Today()); /*Regla definida en la transacción “Invoice”*/

Análoga a la anterior, solo que en lugar de utilizar la variable del sistema today, se utiliza la función Today quedevuelve la fecha correspondiente al día.

Default( InvoiceLineAmount, ProductPrice*InvoiceLineQuantity); /* Regla definida en “Invoice” */

Cuando se está insertando una línea de factura, se sugiere que el atributo InvoiceLineAmount (importe de la línea)tome el valor resultante de evaluar la expresión ProductPrice*InvoiceLineQuantity (precio del producto por cantidadllevada del mismo).

Nota: El tipo de datos de la expresión debe coincidir con el tipo de datos del atributo o variable

Regla de asignación

OBJETIVO: Permite asignar a un atributo o a una variable, el valor de una expresión.

SINTAXIS: att | & var = exp [if cond] [on evento/momento de disparo];

DONDE:• att: es un atributo perteneciente a alguna de las tablas base asociadas a la transacción, o a sus tablas extendidas(debe estar declarado en la estructura).• var: es el nombre de una variable.• exp: es una expresión que puede involucrar constantes, funciones, variables u otros atributos, y debe ser del mismotipo que att o var.• cond: es una expresión booleana (puede contener los operadores lógicos and, or, not)• evento/momento de disparo: es uno de los eventos predefinidos de GeneXus disponibles para reglas detransacciones, que permiten definir el momento específico de ejecución de una regla.

FUNCIONALIDAD: Una regla de este tipo permite asignar al atributo o variable de la izquierda, el valor resultante deevaluar la expresión. Como puede verse, la condición es opcional; de no ponerla, la asignación se realiza siempre.

La asignación a un atributo, implica su actualización en el registro que corresponda. Se pueden definir reglas deasignación a atributos de alguna de las tablas bases asociadas a la transacción, e incluso de sus tablas extendidas.Esto significa que pueden actualizarse atributos inferidos en una transacción (siendo necesario declararlos en laestructura).

EJEMPLO:

InvoiceLineAmount = ProductPrice*InvoiceLineQuantity; /*Regla definida en la transacción “Invoice”*/

Si el importe de cada línea de una factura se calcula siempre multiplicando el precio del producto por la cantidadllevada del mismo, podemos utilizar esta regla de asignación para liberar al usuario de realizar el cálculo.



Error

OBJETIVO: Permite desplegar un mensaje de error si la condición se satisface. Sirve para definir los controles que debencumplir los datos.

SINTAXIS: Error( ‘msg’ | & var | character expresion, msgId ) if cond [on evento/momento de disparo];

DONDE:• msg: es un string con un mensaje de error a desplegar.

• var: es el nombre de una variable de tipo character, que contiene un string con un mensaje de error a desplegar.• character expression: es una expresión cuyo tipo resultante es character y que será desplegada.• msgId: es un string (sin espacios en blanco ni comillas) que será utilizado solo si la transacción es definida tambiéncomo business component1.• cond: es una expresión booleana (que puede contener los operadores lógicos and, or, not)• evento/momento de disparo: es uno de los eventos predefinidos de GeneXus disponibles para reglas de transacciones,que permiten definir el momento específico de ejecución de una regla.

FUNCIONALIDAD: Esta regla despliega el mensaje del parámetro msg, var o character expresion, si la condición cond quese evalúa resulta verdadera. El mensaje de error se despliega en una ventana popup cuando el ambiente de trabajo esWindows y en el control Error Viewer y/o un cuadro de texto cuando el ambiente de trabajo es Web, deteniendocualquier actualización a la base de datos. Cuando la transacción se ejecuta como business component1, dedispararse el error, generará una entrada en el SDT messages, con identificador msgId.

EJEMPLOS:

Error(‘No se permiten clientes sin nombre’) if CustomerName.isEmpty(); /*Regla definida en la transacción “Customer”*/

Se evalúa la condición CustomerName.isEmpty(), y si ésta se satisface, se despliega el mensaje ‘No se permiten clientessin nombre’ en pantalla. No se permite continuar hasta que el usuario ingrese un nombre en el campo CustomerName oabandone la transacción (en cuyo caso no se hará en la base de datos actualización alguna).

Error(‘No se permite eliminar facturas’ ) if Delete; /* Regla definida en la transacción “Invoice” */

Se necesita prohibir la eliminación de facturas. Con esta regla, si el usuario intenta realizar una eliminación, la condicióndará True y se disparará la regla, evitando la eliminación.

Msg

OBJETIVO: Permite desplegar un mensaje de advertencia si la condición se satisface.

SINTAXIS: Msg( ‘msg’ | & var | character expresion, msgId) if cond [on evento/momento de disparo];

DONDE:msg, var, character expresion, msgId, cond, evento/momento de disparo: son los mismos que para la regla error.Observar que la sintaxis es exactamente la misma.

FUNCIONALIDAD: Esta regla se utiliza para presentar mensajes de advertencia al usuario. Despliega el mensaje deprimer parámetro, si la condición se satisface, análogamente a la regla Error; pero a diferencia de esta última, permitecontinuar con la ejecución si la condición sigue satisfaciéndose. Del mismo modo, si la transacción es businesscomponent1, de dispararse la regla genera entrada en el SDT messages.

Los mensajes de advertencia se despliegan en una ventana popup en ambiente Windows y en el Error Viewer o cuadro detexto en ambiente Web.

EJEMPLO:

Msg ( ‘No se permiten clientes sin nombre’ ) if CustomerName.isEmpty();

/*Regla definida en la transacción “Customer”*/Se evalúa la condición CustomerName.isEmpty(), y si ésta se satisface se despliega el mensaje ‘No se permiten clientessin nombre’ . A diferencia de lo que ocurre con la regla Error, aquí sí se permite continuar la ejecución, pues no se trata deun error sino de una advertencia.

--------------------------------------------------------------------------------------------------------------------------------1 Estudiaremos este tema más adelante en el curso.



Noaccept

OBJETIVO: Permite indicar que los atributos no aceptarán valores por parte del usuario (serán solo de salida).

SINTAXIS: Noaccept( att1[, atti]…) [if cond];

DONDE:atti: es un atributo perteneciente a alguna de las tablas bases asociadas a la transacción.cond: es una expresión booleana (puede contener los operadores lógicos and, or, not).evento/momento de disparo: es uno de los eventos predefinidos de GeneXus disponibles para reglas de transaccioneque permiten definir el momento específico de ejecución de una regla.

FUNCIONALIDAD: En una transacción, todos los atributos que pertenecen a las tablas base asociadas a la transacción, pdefecto son aceptados. Si queremos que algunos atributos con estas características no sean aceptados, entoncecontamos con la regla Noaccept.

EJEMPLO:Noaccept( IvoiceDate) if Update; /* Regla definida en la transacción “Invoice” */

Si se está modificando una factura (modo Update), no se permite que se modifique su fecha.

Subtract

OBJETIVO: Sustrae el valor de un atributo al valor de otro atributo, si se satisface la condición especificada.

SINTAXIS: subtract(att1, att2) [if cond];

DONDE:att1, att2: son atributos pertenecientes a alguna de las tablas base asociadas a la transacción, o a sus tablas extendida(y deben estar declarados en la estructura)cond: es una expresión booleana (que puede contener los operadores lógicos and, or, not).

FUNCIONALIDAD: La sustracción se realiza teniendo en cuenta el modo en el que se esté trabajando en la transacció(Insert, Update o Delete).

En modo:- Insert: se le sustrae al valor del atributo att2, el valor del atributo att1- Delete: se le suma al valor de att2, el valor del atributo att1- Update: se le sustrae al valor del atributo att2, la diferencia entre el valor nuevo y el viejo de att1

EJEMPLO:

En la transacción “Invoice”, cada vez que se ingresa una línea con un producto que se está comprando, se debe disminu

el stock del mismo, según la cantidad llevada.Esto podría hacerse en forma sencilla con la siguiente regla de asignación:

ProductStock = ProductStock – InvoiceLineQuantity;

Si prestamos atención, sin embargo, vemos que esta regla no nos sirve, pues no está condicionada a un modo particularazón por la cuál se disparará tanto cuando se está insertando una nueva línea en la factura, como cuando se eseliminando o modificando una ya existente. Y en estos últimos dos casos es incorrecto disparar la regla.

De hecho, cuando se esté eliminado una línea existente, debe realizarse la operación contraria, es decir, se de “devolver” al stock lo que se había quitado cuando se insertó la línea.

Lo correcto entonces, teniendo en cuenta todos los casos posibles sería tener 3 reglas:

ProductStock = ProductStock – InvoiceLineQuantity if Insert;ProductStock = ProductStock + InvoiceLineQuantity if Delete;ProductStock = ProductStock + old(InvoiceLineQuantity) – InvoiceLineQuantity if Update;

Aquí estamos utilizando la función “old”, que devuelve el valor almacenado del atributo (es el valor antes de modificarloPara evitar tener que hacer todo esto, GeneXus provee la regla subtract que se encarga de hacer la asignación correcde acuerdo al modo. Entonces podemos sustituir las 3 asignaciones anteriores, por:

subtract( InvoiceLineQuantity, ProductStock);

Esta regla tiene la inteligencia para, dependiendo del modo, restar o sumar.



Add

OBJETIVO: Suma el valor de un atributo al valor de otro atributo, si se satisface la condición especificada

SINTAXIS: add( att1, att2) [if cond];

DONDE:att1, att2: son atributos pertenecientes a alguna de las tablas base asociadas a la transacción, o a sus tablas extendida(y deben estar declarados en la estructura).cond: es una expresión booleana.FUNCIONALIDAD: La adición se realiza teniendo en cuenta el modo en el que se esté trabajando en la transacción (InseUpdate o Delete).

En modo:

- Insert: se le suma al valor del atributo att2, el valor del atributo att1

- Delete: se le sustrae al valor de att2, el valor del atributo att1

- Update: se le suma al valor del atributo att2, la diferencia entre el valor nuevo y el

viejo de att1

EJEMPLO:Definimos en la transacción “Customer”, un atributo de nombre CustomerTotalPurchases, para registrar el importe totde compras efectuadas por el mismo. El comportamiento que se desea es que cada vez que se cree una factura para ucliente dado, se le sume el total de la factura ( InvoiceTotal) al total de compras efectuadas por el clien(CustomerTotalPurchases).

Al igual que vimos en la regla subtract, no debemos olvidar que en la transacción “Invoice” podemos también eliminarmodificar facturas, y no solo crearlas; por lo tanto es importante tener en cuenta el modo de trabajo en la transacció(Insert, Update, Delete). GeneXus nos libera de tener que considerar nosotros a los modos, teniendo que escribir lasiguientes tres reglas de asignación en la transacción “Invoice”:

CustomerTotalPurchases = CustomerTotalPurchases + InvoiceTotal if Insert;CustomerTotalPurchases = CustomerTotalPurchases – InvoiceTotal if Delete;CustomerTotalPurchases = CustomerTotalPurchases – old(InvoiceTotal) + InvoiceTotal if Update;

y en su lugar nos provee de la regla add, que se encarga de sumar o restar, dependiendo del modo.

Así es que si en la transacción “Customer” agregamos el atributo CustomerTotalPurchases (total de compras del cliente):

CustomerId*CustomerNameCustomerAddressCustomerGender...CustomerTotalPurchases

y en la transacción “Invoice” inferimos al atributo CustomerTotalPurchases, ya que pertenece a la tabla extendida podemos definir la regla:

add( InvoiceTotal, CustomerTotalPurchases );

y logramos el comportamiento deseado, que es:

• si se inserta una factura (Insert): se le suma al valor del atributo CustomerTotalPurchases el valor del atribuInvoiceTotal• si se elimina una factura (Delete): se le sustrae al valor del atributo CustomerTotalPurchases el valor del atribuInvoiceTotal• si se modifica una factura (Update): se le suma al valor del atributo CustomerTotalPurchases, la diferencia entre el valnuevo y el viejo de InvoiceTotal



Serial

OBJETIVO: Permite numerar serialmente atributos numéricos.

SINTAXIS: Serial( att1, att2, step);

DONDE:

• att1: es un atributo perteneciente a alguna de las tablas base asociadas a la transacción (es decir, no

inferido), que desea autonumerarse (debiendo estar declarado en la estructura).• att2: Tiene que pertenecer a una tabla directamente superordinada a la del atributo at t 1.

• step: es el paso o incremento de la serialización.

FUNCIONALIDAD: El propósito de esta regla es asignar un número correlativo a att1 cada vez que se inserta unregistro en la tabla a la que pertenece att1. Se toma el valor de att2 (att2 contiene el último número utilizado enla autonumeración), se le suma el valor del parámetro step, y el valor resultante se asigna tanto al atributo att1

del nuevo registro, como al atributo att2 para conservar el último número asignado.

Es decir, cuando se está insertando un registro por medio de una transacción en la cual se hadefinido la regla: Serial(att1, att2, step);, se accede al att2 (habrá un solo valor de este atributo relacionado,pues pertenece a una tabla directamente superordinada1), se le suma el valor step, y se asigna el valor obtenidotanto a att1 del registro que va a ser insertado, como a att2 perteneciente a una tabla directamentesuperordinada con respecto a la tabla que contiene a att1.

Si se diseña a la transacción “Invoice” conteniendo un Número de Línea de Factura (atributo InvoiceLineId)como identificador único del segundo nivel, la estructura de la transacción sería:

InvoiceId*CustomerIdCustomerNameInvoiceDateI nv oiceLast LineI d

(I nvoiceLin eI d *ProductId

ProductDescription……)

En este diseño el atributo ProductId no es identificador único del nivel, sino clave foránea únicamente.

Cada línea tiene un número de línea que la identifica en forma única, y es posible ingresar el mismo producto endistintas líneas.

Podría ser útil asignar por medio del sistema, números correlativos al campo I nv oiceLin eI d , definiendo laregla:

serial(InvoiceLineId, InvoiceLastLineId, 1);

El primer parámetro de la regla serial define cuál es el atributo a numerar automáticamente, en el segundoparámetro debe indicarse un atributo cuya función es guardar el último valor asignado hasta el momento, y porúltimo el tercer parámetro es para indicar el incremento (en este caso se incrementa de uno en uno).

El segundo parámetro (en el ejemplo InvoiceLastLineId) debe pertenecer a una tabla directamentesuperordinada a la tabla que contiene el atributo que se desea numerar automáticamente (InvoiceLineId). La

regla serial lo requiere así. En el ejemplo, se puede observar que InvoiceLastLineId se encuentra en la tabla declave InvoiceId*, la cual es directamente superordinada respecto a la tabla que contiene el atributo a numerar(InvoiceLineId).

Es decir, cada factura tendrá en el cabezal un atributo que almacenará el último número de línea asignado hastael momento (InvoiceLastLineId). La regla serial está implementada de forma tal que



necesita este atributo (para fijarse el último número utilizado, sumarle el incremento, y asignar el próximo número a lanueva línea).

Cons iderac ión :

La regla serial es útil a la hora de autonumerar líneas, no así cabezales (por ejemplo identificadores de facturas, declientes, etc.). El motivo es el siguiente: para utilizar la regla serial, se requiere definir un atributo en una tabladirectamente superordinada; esto resulta bien sencillo si se desean autonumerar líneas ya que alcanza con incluir esteatributo en el nivel de la estructura inmediatamente superior al del atributo a autonumerar.

Sin embargo, si lo que se quiere numerar automáticamente es un atributo del primer nivel (cabezal), allí no existe unnivel inmediatamente superior en la estructura; esto no es un problema sin solución ya que para definir una relaciónde superordinación/subordinación entre tablas, no solo está la posibilidad de diseñarlo en una misma estructura detransacción con más de un nivel; también transacciones distintas con atributos en común, provocan la creación detablas relacionadas, y por ende, con relaciones de superordinación / subordinación entre ellas.

El siguiente diseño incluye a una tabla de nombre NUMBER superordinada a las tablas INVOICE y CUSTOMER:

Como se puede observar, la tabla NUMBER tiene solamente 2 atributos: NumberCode que sería un código paraalmacenar el tipo de número que se brinda (número de factura, número de cliente, etc.) y NumberLast para almacenarel último número dado para cada NumberCode.

La estructura de la tabla NUMBER sería:

NumberCode* NumberLast

CUSTOMER 20 último identificador de cliente asignado

INVOICE 10 último identificador de factura asignado

Para obtener este diseño, deberíamos definir una transacción “Number” con estructura:

NumberCode*NumberLast

Y relacionarla con las transacciones en las cuales se utilizaría la regla serial:

NUMBER

INVOICE CUSTOMERCustomerId*CustomerNameNum berCode

…

InvoiceId*InvoiceDateNum berCode

CustomerId…

NumberCode*NumberLast

InvoiceId*InvoiceDateCustomerIdCustomerNameNum berCode Num berLast

(InvoiceLineId*ProductIdProductDescription…)

CustomerId*CustomerName…Num berCode

Num berLast

Inferido: está en la tablaNUMBER directamentesubordinada



Finalmente, agregando en la transacción “Invoice” las siguientes reglas, lograríamos autonumerar las facturas:

serial(InvoiceId, NumberLast, 1);equal(NumberCode, ‘INVOICE’ );

La regla equal asigna un valor (‘INVOICE’) a un atributo (NumberCode) cuando se ejecuta la transacción en modo insery filtra los registros que tengan dicho valor en el atributo, cuando se ejecuta la transacción en modo update y delete.

Y en la transacción “Customer” la situación es análoga; con las reglas siguientes podemos autonumerar clientes:

serial( CustomerId, NumberLast, 1 );equal( NumberCode, ‘CUSTOMER’ );

Sin embargo, contamos con una solución mucho más simple para autonumerar cabezales: cuando una tabla tiene unclave simple (es decir formada por un solo atributo) y el tipo de datos es numérico, puede numerarse automáticamenutilizando la funcionalidad que brindan los manejadores de base de datos para esto. La forma de indicarlo en GeneXus econfigurando la propiedad Autonumber del atributo clave:

Si en la propiedad Autonumber de un atributo numérico clave, se selecciona el valor True, significa que se realizará lanumeración automática del mismo. Se agregarán las siguientes propiedades en el diálogo:

Start: Mediante esta propiedad se configura a partir de qué número comienza la numeración automática.

Step: Mediante esta propiedad es posible configurar el incremento del campo (entre dos registros).

For replication: Esta propiedad es sólo válida para el motor de base de datos SQL Server; el valor Yes le indica a ésteque no debe aplicar la propiedad en caso de que la tabla sea receptora de replicación (sino que debe mantener losnúmeros que le vienen por replicación).

Para profundizar en el manejo de esta propiedad, recomendamos acceder al Help de GeneXus.



Update

OBJETIVO: Posibilita actualizar en el form de una transacción (win/web) atributos de la tabla extendida (inferidos).

SINTAXIS: Update( att1[, atti …]);

DONDE:atti: es un atributo perteneciente a la tabla extendida de alguna de las tablas bases asociadas a la transacción.

FUNCIONALIDAD: En una transacción, todos los atributos que pertenecen a las tablas base asociadas a la transacción, pdefecto son aceptados y los que perteneciendo a la tabla extendida, no pertenecen a la base, son inferidos, y por tanto naceptados.Pero si queremos que algunos de estos atributos inferidos sean aceptados, para que el usuario pueda modificar desde form su valor, entonces contamos con la regla Update.

EJEMPLO:

InvoiceId*InvoiceDateCustomerIdCustomerName…

CustomerId*CustomerName…

update(CustomerName);



Conceptos importantes sobre reglas de

transacciones

• ¿En qué nivel de una transacción se ejecutaránlas reglas definidas en la misma?

• ¿Cómo condicionar reglas para que se ejecutenen determinados modos?

¿En qué nivel de una transacción se ejecutarán las reglas definidas en la misma?

La mayor parte de las veces no es necesario agregar explícitamente en la definición de las reglas el nivelde la transacción en el cual se desea que se disparen, ya que los atributos involucrados en las reglas ledan la pauta a GeneXus del nivel en el cual corresponde ejecutarlas.

Por ejemplo, si una regla referencia únicamente a atributos del primer nivel de la transacción en la cual

se encuentra definida (ya sea en la propia regla o en la condición de disparo), GeneXus entenderá que lamisma estará asociada al primer nivel de la transacción.

Análogamente, si una regla referencia solamente a atributos del segundo nivel de la transacción en lacual se encuentra definida (ya sea en la propia regla o en la condición de disparo), GeneXus entenderáque la misma estará asociada al segundo nivel de la transacción.

En el caso que una regla referencie atributos de varios niveles, GeneXus entenderá que la regla estaráasociada al último de los niveles de los atributos involucrados, ya que será en el último nivel en el quecontará con los valores de todos los atributos implicados.

A continuación presentamos ejemplos concretos:

1) Si se define la siguiente regla en la transacción “Invoice”:Default(InvoiceDate, &today);

como el único atributo que se menciona en la regla es InvoiceDate, y es un atributo del primer nivel dela transacción, GeneXus determinará que se tratará de una regla asociada al primer nivel.

2) Si se define la siguiente regla en la transacción “Invoice”:subtract( InvoiceLineQuantity, ProductStock );

como los dos atributos que se mencionan en la misma se encuentran en el segundo nivel de latransacción, GeneXus determinará que se tratará de una regla asociada al segundo nivel.



3) Si se define la siguiente regla en la transacción “Invoice”:

InvoiceLineDiscount= InvoiceLineAmount * CustomerDiscountPercentage/100;

siendo InvoiceLineDiscount (descuento correspondiente a una línea) un atributo perteneciente al segundo nivel dela transacción “Invoice” y CustomerDiscountPercentage (porcentaje de descuento otorgado a un cliente) unatributo declarado en el primer nivel de la transacción “Invoice”, GeneXus determinará que se tratará de una reglaasociada al segundo nivel de la transacción.

Cuando nos referimos a que una regla está asociada a determinado nivel, significa que la misma se ejecutará paracada instancia con la cual se trabaje a través de ese nivel (si se cumple la condición de disparo de la regla, claroestá).

En el caso del primer ejemplo visto, la regla Default(InvoiceDate, &today) es una regla asociada al primer nivelde la transacción “Invoice”. Esto significa que se ejecutará para todo cabezal de factura que se inserte a través delprimer nivel de la transacción “Invoice” (la regla Default tiene la particularidad de dispararse únicamente cuandoel modo de ejecución es Insert).

En el caso del segundo ejemplo visto, la regla subtract(InvoiceLineQuantity, ProductStock) es una regla asociadaal segundo nivel de la transacción “Invoice”. Esto significa que se ejecutará para toda línea de factura que seinserte, actualice o elimine a través del segundo nivel de la transacción “Invoice”.

En el caso del tercer ejemplo, la regla:InvoiceLineDiscount = InvoiceLineAmount * CustomerDiscountPercentage/100 es una regla asociada al segundonivel de la transacción “Invoice”. De modo que esta regla se ejecutará para toda línea de factura que se inserte,actualice o elimine a través del segundo nivel de la transacción “Invoice”.

Concluyendo, tal como se desprende de todo lo explicado, para cada factura con la cual se trabaje a través de latransacción “Invoice” :

- para el cabezal: se ejecutarán las reglas asociadas al primer nivel

- para cada una de las líneas: se ejecutarán las reglas asociadas al segundo nivel

Es importante saber que como norma general GeneXus siempre determina que una regla se dispare en elprimer momento en que sea posible, es decir, en aquel momento en el que cuente con todos los datosnecesarios. Y solamente en algunos casos que así lo requieran, una misma regla se volverá a disparar másadelante.

¿Qué nivel de disparo por defecto se le asociará a una regla que no referencia atributos?

Cuando no hay atributos involucrados en una regla, el nivel asociado por defecto a la regla será el primero.

Por ejemplo, la siguiente regla definida en la transacción “Invoice”:

Error(‘No se permite eliminar facturas’) if Delete;

no tiene atributos involucrados, por lo tanto, el nivel asociado por defecto a la regla será el primero.

¿Cuándo hay que especificar explícitamente el nivel de disparo de una regla?

Existe una cláusula opcional de nombre Level que permite modificar el nivel por defecto de disparo de una regla,cambiándolo por un nivel posterior.

Es decir, si por ejemplo una regla se ejecuta por defecto para el primer nivel de una transacción y se desea que seejecute para el segundo, se deberá agregar a la regla el componente Level seguido de un atributo o conjunto deatributos del segundo nivel. Esto hará que la regla se ejecute para cada una de las instancias correspondientes alas líneas, y no para la instancia correspondiente al cabezal como era el comportamiento por defecto.

Por ejemplo, si definimos la siguiente regla en la transacción “Invoice”:msg(‘La fecha de la factura es mayor a la fecha actual’) if InvoiceDate > &Today;

por defecto esta regla estará asociada al primer nivel de la transacción, ya que el único atributo referenciado en laregla se encuentra en el primer nivel de la transacción. Si por algún motivo deseamos que la regla se ejecute paracada una de las instancias correspondientes a las líneas en vez de ejecutarse para la instancia correspondiente alcabezal, tendremos que agregar en la definición de la regla, la cláusula Level seguida de uno o varios atributosdel segundo nivel:

msg(‘La fecha de la factura es mayor a la fecha actual’) if InvoiceDate>&Today Level InvoiceLineAmount;



Agregar la cláusula Level a una regla solamente tiene sentido si a continuación de la misma se mencionanatributos que son de algún nivel posterior a los niveles de los atributos implicados en la definición de la regla ensí.

En el ejemplo que sigue, el hecho de haber agregado la cláusula Level a la regla no aporta más información de laya aportada por el atributo implicado en la definición de la regla en sí:

msg(‘La fecha de la factura es mayor a la fecha actual’) if InvoiceDate > &Today Level CustomerId;

Es fácil comprender que el atributo InvoiceDate ya le da la pauta a GeneXus de que se trata de una regla asociada

al primer nivel, así que lo especificado por la cláusula Level en el ejemplo no aporta más información y por lotanto su agregado es innecesario.

Por último, en el ejemplo que sigue:

InvoiceLineDiscount= InvoiceLineAmount * CustomerDiscountPercentage/100 Level InvoiceDate;

si bien se incluyó la cláusula Level en la definición de la regla, como el atributo que sigue a la cláusula es de unnivel superior al nivel de los atributos referenciados en la regla, la cláusula Level definida no aportará informaciónútil en este caso tampoco. Es decir, no es posible que habiendo involucrados atributos de un segundo nivel en unaregla, la misma se ejecute en el primer nivel, ya que en el primer nivel no se tiene la información del o de losniveles inferiores (además de que hay N instancias para el o los niveles inferiores). De modo que la regla seguiráestando asociada al segundo nivel de la transacción “Invoice”, no habiendo aportado información útil la cláusulaLevel en este ejemplo.

Concluyendo, la cláusula Level solamente tiene sentido que sea agregada para modificar el nivel por defecto dedisparo de una regla, a un nivel posterior.

¿Cómo condicionar reglas para que se ejecuten en determinados modos?

GeneXus provee las siguientes funciones booleanas para poder incluirlas en la condición de disparo de lasreglas con el objetivo de limitarlas a que se ejecuten puntualmente en algunos de los modos posibles:

• Insert• Update• Delete

Ejem plos d e u so (todas las reglas corresponderán a la transacción “Invoice”)

1) Noaccept( InvoiceDate ) if Update;Si se está modificando una factura (modo Update), no se permite que se modifique su fecha. Si se definiera laregla sin la condición de disparo que hemos explicitado, el atributo InvoiceDate se deshabilitaría en todos losmodos de ejecución.

2) Error( ‘No se permite eliminar facturas’ ) if Delete;

Si se intenta eliminar una factura, se disparará el error deteniendo la eliminación. Como no hay atributosinvolucrados en la regla, por defecto el nivel asociado a la regla será el primero.

3) Error( ‘No se permite eliminar líneas de facturas’ ) if Delete Level InvoiceLineQuantity;

Si se intenta eliminar una línea de una factura, se disparará el error deteniendo la eliminación. Observar que se haexplicitado en la regla la cláusula Level seguida de un atributo del segundo nivel de la transacción “Invoice”, paraindicar que se desea que la misma esté asociada al segundo nivel de la transacción.



Tipos de diálogo

• Diálogo campo a campoLas validaciones, disparo de reglas y fórmulas y grabaciones, sevan efectuando en forma interactiva, en la medida que el usuariova trabajando en la pantalla (Ej: Vb, Vfp con interfaz Win)

• Diálogo a pantalla completa (full screen)Todas las validaciones, disparo de reglas y fórmulas ygrabaciones, se efectúan cuando se confirma la pantalla completa(Ej: Java y .Net con interfaz Win)

• Diálogo con Validación a nivel del cliente (CSV)Híbrido entre los dos anteriores

• Disparo de algunas reglas y fórmulas interactivas

• Grabaciones cuando se confirma la pantalla completa(aquí se redisparan reglas y fórmulas)

(Ej: Java y .Net, Win y Web)

GeneXus genera distintos tipos de diálogos para las transacciones. El diálogo utilizado para un modelo enparticular, dependerá de su ambiente o plataforma (en particular de su interfaz, Win o Web).

Los dos tipos de diálogo clásicos son:

• campo a campo• a pantalla completa (full screen)

Luego se ha creado un hí brido entre ambos, que funciona en algunos aspectos como el diálogo a pantallacompleta y en otros como el campo a campo. Le llamaremos: diálogo con validación a nivel del cliente(Client Side Validation).

Diálogo campo a campo

En este tipo de diálogo, cada vez que se digita un valor en un campo y se abandona, se controlainmediatamente su validez. Las reglas y f órmulas1 se van disparando a medida que se va pasando por loscampos, y los datos de la tabla extendida se van infiriendo ni bien se van ingresando los valores de lasclaves foráneas.

Generalmente la grabación de los datos en este tipo de diálogo es por registro, vale decir:

• Ni bien se terminan de ingresar los datos del cabezal y se pasa a las l í neas, el registro correspondiente alcabezal es grabado.

• Ni bien se terminan de ingresar los datos de una l í nea y se pasa a la siguiente, el registro correspondientea la lí nea de la cual se salió, es grabado.

La grabaciones se van realizando interactivamente, y si se realiza expl í citamente una confirmación de datos,se grabará puntualmente el registro con el cual se esté trabajando (el correspondiente al cabezal o elcorrespondiente a cierta lí nea en la cual el cursor se encuentre).

Los generadores Visual Basic y Visual FoxPro trabajan con este tipo de diálogo.

------------------------------------------------------------------------------------------------------------------1 Estudiaremos las f órmulas un poco más adelante.



Tipos de diálogo

• Validaciones• Controles IR• inferencias• Reglas• Fórmulas• Grabaciones

• Ingreso de datos• Confirmación

• Validaciones• Controles IR• inferencias• Reglas• Fórmulas• Grabaciones

• Ingreso de datos• Validaciones• Controles IR• Inferencias• Algunas reglas• Fórmulas• Confirmación

ClientServer

ClientServer

Diálogo a pantalla completa Diálogo con CSV

Diálogo a pantalla completa (full screen)

En este tipo de diálogo no se realizan validaciones de los datos, controles de integridad referencial (IR),inferencias de la tabla extendida, ni disparos de reglas y f órmulas a medida que los datos van siendoingresados por el usuario en la pantalla.

Las validaciones, reglas y f órmulas se disparan solamente en dos momentos:

1. Al ingresar a la transacción (reglas que no dependen de nada, no tienen condiciones de disparo).

2. Al confirmar los datos.

La confirmación de los datos determina la grabación de la pantalla completa, disparando previamentetodas las reglas, validaciones y haciendo la carga de los atributos de la tabla extendida.

Está en la naturaleza de los generadores Java y .Net trabajar con este tipo de di álogo. Sin embargo existe laposibilidad de modificar este comportamiento, para que el usuario final pueda tener mayor interacción con laaplicación de manera tal que no deba esperar a confirmar la transacción para ver los atributos inferidos, asícomo las validaciones y disparo de reglas y f órmulas. En lo que sigue explicaremos el diálogo a pantallacompleta con Validación a nivel del Cliente.

Diálogo a pantalla completa con Validación a nivel del Cliente (Client Side Validation)

La base de este diálogo es a pantalla completa, pero el usuario tendrá mayor interacción con la aplicación.

Tanto las validaciones de datos, como los controles de IR y disparo de algunas reglas y f órmulas, además de

realizarse cuando se confirma la transacción (como en el diálogo full screen clásico), también se realizaránantes, en forma interactiva a medida que el usuario vaya ingresando y abandonando los campos de la pantalla.

Las grabaciones de los registros s í se realizarán a pantalla completa, tras la confirmación.

De modo que se trata de un hí brido entre los diálogos campo a campo y a pantalla completa.

Nota: en el caso de tratarse de ambiente Web, la pantalla que se ejecuta en el cliente es la ejecutada en elbrowser, y el servidor en este caso es el Servidor Web que ejecuta la aplicación. Si bien la naturaleza deinternet no posibilitaba la validación a nivel del cliente (es decir, enviar partes de la lógica de las transaccionesal browser), con el advenimiento de Ajax1, un conjunto de tecnologí as existentes operando juntas, esto ahoraes posible.

------------------------------------------------------------------------------------------------------------------1 Puede encontrar un artículo interesante “Ajax: A New Approach to Web Applications” en

http://www.adaptivepath.com/publications/essays/archives/000385.php



Diálogo con Validación a nivel del cliente(Client Side Validation)

• En su base es full screen, con algunas validaciones en el cliente

que le permiten incrementar la interacción con el usuario final

• Generadores .Net y Java

• interfaz Win: es configurable (propiedad CSV)

• interfaz Web: no es configurable, siempre se realizará.

• Valores de la propiedad CSV (solo para Win)

• Yes: Activa las validaciones, inferencias y disparo de reglas y fórmulas en lamedida que el usuario va ingresando datos en la pantalla. Estas acciones serepiten cuando se confirma. (valor predeterminado)

• No: Todas las validaciones y disparo de reglas y fórmulas se realizan cuando seconfirma.

• Propiedad a nivel de modelo y de objeto

Mientras que para aplicaciones .Net y Java con interfaz Web siempre se trabajará con diálogo con validacióna nivel del cliente (WCSV: Web Client Side Validation) posible solo gracias a la irrupción del conjunto detecnologías conocido como Ajax en el mundo de Internet, para el caso de las mismas aplicaciones parainterfaz Win existe la posibilidad de configurar una propiedad de nombre ‘Client Side Validation’, para poder,si así se desea, trabajar con el diálogo base, exclusivamente a pantalla completa.

Interfaz Win

Cuando se trabaja con generadores .Net o Java y ambiente Windows, la validación a nivel del clienteofrece una alternativa al diálogo a pantalla completa para proveer mayor interacción con el usuario final.

La propiedad Client Side Validation admite los siguientes valores:

- Yes: Si se selecciona este valor, en la medida que el usuario final vaya pasando por los campos de lapantalla y/o ingresando información en ellos, se irán validando los datos, infiriendo los atributos de la tablaextendida, y disparándose las reglas y fórmulas definidas. Todas estas operaciones se ejecutarán en formainteractiva para que el usuario final pueda ir viendo resultados. De todas formas, las características deldiálogo a pantalla completa se mantendrán, en el sentido de que cuando el usuario final confirme los datos,se grabarán los de la pantalla completa (disparándose previamente todas las validaciones y acciones, estavez en el servidor). Este es el valor por defecto.

-No : Indica que el diálogo a pantalla completa será puro, es decir, sin el agregado de las validaciones enforma interactiva.

La propiedad Client Side Validation se encuentra disponible tanto a nivel de modelo como a nivel deobjeto. Esto significa que el valor que se configure en la propiedad a nivel del modelo determinará elcomportamiento de todas las transacciones, a excepción de aquellas que tengan configurado el valorcontrario en su propiedad a nivel del objeto.

Cuando se crea un modelo de prototipo con interfaz Win y generador Java o .NET, uno de los pasos delWizard de creación de dicho modelo contiene un combo titulado “Client Side Validation” que ofrece los dosvalores posibles: ‘Yes’ o ‘No’. De esta manera el analista ya puede determinar si desea que su aplicacióntenga un diálogo a pantalla completa (propiedad CSV = No) o si por el contrario, desea incrementar lainteractividad de las transacciones, con validación a nivel del cliente (propiedad CSV = Yes). También sepuede configurar esta propiedad a nivel del modelo más tarde (editando las propiedades del modelo), así como a nivel de objeto si se desea que ciertas transacciones tengan el comportamiento contrario alconfigurado para el modelo.



• En la medida que el usuario final va ingresando información en lapantalla, se van validando los datos, realizando las inferencias, ydisparándose las reglas y fórmulas definidas.

• Procesamiento de datos (grabaciones) a “pantalla completa”

• Inferencia de modo:

WIN:CSV=No Hay botón get / no se infiere el modoCSV=Yes No hay botón get / se infiere el modo

Diálogo con Validación a nivel del cliente(Client Side Validation)

WEB :Hay botón get / no se infiere el modo

Resumen sobre diálogo a pantalla compl eta con validación a nivel del cliente:

Mientras el usuario va trabajando con la pantalla, ingresando datos en los distintos campos yabandonándolos, se irán realizando validaciones de los mismos, controles de IR e inferencias de la tablaextendida, así como disparo de reglas y fórmulas que involucren a esos atributos que se abandonan.Esto le brindará al usuario la idea de una alta interacción.

Luego, cuando el usuario termina de trabajar con la instancia de cabezal y líneas, confirma presionandoel botón de confirmación, y allí se realiza el procesamiento de datos a “pantalla completa”. Aquí vuelvena validarse los datos, a dispararse los controles de IR e inferencias, junto con las reglas y fórmulas,además de realizarse las grabaciones de todos los registros correspondientes (cabezal y líneas). Todoesto se realiza en el servidor, como si nada hubiese ocurrido en el cliente (tiene que ver con aspectosde seguridad, dado que si no vuelven a realizarse las validaciones luego en el servidor, podría haberse

“colado” algo en el camino al servidor que burle la seguridad).



• Se cuenta también con la propiedad “Confirmation”, útilfundamentalmente en diálogo a pantalla completa.

• Posibilita trabajar “con” o “sin” confirmación explícita del usuario:• Con confirmación: validación en 2 pasos (grabación en el último).

• Sin confirmación: se valida y graba en 1 solo paso• En Win: no hay botón “Confirm”, solo Insert o Update, dependiendo del modo.• En Web: no hay mensaje de confirmación en el Error Viewer

Diálogo a pantalla completaPropiedad: Confirmation

WIN: cambia texto del botón, “confirm” en el 2do. paso

WEB: no cambia texto, “confirm” se muestraen el 2do. paso en el Error Viewer

La propiedad Confirmation se encuentra disponible tanto a nivel de modelo como a nivel de objeto. Estosignifica que el valor configurado en la propiedad a nivel de modelo determinará el comportamiento de todoslos objetos del modelo, a excepción de aquellos que tengan configurado otro valor en forma particular en supropiedad a nivel de objeto.Esta propiedad permite configurar:• para transacciones: si se desea o no, que antes de que se graben directamente los datos, se le soliciteconfirmación al usuario para hacerlo.

• para reportes y procedimientos: si se desea o no, que antes de que se comience a ejecutar el proceso, se lesolicite al usuario confirmación para hacerlo.Los valores que admite esta propiedad son:• Always prompt: Si se selecciona este valor, se le solicitará confirmación al usuario.• Never prompt: Si se selecciona este valor, no se le solicitará confirmación al usuario.• Do not prompt on first level: Este valor se ofrece únicamente para los generadores Visual Basic y VisualFox Pro, y aplica solamente a transacciones. Si se selecciona el mismo, se le solicitará confirmación al usuarioantes de que se graben los datos en cada nivel de la transacción, a excepción del primero.El trabajo con confirmación reviste relevancia fundamentalmente en el caso en que se trabaje con diálogo apantalla completa (sin validaciones del lado del cliente), pues como dijimos, es en ese tipo de diálogo en elque el usuario no tiene una respuesta interactiva por parte del sistema respecto a los datos que acaba deingresar y requiere de una primera confirmación para obtener alguna respuesta. Por ejemplo, puede haberingresado un valor que no era el que deseaba para una clave foránea que corresponde al país del cliente(suponiendo que no disfraza los valores del atributo y trabaja directamente con los códigos1), y en ese casocomo las inferencias no se realizarán interactivamente, puede querer realizar una confirmación en dos pasos,de modo tal que en el primero se le muestren los datos inferidos y así ya sabrá que el país que digitó era el

deseado. En caso que no lo fuera, podrá modificarlo antes de que la información sea efectivamente grabadaen la base de datos (cosa que se logrará recién en el 2do. paso).Para interfaz Web (que trabaja con CSV) así como para Win con validación a nivel del cliente, no resultanecesario este tipo de comportamiento, ya que las inferencias y validaciones se van disparandointeractivamente a medida que el usuario va trabajando con la interfaz. Si igualmente se utilizaConfirmación, las validaciones, controles de IR e inferencias, las reglas que no dependen de las grabacionesde los registros, y disparo de fórmulas se ejecutarán tres veces (una en el primer paso de la confirmación (enel cliente), segunda vez en el 2do. paso de la confirmación (en el cliente) y una última vez en el servidor,

junto con el resto de las reglas, cuando los registros pasan a grabarse en la base de datos.------------------------------------------------------------------------------------------------------------1 “Descripciones en vez de códigos” dentro del tema Integridad Referencial en este manual.



eliminaciónde líneas

(tecla Supr)

Transacciones en tiempode ejecución

WIN

¿Cómo trabaja el usuario final en ejecución con las transacciones?

En el ejemplo de arriba la transacción “Invoice” se está ejecutando en un ambiente GUI-Windows, y.Net con validación a nivel del cliente. Por tanto, ni bien el usuario ingresa un valor para el atributoque es PK y abandona el campo, se infiere el modo (será Insert en caso en que no exista facturacon ese identificador en la tabla, u Update en caso contrario).

UpdateEn caso de existir registro con ese identificador, se edita en los campos del form, así como serecuperan también las líneas de la tabla INVOICELINE asociadas y se editan en el grid.En este caso el usuario podrá tanto modificar los valores editados (tanto de cabezal como delíneas), para los atributos para los que esto esté permitido (los que no sean read only), insertarnuevas líneas en el grid, así como eliminar alguna línea existente (posicionándose en la línea ypresionando la tecla DEL-Suprimir del teclado).Luego de efectuadas todas las modificaciones (de datos preexistentes, inserción de nuevas líneas omarcado para la eliminación de líneas mediante la tecla DEL), se presiona el botón de “Confirm” 1para aplicar los cambios.En cambio, si lo que se desea es eliminar la factura entera, en ese y solo ese caso se presiona elbotón Delete.

InsertEn caso de no existir registro en la tabla INVOICE con el valor ingresado por el usuario en la PK,entonces los campos del form estarán vacíos esperando ser ingresados por el usuario. El botón de

confirmación dirá “Insert”. El grid no contendrá líneas ingresadas. El usuario ingresará por tanto losdatos para el cabezal y las líneas, pudiendo arrepentirse de una línea que ingresó previamente yborrarla utilizando el mismo procedimiento indicado antes (tecla DEL-Suprimir del teclado sobre lalínea).Obsérvese que en este caso no tendrá sentido presionar el botón “Delete”, dado que los registrosaun no existen en la base de datos, por lo que no hay nada que borrar. Simplemente cerrando latransacción, o pasando a editar otro registro, lo digitado por el usuario en la pantalla se perderá singrabarse.Luego de ingresados sus datos, el usuario confirmará la pantalla mediante el botón “Insert” (teniendo luego que reconfirmar si se trabaja con confirmación; botón “Confirm”).

---------------------------------------------------------------------------------------------------------1 Si se trabaja con confirmación el botón dirá “Update” en primera instancia y luego “Confirm”. Si setrabaja sin confirmación, solo dirá “Update”.



Transacciones en tiempode ejecución

eliminación delíneas

(&GxRemove)

WEB

Para la misma transacción, generada en ambiente Web la historia es muy similar.

Existen algunas pequeñas diferencias, no obstante. Mientras que en ambiente Win contamos con elcontrol Grid que muestra la cantidad de líneas por pantalla que determine el analista cuando diseñael form de la transacción, permite sin embargo el desplazamiento vertical (barra de scroll),permitiendo entonces ingresar tantas líneas como se desee, con tan solo hacer scroll cuando se haningresado todas las líneas de la pantalla.

En Web, sin embargo, al no contar con esta facilidad, siempre se mostrará un número de líneasvacías fijas para ser ingresadas por el usuario (valor configurable por el analista a nivel del grid, ensu propiedad “Rows”). Por defecto se muestran 5 líneas vacías.

Si el usuario ingresó las 5 líneas y necesita ingresar más, le bastará con presionar “Apply Changes” y 5 líneas vacías más se adicionarán al formulario (si se trabaja con confirmación, esto dará laoportunidad de agregar las líneas sin ingresar todo lo anterior en la base de datos).

Otra diferencia respecto al tratamiento de las líneas con respecto a Win es que en el grid del formWeb se incorpora automáticamente una primera columna conformada una variable del sistema denombre &GxRemove, en la forma de check box. Como lo indica su nombre, se utiliza para permitiral usuario en ejecución marcar varias líneas para ser eliminadas.

Lo que en Win se realizaba mediante la tecla DEL, aquí se realiza marcando el check box de la líneaque quiere eliminarse.

Cuando se ingresa en la transacción en modo Insert, el check box no aparecerá en el grid, dado que

no existe ninguna línea aún ingresada, que pueda ser por tanto eliminada.Al aplicar los cambios (Apply Changes) esta primera columna aparecerá para las líneas ingresadasen el form.

Por lo demás, el modo de operación (cómo insertar, modificar, o eliminar registros) es análogo al deWin.



Algunos elementos más

de las transacciones

• Propiedades

• Documentación

• Ayuda

Propiedades

Ayuda

Documentación

Propiedades

Las propiedades asociadas a un objeto –en este caso nos referimos a una transacción, pero valeen general, independientemente de cuál objeto se trate- permiten definir ciertos detallesreferentes al comportamiento general del objeto.

Para ingresar al diálogo de propiedades de un objeto, teniendo el objeto abierto, se deberá

seleccionar el ítem Object / Properties de la barra de menú de GeneXus, o el botón de la barrade herramientas “Fast Access” que señalizamos en la transparencia.

Sin tener el objeto abierto, es posible editar sus propiedades haciendo botón derecho sobre elnombre del objeto, y seleccionando el ítem Properties del menú contextual.

Mediante cualquiera de los caminos anteriores, se abre un diálogo que ofrece las propiedadesasociadas al objeto activo, y donde el analista podrá especificar sus valores, definiendo así detallesreferentes al comportamiento del objeto.

Por ejemplo, la propiedad Confirmation de la que hablamos antes, así como la propiedad ClientSide Validation aparecen en este diálogo en caso de estar trabajando en un modelo .Net o JavaWin, dado que como dijimos oportunamente, pueden configurarse a nivel de objeto.

La propiedad Confirmation también aparecerá en este diálogo si el modelo es .Net o Java Web; no

así la otra. Asimismo dentro de la sección Web Transaction properties del diálogo de configuraciónde propiedades, se encontrará la propiedad Theme para asociarle un objeto tema a la transacción.Cada modelo, dependiendo de su configuración (lenguaje, interfaz, etc.), tendrá algunaspropiedades u otras para configurar.

A lo largo del curso iremos viendo algunas de estas propiedades. Para profundizar en el manejo dealguna propiedad en particular, recomendamos acceder al Help de GeneXus.



Documentación

Los objetos GeneXus ofrecen una sección para que el analista pueda incluir documentación técnica acerca delobjeto.

Para ingresar a la sección de documentación de un objeto, teniendo al objeto abierto, se deberá seleccionar lasolapa Documentation, o el ítem Object / Documentation de la barra de menú de GeneXus.

También el botón de la barra de herramientas “Fast Access” que señalizamos en la transparencia, conducirá a la

sección de documentación del objeto activo.Se abrirá un editor html para que el analista ingrese la documentación técnica correspondiente.

Ayuda

Los objetos GeneXus tienen una sección específica para poder escribir la Ayuda para el usuario final en el uso delobjeto.

Para ingresar a la sección de ayuda de un objeto, teniendo al objeto abierto, se deberá seleccionar la solapa Help,o el ítem Object / Help de la barra de menú de GeneXus.

También el botón de la barra de herramientas “Fast Access” que señalizamos en la transparencia.

Se abrirá un editor Html para que el programador ingrese el texto de ayuda que se le desplegará al usuario cuando

ejecutando el objeto, solicite ayuda.

Algunas consideraciones importantes

Si se ingresa texto de ayuda para objetos y/o atributos y/o variables de la base de conocimiento, luego deespecificar y generar las aplicaciones, se deberá generar el Help. Para ello se deberá seleccionar el ítem Bu ild /Generate Help.

Al seleccionar el ítem Bui ld / Generate Help, se desplegará una pantalla para elegir entre dos formatos: CHM yWEB. También se deberá seleccionar el lenguaje en el que se generará el Help1.

CHM: Es el formato que se deberá elegir para aplicaciones GUI-Windows. Permite empaquetar toda la ayudagenerada en un único archivo de formato CHM, brindando la posibilidad de buscar en la ayuda generada, se definiráun índice, etc.

WEB: Es el formato que se deberá elegir para aplicaciones Web. En tiempo de ejecución se abrirá un browser con eltexto de la ayuda en formato HTML.

En el caso de elegir el formato CHM, se solicitará el path del compilador de Help (este compilador viene con VisualStudio, pero no se instala automáticamente, sino que hay que instalarlo por separado).

Cualquiera sea el formato de ayuda elegido, se generará un directorio HELP bajo el directorio del modelo, en el quese creará un archivo con extensión HTML por cada objeto/atributo/variable que tenga ayuda.

Si el formato elegido es CHM, se creará además un archivo de nombre APPHLP.CHM en el directorio del modelo, yun archivo de definición de proyecto (de extensión HHP) que será utilizado por el compilador de Help, para lageneración del CHM.

El funcionamiento en ejecución será el siguiente:• Cuando el usuario final seleccione el botón de Ayuda de la transacción: se desplegará la ayuda del objeto.• Cuando el usuario final presione F1: se desplegará la ayuda del atributo en el cual se encuentre el cursor; y si eseatributo no tiene definido texto de ayuda, se desplegará la ayuda del objeto.

-------------------------------------------------------------------------------------------------------------------------1 Esto está directamente vinculado a la posibilidad de tener un texto de help por cada uno de los objetos Language,utilizados para poder traducir la aplicación. Es decir, la posibilidad de tener un texto de Help para cada idiomaposible. Así deberá seleccionarse aquí cuál de esos textos de help (el correspondiente a qué lenguaje) deberátomarse para generar el help.



ATRIBUTOS FÓRMULA



Características

• Relación entre atributos, constantes y/o funciones.

• Definición Global: definidas a nivel de la base deconocimiento.

• Atributo Virtual: no se almacena en la tabla.

• Llamaremos tabla base del atributo fórmula a la tabla “asociada” al mismo

• Son calculadas siempre que se hace referencia al atributo

Cuando el valor de un atributo puede calcularse a partir del valor de otros atributos, constantes y/ofunciones, el mismo puede ser definido como fórmula.

Para definir que un atributo es una fórmula y especificar cómo calcularla, existen tres posibilidades,todas ellas disponibles únicamente en el modelo de Diseño:

1) En la estructura de una transacción, así como se define para cada atributo su nombre, tipo dedatos y descripción, es posible definir que el atributo es una fórmula e indicar cuál es el cálculo quedebe hacerse. Esta vía directa en la estructura de una transacción que permite definir que unatributo es una fórmula, se habilita tanto para un atributo ya definido y salvado previamente, comopara un atributo que se está definiendo en el momento.

2) En la estructura de una transacción, es posible pulsar el botón derecho del mouse sobre unatributo que haya sido definido y salvado previamente; se abrirá el menú pop up correspondiente,se deberá seleccionar el ítem Formula del mismo, y a continuación se presentará una pantalla deedición de fórmula para que se indique cómo calcularla.

3) Seleccionando el ítem Advanced / Formula de la barra de menú de GeneXus, se abrirá undiálogo ofreciendo todos los atributos definidos en la base de conocimiento, para que se seleccioneuno, y se edite la forma de calcularlo.

La definición de un atributo como fórmula -indicando cuál es el cálculo que debe hacerse paraobtener su valores una definición global. Dicho de otro modo, se trata de una definición a nivelde la base de conocimiento y no a nivel de un objeto específico, independientemente de por cual delas vías se realice su definición. Siempre que se referencie/utilice un atributo fórmula en cualquierobjeto de la base de conocimiento en el cual sea válido, GeneXus tendrá el conocimiento de quécálculo habrá que hacer para obtener su valor; así, en los programas generados asociados a losobjetos que utilicen fórmulas, incluirá el código necesario para que en tiempo de ejecución sedispare el cálculo y se muestre el valor resultante.



Los atributos definidos como fórmula, a menos que se especifique lo contrario, no estarán almacenados enla base de datos. Dado que sus valores se pueden calcular a partir de los valores de otros atributos,constantes y/o funciones, resulta innecesario y sería redundante almacenarlos (motivo por el cual decimosque son atributos virtuales).

A pesar de que los atributos definidos como fórmula no se crearán como campos físicos en ninguna tabla dela base de datos, cada uno de ellos estará “asociado” a una tabla (siguiendo los mismos criterios denormalización que se utilizan para determinar en qué tabla corresponde almacenar un atributo común).Expresiones del estilo: “la tabla donde está el atributo fórmula x” no son correctas; nos referimos en cambio

a la tabla “asociada” o tabla “base” de un atributo fórmula.



Fórmulas vs. Asignaciones

• Puede especificarse de dos maneras:• mediante una fórmula• mediante una regla de asignación

• Diferencias:

fórmula atributo virtual

regla atributo almacenado

fórmula global

regla local

a t r i b u t o = expres ión

Cuando el valor de un atributo puede obtenerse mediante un cálculo, existen dos opciones para reflejar esteconocimiento:

• Definir al atributo como fórmula con el cálculo correspondiente

ó

• Reflejar el cálculo mediante una regla de asignación, dentro de la transacción.

La sintaxis de definición en ambos casos es similar, sin embargo, existen diferencias importantes entreambas alternativas:

1. Un atributo definido como fórmula no se creará como campo físico en una tabla de la base de datos (a noser que se especifique lo contrario, definiéndolo como redundante, como se verá más adelante). En cambio,si se especifica su cálculo por medio de una regla de asignación dentro de la transacción, el atributo nopresentará ninguna diferencia con respecto al resto de los atributos que no son fórmula y al igual que losotros, se almacenará en la tabla que corresponda.

2. La asignación de un cálculo a un atributo mediante la definición del atributo como fórmula es unadefinición global. Esto significa que el valor del atributo en tiempo de ejecución siempre se mostraráactualizado al ejecutar todo programa que lo utilice, ya que su valor se calculará en el momento. Por elcontrario, la asignación de un cálculo a un atributo mediante la definición de una regla de asignación en unatransacción, es una definición local. Esto significa que solamente si se ejecuta la transacción que tienedefinida esa regla1, el cálculo se efectuará y se almacenará el valor resultante en el campo físicocorrespondiente. De existir otro objeto definido en la base de conocimiento que actualice la tabla quecontiene al atributo cuyo valor se debe calcular, habrá que definir explícitamente en el mismo la asignacióndel cálculo al atributo.

--------------------------------------------------------------------------------------------------------------1 La transacción podrá ejecutarse como tal o como business components, como veremos más adelante. Encualquiera de estos casos, las reglas de la transacción se ejecutarán.



Clasificación

• Fórmulas Horizontales o Expresión

• Permiten definir una o varias expresiones aritméticascondicionales

• Fórmulas Verticales• SUM

• COUNT

Son incondicionales

• Fórmulas Aggregate/Select• Aggregate: Sum, Count

• Select: Max, Min, Find

Son condicionales

• Fórmulas CompuestasVarias expresiones Horizontales y/o Aggregate/Select condicionales

Podemos dividirlas conceptualmente en cuatro categorías:

• Fórmulas Horizontales o Expresión:Una fórmula de este tipo, permite definir una o varias expresiones condicionales.

Los atributos involucrados en la fórmula deberán pertenecer a la tabla extendida de la tabla asociada aatributo fórmula (tabla base de la fórmula).

Son condicionales, en el sentido que pueden incluir condición de disparo.

• Fórmulas Verticales:Las fórmulas verticales son dos: SUM y COUNT.

SUM permite sumar y COUNT permite contar todas las ocurrencias del atributo referenciado, en la tabla en laque se encuentre.

El atributo referenciado en la fórmula deberá pertenecer a una tabla directamente subordinada a la tablaasociada (tabla base) del atributo fórmula, y no podrá ser un atributo primario.

Son incondicionales, significando esto que no permiten que se les incluya condición de disparo ni condicionessobre los registros a ser sumados/contados.

• Fórmulas Aggregate / Select:Una fórmula de este tipo permite buscar, sumar, contar atributos que cumplan determinadas condiciones, encualquier tabla del modelo.

Son condicionales, en el sentido que pueden incluir condición de disparo y también condiciones sobre losregistros a ser buscados/sumados/contados.

• Fórmulas Compuestas:Una fórmula de este tipo está compuesta por varias fórmulas Aggregate/Select condicionales, pudiendo tambiéncontener expresiones horizontales.

Como se puede percibir, dependiendo de la clase de fórmula que se defina, se podrán involucrar en la mismaatributos de tablas que tengan determinada relación en particular con respecto a la tabla asociada al atributofórmula.

En el presente curso no ahondaremos en las últimas dos clases de fórmulas. Para un estudio de las mismasrecomendamos dirigirse al curso no presencial de GeneXus, donde encontrará un tratamiento profundo de estostemas.



Fórmulas Horizontales

Donde:• expi : cualquier expresión válida (atributos, constantes,funciones, operadores).Los atributos involucrados deben ser de la tabla extendida.

• condi : condición de disparo, es cualquier expresión lógica

válida. Los atributos involucrados deben ser de la tablaextendida.

atributo = exp1 [if cond1]

[; exp2 [if cond2]]........................[; expn [ otherwise | if condn]]

expi : puede ser cualquier expresión válida, pudiendo contener atributos pertenecientes a la tablaextendida de la tabla asociada al atributo que se está definiendo como fórmula y/o constantes y/ofunciones y/o operadores aritméticos (+,-,*,/,^) y/o operadores de strings (+) y/o operadores de fechas (+,-). Otra posibilidad es que contenga una invocación con udp (comando que veremos en breve) a unprocedimiento GeneXus o a un programa externo que retorne un valor. El resultado -ya sea de lasexpresiones o el retornado por el programa invocado- deberá ser del mismo tipo de datos que el del atributoque se está definiendo como fórmula.

condi : es cualquier expresión lógica válida, pudiendo contener atributos pertenecientes a la tablaextendida de la tabla asociada al atributo que se está definiendo como fórmula y/o constantes y/ofunciones y/o operadores lógicos (and, or, not) y/o operadores de comparación (>, >=, <, <=, =, like). Laprimera condición que al ser evaluada dé True, provocará que el resultado de la fórmula sea el de laexpresión de la izquierda de esa condición (las demás no se seguirán evaluando).

otherwise: cuando ninguna de las condiciones evaluadas dan True, si existe una expi con cláusulaotherwise, el resultado de la fórmula será el de la expresión expi que anteceda a esta cláusula.



CustomerBa lance = Cust om erTot a lPur chases

- Cust om erTot a lPaym ent s

CusteromerId*CustomerNameCustomerTotalPurchasesCustomerTotalPaymentsCust om erBal ance

Transacción “Customer” TABLA CUSTOMER

CustomerId*CustomerNameCustomerTotalPurchasesCustomerTotalPayments

Fórmulas Horizontales: Ejemplos

En la transacción "Customer" del ejemplo, como se puede observar, además de los atributoscorrespondientes a los datos personales del cliente, existen los atributos CustomerTotalPurchases(total de compras del cliente) y CustomerTotalPayments (total de pagos del cliente), y se necesitasaber en todo momento cuál es el saldo del cliente, por lo qué también aparece el atributoCustomerBalance.

Este saldo del cliente se calcula siempre igual: como la diferencia entre su total de comprasCustomerTotalPurchases y su total de pagos CustomerTotalPayments.

Como el cálculo que debe realizarse es siempre ese, tenemos dos alternativas para definirlo:

1. Definir las siguientes reglas en la transacción “Customer”:

CustomerBalance = CustomerTotalPurchases – CustomerTotalPayments;

Noaccept(CustomerBalance);

/*para que el usuario no pueda modificar el valor calculado de CustomerBalance* /

2. Definir a CustomerBalance como un atributo fórmula horizontal.

Analizando las diferencias entre ambas alternativas decidimos optar por la segunda. Para ello, loúnico que tendremos que hacer estando en el modelo de Diseño, es abrir la transacción "Customer"y agregar en su estructura al atributo CustomerBalance. Se deberá ingresar el nombre, descripcióny tipo de datos del atributo, y en el campo fórmula lo siguiente: Custom erTota lPur chases – Cust om erTot alPaym ent s.

Con esta definición GeneXus tendrá el conocimiento de que el atributo CustomerBalance será unatributo virtual y sabrá de qué forma calcular su valor. Cuando el analista pase a un modelo dePrototipo o Producción y haya un análisis de impacto, la definición del atributo CustomerBalance nocausará la creación del campo físico en la tabla CUSTOMER.

Este es un ejemplo de fórmula horizontal, debido a que se trata de un cálculo aritmético queinvolucra atributos de la tabla extendida de la tabla asociada al atributo definido como fórmula(en particular, en este caso los atributos involucrados pertenecen a la propia tabla base del atributofórmula).



INVOICE CUSTOMER COUNTRY

INVOICELINE PRODUCT

InvoiceId*CustomerId

InvoiceDateInvoiceTotal

CustomerId*

CustomerNameCountryId CountryId*CountryName

I nv oice I d *Product I d *I nvo iceLineQuant i ty I nv oiceLineAm ou nt

Product I d *Product Nam e ProductPr ice ProductStock

I nvo iceL ineAm oun t =ProductPrice*InvoiceLineQuantity if InvoiceLineQuantity<=100;ProductPrice*InvoiceLineQuantity*0.9 otherwise;

Fórmulas Horizontales: Ejemplos

Supongamos que queremos definir al atributo InvoiceLineAmount (importe de línea de factura) como lasiguiente fórmula: InvoiceLineQuantity * ProductPrice (incondicional).

Al hacerlo, si bien el atributo estará “asociado” a la tabla INVOICELINE, no se almacenará en ella (diremos queINVOICELINE será su tabla base).

La definición de esta fórmula se compondrá de una expresión aritmética sin condiciones de disparo, porque suvalor siempre se calcula de la misma forma. En la expresión aritmética intervienen los atributosInvoiceLineQuantity y ProductPrice, ambos pertenecientes a las tablas base y extendida del atributo fórmularespectivamente.

Si, en cambio, se necesita definir que cuando la cantidad de producto llevada por el cliente supere las 100unidades, se haga un 10% de descuento al importe de línea correspondiente, la fórmula se transformará en laque aparece arriba en la transparencia, en la que hay dos expresiones condicionales.

Si bien elegimos condicionar la segunda expresión con la cláusula otherwise, hubiese sido equivalente definir:

ProductPrice * InvoiceLineQuantity if InvoiceLineQuantity <=100;

ProductPrice * InvoiceLineQuantity * 0,9 if InvoiceLineQuantity > 100;

ya que las dos condiciones de disparo son disjuntas y no dejan fuera ninguna posibilidad.



Características:

• Suman o cuentan todas las ocurrencias del atributo att enuna tabla.

• La tabla asociada a att debe ser directamentesubordinada de la tabla base del atributo fórmula.

• att no puede formar parte de ninguna clave del modelo(no puede ser atributo primario).

• Son incondicionales.

Fórmulas Verticales

atributo = SUM(att) | COUNT(att)

Las fórmulas verticales son dos: SUM y COUNT.

SUM permite sumar los valores contenidos en el atributo att para todos los registros de la tabla asociada aél, que necesariamente deberá ser directamente subordinada a la del atributo que estamos definiendocomo fórmula.

COUNT permite contar todas las ocurrencias del atributo referenciado en la fórmula, que también debepertenecer a una tabla

directamente subordinadaa la tabla base del atributo que se está definiendo

como fórmula.

Las fórmulas verticales son incondicionales, es decir, no permiten que se les incluya condiciones sobre losregistros de la tabla subordinada a ser sumados/contados.

Sin tax is : SUM(att) | COUNT(att)

donde:

att: Puede ser un atributo almacenado en una tabla directamente subordinada a la tabla base delatributo que se está definiendo como fórmula, o un atributo fórmula horizontal o vertical asociado tambiéna una tabla directamente subordinada a la tabla base del atributo fórmula. En cambio, no podrá ser unatributo fórmula Aggregate/Select, ni involucrar directa o indirectamente a un atributo fórmulaAggregate/Select.

No puede formar parte de ninguna clave del modelo.

Para el caso de fórmula SUM, debe ser de tipo numérico.

El tipo de datos del atributo fórmula debe ser numérico.



Características (continuación):

• Se consideran los registros “relacionados”:

Relación de subordinación directa:

los registros están relacionados

• Para cada registro de la tabla base para el que se estáevaluando la fórmula, se suman/cuentan los registros dela tabla navegada relacionados.

TablaBase

TablaNavegada


Registros sumados/ contados:

Si bien no pueden establecerse condiciones sobre los registros de la tabla subordinada para que éstossean utilizados en la suma/cuenta (incondicionalidad de las fórmulas verticales), en la resolución dela fórmula GeneXus no considera todos los registros de la tabla subordinada.

Por el contrario, solo se suman/cuentan aquellos que estén “relacionados” con el registro de la tablabase para el cuál la fórmula se está evaluando.

Quedará más claro este punto con los ejemplos que veremos a continuación.



I nvoiceI d *Cust om er I d

Cust om erNam e

I nvo iceDate

I nvo iceTota l = SUM(InvoiceLineAmount)

(Product I d *

Produc tDescr i p t i on

ProductPr ice

I nvo iceL ineQuant i ty

I nvo iceL ineAm ount = ProductPrice*InvoiceLineQuantity

)

InvoiceId*CustomerIdInvoiceDate

InvoiceId*ProductId*InvoiceLineQuantity

Transacción "Invoice"

• InvoiceTotal e InvoiceLineAmount son fórmulas no están almacenados

• En el cálculo de InvoiceTotal solo intervienen los registros que cumplan:

INVOICELINE.I nv oice I d = INVOICE.I nv oiceI d

Fórmulas Verticales: Ejemplos

INVOICE

INVOICELINE

1

N

Queremos definir en la transacción "Invoice" que el importe total (InvoiceTotal) se calcule automáticamentecomo la suma de los importes de las líneas (InvoiceLineAmount).

El atributo InvoiceTotal se encuentra en el primer nivel de la transacción "Invoice" (siendo su tabla asociada:INVOICE) y el atributo InvoiceLineAmount se encuentra en el segundo nivel de la transacción "Invoice"(siendo su tabla asociada: INVOICELINE).

Es posible definir al atributo I nvo iceTota l como la fórmula vertical: SUM(I nvo iceL ineAm ount ) ya que elatributo que necesitamos referenciar en la fórmula para ser sumado (InvoiceLineAmount) pertenece a unatabla directamente subordinada (INVOICELINE) a la tabla base (INVOICE) del atributo que queremos definircomo fórmula (InvoiceTotal).

Las fórmulas verticales no permiten que se les incluya condiciones de filtro. Por ejemplo, no podremos definircon una fórmula vertical “contar las líneas de la factura que cumplan que la cantidad de producto llevadasupere las 100 unidades”. Solamente podremos “contar las líneas de la factura” (todas).

Sin embargo, como resulta evidente en el ejemplo que venimos viendo, los registros de INVOICELINE queintervendrán en el cálculo serán sólo los relacionados con el registro de INVOICE para el que se estécalculando InvoiceTotal. Es decir, se contemplarán todos aquellos registros de INVOICELINE que cumplan,para el registro actual de INVOICE:

INVOICELINE.InvoiceId = INVOICE.InvoiceId.

De modo que si bien las fórmulas verticales no permiten que se les incluya condiciones sobre los registros dela tabla directamente subordinada a ser sumados/contados, en la resolución de la fórmula GeneXus noconsidera todos los registros de la tabla subordinada, sino solamente aquellos que estén relacionados con elregistro de la tabla base para el cuál se esté evaluando la fórmula.

En este ejemplo, el atributo sumado (InvoiceLineAmount) es un atributo fórmula horizontal asociado a latabla INVOICELINE que es directamente subordinada a la tabla INVOICE.



I nvoiceI d *Cust om er I d

Cust om erNam e

I nvo iceDate

I nvoiceLines = COUNT(InvoiceLineQuantity)

(Product I d *

Produc tDescr i p t i on

ProductPr ice

I nvo iceL ineQuant i ty

I nvo iceL ineAm ount = ProductPrice*InvoiceLineQuantity

)

InvoiceId*CustomerIdInvoiceDate



• InvoiceLines e InvoiceLineAmount son fórmulas no están almacenados

• En el cálculo de InvoiceLines solo intervienen los registros que cumplan:

INVOICELINE.I nv oice I d = INVOICE.I nv oiceI d


INVOICE

INVOICELINE

1

N

Si necesitamos contar la cantidad de líneas que tiene una factura, podemos agregar un atributo en el primernivel de la estructura de la transacción "Invoice" (de nombre InvoiceLines), y definirlo como la fórmula:

COUNT(InvoiceLineQuantity)

o:

COUNT(InvoiceLineAmount)

Es exactamente lo mismo optar por referenciar a cualquiera de los atributos anteriores en la fórmula COUNT,ya que el primero es un atributo almacenado en la tabla INVOICELINE y el segundo es un atributo fórmulaasociado a la tabla INVOICELINE, la cual es directamente subordinada a la tabla INVOICE (asociada alatributo InvoiceLines que se está definiendo como fórmula). En cambio a los atributos InvoiceLineId yProductId no es posible referenciarlos en la definición de la fórmula COUNT porque si bien se encuentran enla tabla INVOICELINE, forman parte de alguna clave.



CUSTOMER

INVOICEInvoiceId*CustomerIdInvoiceDate

INVOICELINE


InvoiceTotal =

SUM( InvoiceLineAmount )

InvoiceLineAmount =

ProductPrice*InvoiceLineAmount


Cust om erI d *

Cust om erNam e

Custo m erTota lPurchases = SUM(InvoiceTotal)

Custom erTot a lPaym ent s

Cust om erBalan ce

Transacción “Customer"

1

N

CustomerId*CustomerNameCustomerTotalPayments

1

N

CUSTOMER e INVOICE:

Relación 1-N hay subordinacióndirecta vale la fórmula

En este otro ejemplo, el atributo CustomerTotalPurchases de la transacción "Customer" representa el total decompras efectuadas por el cliente. Este total de compras se puede calcular como la suma de los totales de lasfacturas realizadas para ese cliente.

Por tanto podemos definirlo como la fórmula:

CustomerTotalPurchases = SUM( InvoiceTotal )

GeneXus la interpretará como una fórmula vertical, ya que la tabla base es CUSTOMER e InvoiceTotal estáasociado a INVOICE, tabla directamente subordinada a CUSTOMER.

Observar que en este caso, InvoiceTotal también es una fórmula vertical.

Como restricción, no se pueden utilizar más de dos fórmulas SUM anidadas. Es decir, es posible definir unafórmula SUM que involucre otra fórmula SUM, pero ésta última no puede involucrar otra fórmula SUM.

Lo mismo ocurre con la anidación de fórmulas COUNT.




Características (continuación):

• Navegación vertical: Performance y Redundancia

• Equivalencia entre SUM redundante y regla add

CustomerTotalPurchases = SUM(InvoiceTotal) Y redundante

CustomerTotalPurchases atributo secundario (no fórmula) ycalculado mediante la siguiente regla (en "Invoice"):

add(I nv oiceTot al , Cust om erTot alPur chases )

∼

Navegación vertical: Performance y Redundancia

El hecho de que una fórmula no esté almacenada puede ocasionar en algunos casos problemas deperformance debido al tiempo que puede demorar el cálculo. Esto dependerá de la cantidad de registrosque se sumen o cuenten.

Supongamos, por ejemplo, que tenemos miles de facturas, cada una de las cuales puede tener miles delíneas. Si frecuentemente se requiere sacar listados de las facturas mostrando sus totales, y los totales secalculan mediante la definición de un atributo fórmula SUM, por cada una de las miles de facturas, sedeberán navegar miles de registros correspondientes a sus líneas para realizar el cálculo del total. Estorepresenta un costo elevado de performance.

Para evitar este inconveniente, GeneXus provee la posibilidad de definir a un atributo fórmula comoredundante. Al hacerlo, el atributo deja de ser virtual y pasa a estar almacenado en la tabla asociada.

En tiempo de ejecución, al utilizar una transacción que contiene un atributo fórmula redundante, elcomportamiento es el siguiente: la fórmula se dispara efectuándose el cálculo y el resultado se almacenaen el campo físico de la base de datos.

En los programas generados correspondientes a transacciones que tienen involucrados atributos fórmulasredundantes, GeneXus incorpora rutinas que se encargan de almacenar los datos redundantes, siempreque se recalculen.

Al consultar un atributo fórmula redundante, no se dispara la fórmula para obtener el cálculo sino que setoma el valor almacenado del campo de la base de datos.

Un atributo fórmula redundante:

• A diferencia de un atributo fórmula simple: estará almacenado en la base de datos.

• A diferencia de un atributo común: GeneXus tendrá el conocimiento de cómo calcular su valor y en losprogramas generados correspondientes a transacciones, incluirá rutinas para mantener actualizado elvalor almacenado.



Equivalencia entre definir un atributo fórmula SUM redundante y utilizar regla add

Definir un atributo como fórmula SUM redundante es equivalente a que el atributo sea común (no fórmula) ydefinir una regla add en las transacciones en las cuales se encuentre, para efectuar el mismo cálculo. Ambascosas son equivalentes, con la salvedad de que la definición de la fórmula es global (está asociada alatributo), mientras que la definición de la regla es local (es decir, la regla add se va a ejecutar solamentecuando se hagan ABM1 a través de la transacción en la cual está definida la regla).

Por ejemplo, definir al atributo InvoiceTotal como la fórmula: SUM(InvoiceLineAmount) redundante, esequivalente a que el atributo InvoiceTotal no sea definido como fórmula, e incluir la regla:add(InvoiceLineAmount, InvoiceTotal) en la transacción "Invoice".

Si optamos por lo último:

− Cada vez que se inserte una línea, la regla add sumará el valor de InvoiceLineAmount al valor deInvoiceTotal.

− Cada vez que se elimine una línea, la regla add restará el valor de InvoiceLineAmount al valor deInvoiceTotal.

− Cada vez que cambie el valor de InvoiceLineAmount de una línea (porque se haya modificado el valor dealguno de los atributos que participan en la definición de su fórmula), la regla add sumará a InvoiceTotal, ladiferencia entre el valor nuevo y el viejo de InvoiceLineAmount.

Como sabemos, de definir al atributo InvoiceTotal como la fórmula: SUM(InvoiceLineAmount), elcomportamiento sería el mismo.

Una de las diferencias a tener en cuenta a la hora de decidir si calcular el valor de un atributo mediante ladefinición de una fórmula o regla, es que con la primera alternativa, el atributo no se almacenará y con lasegunda, si. Sin embargo, como nos estamos refiriendo a definir al atributo InvoiceTotal como la fórmula:SUM(InvoiceLineAmount) redundante, el atributo InvoiceTotal se almacenará en su tabla asociada (INVOICE),de igual forma que si se define al atributo InvoiceTotal común (no fórmula) y se incluye la regla:add(InvoiceLineAmount, InvoiceTotal) en la transacción "Invoice" para efectuar el cálculo.

Concluyendo, estas dos alternativas son equivalentes, ya que en tiempo de ejecución en la medida que sevayan insertando, modificando o eliminando líneas por medio de la transacción "Invoice", el valor del atributoInvoiceTotal se irá calculando y su valor quedará almacenado en un atributo físico de la tabla INVOICE.

-------------------------------------------------------------------------------------------------------------------1 ABM= Altas, Bajas y Modificaciones.



COMUNICACIÓNENTRE OBJETOS



Comunicación entre objetos

Procedimiento

Reporte PDF

TransacciónWeb Panel

Los objetos GeneXus pueden comunicarse entre ellos o con otros programas externos.

Un objeto GeneXus puede llamar o ser llamado por otro objeto, intercambiando información através de parámetros1.

Veremos a continuación cómo invocar desde un objeto a otro, y cómo especificar los parámetros(en el objeto llamador y en el llamado) para el intercambio de la información.

El esquema presentado arriba ilustra las posibles interacciones entre objetos GeneXus para unaaplicación Web. Obsérvese que la flecha simple entre Web Panel y Reporte PDF (así como entreTransacción y Reporte PDF) indica que un Web Panel podrá invocar a un Reporte2 pero un Reporteno podrá invocar a un Web Panel (o transacción Web).

El esquema de interacción entre los objetos GeneXus Win es más flexible pues todos los objetospueden interactuar con todos. En ese caso habrá que sustituir al objeto Web Panel por el objetoWork Panel, y los reportes tendrán también más flexibilidad, pues podrán invocarse en cualquiercircunstancia, y podrán emitirse en formatos varios (y no solo PDF).

----------------------------------------------------------------------------------------------------------1 Para aplicaciones Web también se utilizan cookies para el intercambio de información.2 En Web solamente podrá invocarse a reportes PDF, como mencionaremos en el capítulo queestudia el objeto Reporte.



2 posibilidades:

1)

2)

Comunicación entre objetosWin - Web

PgmName.Call(par1, … , parN)

att|&var = PgmName.Udp(par1, … , parN)

Parm(par1, … , parN); /*Declaración de parámetrosen el objeto invocado*/

Parm(par1, … , parN , parsalida);

/*Invocación a PgmName*/

/*Declaración de parámetrosen el objeto invocado*/

/*Invocación a PgmName*/

CALL - Permite invocar a un objeto GeneXus o a un programa externo, tanto sin pasarleparámetros, como pasándole.

UDP (User Defined Procedure) - Permite invocar a un objeto GeneXus o programa externotanto sin pasarle parámetros como pasándole, y con la particularidad de que el programallamado retornará necesariamente al menos un valor al programa que lo invocó. En Win lautilización de UDP es más amplia que en Web, pues en Win todo objeto al finalizar su ejecución

devuelve el control al objeto llamador; sin embargo en Web esto no sucede en todos los objetos,por lo que UDP se utiliza únicamente para invocar a procedimientos (debido a que estos cumplen lacondición de ejecutar y devolver el control al llamador).

Una invocación (ya sea con CALL o UDP) podrá escribirse en distintas partes del objeto llamador,dependiendo de si el mismo es una transacción, web panel, procedimiento, etc.:

A su vez UDP puede utilizarse también en la definición de un atributo fórmula. Es decir, se defineque cierto atributo es una fórmula y que la definición de la misma consiste en la invocación a unprocedimiento utilizando UDP.

PARM – Cuando un objeto es invocado desde otro con parámetros, debe tener declarada la lista deparámetros que recibe. Esta declaración se realiza mediante la regla: PARM.

A continuación daremos más detalles acerca del uso de CALL, UDP y PARM.



2 posibilidades – Ejemplos:

1)

2)

Comunicación entre objetosWin - Web

Ej: RListInvoice.Call(InvoiceId)

En el reporte ListInvoice

Ej: &discount = PCalcDiscount.udp(ProductId,CustomerId)

En el proc CalcDiscount

Parm(InvoiceId)

Parm(ProductId,

CustomerId , &discount);

NOTAR PREFIJO

Aquí mostramos un ejemplo de uso de CALL para realizar una invocación y otro ejemplo de uso deUDP.

Dependiendo de qué objeto llamador se trate, estas invocaciones podrán escribirse en una sección uotra del mismo, pero independientemente de eso, aquí apuntamos a mostrar que CALL permiteinvocar a un objeto con estilo de invocación a un programa, mientras que UDP invoca a un objetocon estilo de invocación a una función.

En el primer ejemplo se está utilizando CALL para invocar a un reporte (objeto ListInvoice)pasándole 1 parámetro (InvoiceId). En el reporte invocado se ha declarado el parámetro que recibe(en su sección de reglas, mediante la regla parm).

En el segundo ejemplo se está utilizando UDP para invocar a un procedimiento (objetoCalcDiscount) pasándole 2 parámetros (ProductId, CustomerId). Ahora, observemos en la sintaxisde la invocación al procedimiento, que el mismo retorna un valor (en la variable &discount). Poreste motivo, en el procedimiento invocado se han declarado 3 parámetros utilizando la regla parm:los 2 parámetros recibidos + el parámetro de retorno en último lugar.

Podemos ver entonces que cuando se utiliza CALL para invocar a un objeto enviándole Nparámetros, se deben declarar los N parámetros (posicionales y del mismo tipo de datos que losenviados) en el objeto invocado mediante la regla parm.

En cambio cuando se utiliza UDP para invocar a un objeto enviándole N parámetros:

• en la regla parm del objeto invocado se deben declarar N + 1.

• El último parámetro declarado en la regla parm del objeto invocado, corresponde al que seencuentra al principio de todo en la invocación, es decir, al que recibe el valor retornado.

• En algún lugar del objeto invocado se le deberá asignar valor al parámetro de retorno.



Convención de nombrado de los objetos

GeneXus invocados

En la invocación a un objeto GeneXus, el nombre del objeto quese invoca debe estar formado por: : Prefijo + nombre delobjeto

Tanto si se utiliza, CALL como UDP para invocar a un objeto GeneXus, el nombre del objeto que seinvoca debe estar formado por: un prefijo (que identifica al tipo de objeto) + el nombre del objeto.

La tabla de la transparencia muestra algunos prefijos según el tipo de objeto.

Por ejemplo, si se desea invocar desde algún objeto GeneXus a la transacción “Invoice” el nombre

que se deberá escribir en la invocación es TInvoice. A su vez, si se desea invocar desde algún objetoGeneXus a un reporte de nombre “CustomersReport”, el nombre que se deberá escribir en lainvocación es RCustomersReport.

Recomendamos utilizar el ítem: Insert/Object de la barra de menú de GeneXus para seleccionar losobjetos que se deseen invocar, ya que automáticamente se insertarán con el prefijo que corresponday el analista no tendrá que recordarlo de memoria.

Nota: Si el objeto invocado es un programa externo, el nombre del mismo deberá incluirse entrecomillas en la invocación.



¿Qué declarar en la regla parm:variable o atributo?

• Variable: Se podrá utilizar libremente, en la lógica del objetoinvocado:

• como condición de filtro por =, >, >=, <, <=, LIKE, etc.

• para alguna operación aritmética

• como bandera

• etc.

• Atributo: Automáticamente el mismo actuará como filtro por igualdaden el objeto, no siendo posible modificar el valor recibido.

Al definir una invocación a un objeto (ya sea utilizando CALL o UDP), si se tienen que enviar datospor parámetro al objeto invocado, resulta evidente determinar si enviar atributos y/o variables: siun dato a ser enviado por parámetro, se encuentra en el objeto invocador, en un atributo, habráque enviar al mismo; y si se encuentra en una variable, habrá que enviar a la variable.

Sin embargo, al declarar la lista de parámetros en el objeto invocado, el programador GeneXusdeberá decidir para cada parámetro, si declararlo mediante un atributo o una variable,

independientemente de cómo haya sido enviado.

¿Cuál es la diferencia entre declarar un parámetro como variable o como atributo en la regla parmdel objeto invocado? Si se declara una variable, se la podrá utilizar libremente en la lógica delobjeto invocado: se la podrá utilizar como condición de filtro por igualdad, por mayor, mayor oigual, menor, menor o igual, LIKE, etc.; se la podrá utilizar para alguna operación aritmética, comobandera, o lo que se necesite. Si en cambio se declara un atributo, automáticamente el mismoactuará como filtro por igualdad en el objeto, no siendo posible modificar el valor recibido.

Cuando lleguemos a la etapa del curso en la cual podamos invocar a reportes pasándolesparámetros así como a otros objetos, podremos terminar de comprender esto ya que la prácticanos permitirá ver este tema.



Definición de parámetros de entrada (in),salida (out),entrada-salida (inout) en Parm

• Para cada parámetro que se declara en la regla parm, es posible definir sise desea que el mismo opere:

− de entrada (in)

− de salida (out)

− de entrada-salida (inout)

• Ejemplo: parm(out:& par1, in:& par2, & par3, inout:& par4);

• Ventajas:

• Mejor especificación de la semántica de las interfaces.

• Independencia del lenguaje de generación.

• Optimizar el pasaje de parámetros de las aplicaciones de acuerdo a la

arquitectura en la que éstas se implementan (ventaja contrapuesta a laanterior).

Para cada parámetro que se declara en la regla parm, es posible definir si se desea que el mismo opere: deentrada (in), de salida (out), o de entrada-salida (inout).

Ejemplo: parm(out:& par1, in:& par2, & par3, inout:& par4);

Como se puede percibir claramente en la sintaxis del ejemplo, el primer parámetro definido es de salida, elsegundo parámetro es de entrada, y el cuarto parámetro es de entrada-salida. Cuando no se especificanada, como es el caso del tercer parámetro de la sintaxis, dependerá de lo siguiente:

• si el objeto fue invocado con CALL, el parámetro, será de entrada-salida.

• si el objeto fue invocado con UDP, y se trata del último parámetro, será de salida; y si se trata de otroparámetro distinto del último, dependerá del lenguaje de generación.

Declarar explícitamente cómo se desea que cada parámetro opere, tiene las siguientes ventajas:

1. Mejor especificación de la semántica de las interfaces; es decir, tanto para GeneXus como para elprogramador cuando trabaje con un objeto, será claro tener definido en la regla parm el objetivo de cadaparámetro, es decir:

- si el mismo vendrá con valor y luego de la ejecución del objeto invocado, sedevolverá al objeto invocador el valor con que haya quedado (inout).- si el mismo vendrá con valor y luego de la ejecución del objeto invocado, no sedevolverá al objeto invocador el valor con que haya quedado (in).- si el mismo no vendrá con valor y luego de la ejecución del objeto invocado, sedevolverá al objeto invocador el valor que tenga (out).

2. Independencia del lenguaje de generación; es decir, si se define explícitamente cómo se desea que cadaparámetro opere, al generar las aplicaciones utilizando diferentes lenguajes de generación no estarácambiando el comportamiento de los parámetros en base al comportamiento por defecto del lenguaje degeneración correspondiente.

3. Optimizar el pasaje de parámetros de acuerdo a la arquitectura en la que éstas se generen (siendo unaventaja contrapuesta a la anterior); esto se refiere a lo siguiente: para la mayoría de los lenguajes es máseficiente pasar los parámetros por referencia (inout) que por valor (in / out); pero en Java, por ejemplo, losparámetros solo se pueden pasar por valor, por lo que para lograr la funcionalidad de pasarlos por referenciaes necesario hacer conversiones de parámetros, lo cual puede redundar en un overhead importante; por otrolado, cuando se trata de aplicaciones distribuidas (por ejemplo Java con RMI o HTTP), la utilización deparámetros de tipo out tiene la ventaja de que no es necesario enviar al parámetro en la invocación, adiferencia de si los parámetros se definen de inout (que implica que haya que pasar todos los parámetros);esto tiene como consecuencia que se envíen más bytes de los necesarios, lo cual es inconvenienteespecialmente en entornos tales como Internet.



Más posibilidades para definir invocaciones Función Link

1)

2)

Comunicación entre objetosWeb

control.Link = PgmName.Link([,par1 … , parN])

Ej: imagen.Link = Link( ‘http://www.artech.com.uy’ )

Ej: imagen.Link = TCustomer.Link()

control.Link = Link(URL)

Los parámetros sonopcionales, y encaso de haber, sedeclaran con reglaparm

La función Link se asocia a la propiedad link de un control dentro de cualquier evento de unatransacción o web panel1, teniendo como resultado que al hacer clic sobre dicho control se realizará lallamada al objeto o URL referenciada en el link.

PgmName (el objeto invocado) podrá ser un web panel, transacción, o reporte PDF 2.

--------------------------------------------------------------------------------------------------------1 a excepción del evento Load de los web panels (que veremos más adelante)

2 también un procedimiento HTTP, pero no profundizaremos sobre este concepto en este curso



Más posibilidades para definir invocaciones Comando Link

1)

2)

Comunicación entre objetosWeb

Ej: TCustomer.Link(CustomerId)

PgmName.Link([,par1 … , parN])

Ej: Link(‘http://www.google.com’)

Link(URL)

El comando Link puede ser utilizado dentro de cualquier evento de una transacción o web panel1.

Cuando se ejecute el evento, al llegar a la sentencia con el comando Link, se redireccionará enforma automática a la URL especificada.

En caso de utilizarse el comando Link como en el ejemplo 1, invocando a un PgmName (siendoPgmName un web panel, transacción o reporte PDF), será equivalente a la utilización de Call.

Opcionalmente se podrán pasar parámetros al objeto invocado, debiendo declararse los mismos enel objeto llamado, con la regla parm.

--------------------------------------------------------------------------------------------------------1 a excepción del evento Load de los web panels (que veremos más adelante)

2 también un procedimiento HTTP, pero no profundizaremos sobre este concepto en este curso



ORDEN DE EJECUCIÓN DE REGLAS Y FÓRMULAS



“Category” Categor yI d *CategoryD iscoun t

“Customer”

Custom erI d *Custom erNa m e CategoryI d Custom erTota lPur chases

“Shipping” Sh ipp ingDa te *ShippingCharge

Add( InvoiceTotal, CustomerTotalPurchases);Error( ‘Insufficient Stock’ ) if ProductStock<0;Subtract( InvoiceLineQuantity, ProductStock);

I nvoiceI d *

I nvo iceDate Custom erI d CustomerTotalPurchasesCategoryDiscountI nvo iceDiscount = InvoiceSubTotal *CategoryDiscountI nvo iceShipp ingCharge = Max( ShippingDate, ShippingDate

<=InvoiceDate,,ShippingCharge)I nvo iceSubTota l = SUM( InvoiceLineAmount )I nvo iceTota l = InvoiceSubTotal – InvoiceDiscount

+ InvoiceShippingCharge(Product I d *ProductPriceProductStockI nvo iceL ineQuant i t y I nv oiceLineAm ount ) = InvoiceLineQuantity *

ProductPrice

“Product” Product I d *Produc tPr ice ProducStock


Reglas:

Orden de ejecución dereglas y fórmulas

La forma de programar el comportamiento de las transacciones es definiendo reglas, las cuales seescriben de forma declarativa. A su vez si hay cálculos para efectuar, se puede optar por laalternativa de definir atributos fórmula.

El programador GeneXus en ningún momento especifica la secuencia de ejecución de las reglas yfórmulas definidas en una transacción, sin embargo al momento de generar, GeneXus determina lasdependencias existentes entre las reglas y fórmulas definidas.

Supongamos que estamos definiendo una aplicación para una empresa que vende determinadosproductos, y que cuenta con un servicio de entrega a domicilio que lleva la mercadería a susclientes. Y definimos entre otras, las siguientes 5 transacciones:

"Customer" (para registrar los clientes de la empresa)

“Category” (a las que pertenece cada cliente)

“Shipping” (envíos: guarda un histórico de costos de envío)

"Invoice" (facturas que se emiten a los clientes)

"Product" (productos vendidos por la empresa)

Se resalta la estructura de la transacción "Invoice", con sus atributos fórmulas (algunashorizontales, otras verticales, otras aggregate/select) y sus reglas declaradas.

¿En qué orden se dispararán las reglas y fórmulas de la transacción "Invoice"?



R. Add(InvoiceTotal, CustomerTotalPurchases);F. InvoiceTotal = InvoiceSubTotal - InvoiceDiscount +

InvoiceShippingCharge

F. InvoiceDiscount = InvoiceSubTotal*CategoryDiscountF. InvoiceShippingCharge = MAX( ShippingDate, ShippingDate <=

InvoiceDate,,ShippingCharge)F. InvoiceSubTotal = SUM( InvoiceLineAmount )F. InvoiceLineAmount = InvoiceLineQuantity *ProductPriceR. Subtract(InvoiceLineQuantity, ProductStock) ;R. Error( ‘Insuffcient Stock’) if ProductStock < 0 ;

Árbol de evaluación

error (‘Insufficient Stock ’)

ProductStock

InvoiceLineQuantity

InvoiceLineAmount

InvoiceTotal

InvoiceSubTotal

InvoiceDiscount

ProductPrice

CategoryDiscount

CustomerTotalPurchases

InvoiceShippingCharge

InvoiceDate ShippingDate

ShippingCharge

Al momento de generar el programa asociado a la transacción "Invoice", GeneXus extraerá lasdependencias existentes entre las reglas y fórmulas definidas; construirá lógicamente un árbol dedependencias (o árbol de evaluación) que determinará la secuencia de evaluación.

Podemos imaginar que el árbol se ejecuta de abajo hacia arriba, es decir que cada vez quecambia el valor de un atributo, se ejecutan todas las reglas y fórmulas que dependen de eseatributo (y que en el árbol se encuentran hacia arriba).

Por ejemplo, si cambia la cantidad de una línea de una factura (InvoiceLineQuantity), como esteatributo interviene en la fórmula que calcula el importe de la línea (InvoiceLineAmount), dichafórmula se redisparará. Por cambiar el importe de una línea, deberá redispararse la fórmulacorrespondiente al subtotal de la factura (InvoiceSubTotal) y en consecuencia, también deberárecalcularse la fórmula correspondiente al descuento (InvoiceDiscount), ya que depende delsubtotal. Deberá redispararse también la fórmula correspondiente al total de la factura(InvoiceTotal) ya que depende tanto del valor de InvoiceSubTotal como del valor deInvoiceDiscount. Por último, por cambiar el total también se tendrá que disparar la reglaAdd(InvoiceTotal, CustomerTotalPurchases);.

Además de dispararse todas las fórmulas y reglas involucradas en la rama derecha del árbol desdeel atributo InvoiceLineQuantity, también se dispararán las fórmulas y reglas involucradas en la ramaizquierda. Es decir, que al cambiar el valor del atributo InvoiceLineQuantity, se redisparará tambiénla regla Subtract(InvoiceLineQuantity, ProductStock); y en consecuencia, por modificar esta reglael valor del atributo ProductStock, se evaluará si habrá que disparar la regla Error(‘StockInsuficiente’) if ProductStock < 0;

Concluyendo, las reglas y fórmulas que se definen en una transacción suelen estar interrelacionadasy GeneXus determina las dependencias entre ellas así como su orden de evaluación.

Observemos las 2 últimas reglas definidas:Subtract(InvoiceLineQuantity, ProductStock);Error(‘Insufficient Stock’) if ProductStock < 0;



Estas reglas están interrelacionadas porque las dos involucran al atributo ProductStock. Ahora, mientras lasegunda solamente consulta su valor, la primera lo actualiza. Entonces, la regla que actualiza al atributo será laque se disparará primero, y luego se disparará la que lo consulta.

Toda regla que actualice el valor de un atributo se disparará antes que una regla que lo consulte (esto se puedeobservar claramente en el árbol). Por este motivo es que la regla Error consulta si el atributo ProductStock quedócon valor negativo; porque como dijimos la sustracción se realizará primero.

En la programación clásica se suele consultar primero si alcanza el stock, y en caso de que sea suficiente recién se

hace la sustracción. Por eso quienes están aprendiendo GeneXus pueden intuitivamente escribir la regla:Error( ‘Insufficient Stock') if InvoiceLineQuantity > ProductStock. Esta sintaxis es correcta, sin embargo no escorrecta su lógica ya que como venimos explicando, en el árbol de evaluación determinado por GeneXus primerose disparará la regla Subtract y luego la regla Error; por lo tanto tendremos que especificar que se dispare elmensaje de error si es que quedó el stock con valor negativo, dado que ya se habrá ejecutado la sustracción almomento de consultar el valor de ProductStock.

Así que la regla que se debe definir es:

Error( ‘Insufficient Stock’ ) i f ProductStock < 0;

Y no:

Error( 'Insufficient Stock') i f InvoiceLineQuantity > ProductStock;

Cuando se dispara una regla Error, se detiene cualquier actualización a la base de datos y se desarma elárbol de evaluación, quedando todo en el estado anterior a producirse el error. Siguiendo el ejemplo queveníamos viendo, si al dispararse la regla Subtract el stock quedara negativo, se dispararía la regla Error. Comoconsecuencia de dispararse la regla Error, se desharía el Subtract que se había ejecutado, así como todas lasdemás reglas y fórmulas que se hayan ejecutado (recálculo de los atributos InvoiceLineAmount, InvoiceSubTotal,...., CustomerTotalPurchases).

¿Cóm o pod em os ver e l o rd en de eva luac ión de ter m inado por GeneXus?

Al especificar una o varias transacciones, seleccionando la opción Detailed Navigation, se detallará en el listadode navegación resultante el orden de ejecución de todas las reglas y fórmulas definidas en la transacción.



Alteraciones del orden de disparode las reglas

Supp l ie r I d *I nvoiceI d *...I nvo iceEnt Tota l Entered Total

( Product I d *I nvo iceL ineQuant i ty

I nvo iceL inePr ice

I nv oiceLin eAm oun t = I nvo iceL inePr ice * I nvo iceL ineQuant i ty )...I nv oiceCalcTotal = SUM( I nv oiceLineAm ount ) Calculated Total

Error

TotalCalculado

TotalIngresado

InvoiceLineAmount

Error(‘The calculated total doesn’t match with the entered total') if (I nv oiceEntTot al< > I nv oiceCalcTota l )On AfterLevel Level Product I d ;

En la mayoría de los casos el orden de ejecución de las reglas definido por GeneXus a partir denuestras especificaciones es el deseado. Pero en algunos casos podemos querer cambiar el momentode disparo de una regla.

Ejemplo:

Definimos una transacción para registrar las facturas que nos entregan nuestros proveedores.

El identificador del primer nivel es compuesto por el identificador de proveedor y el identificador defactura, ya que el número de factura no nos sirve como identificador único, porque proveedoresdistintos pueden repetir el mismo número de factura.

Para cada factura de un proveedor que se ingrese, nos interesa controlar que el total que vengaescrito en la factura (y que se ingresará en el atributo InvoiceEntTotal) sea correcto. Para hacer estecontrol, definimos al atributo InvoiceCalcTotal como fórmula vertical SUM(InvoiceLineAmount), yagregamos una regla Error que se disparará si no coinciden los valores de los atributosInvoiceEntTotal y InvoiceCalcTotal:

Error( 'El total ingresado no coincide con el total calculado') if InvoiceCalcTotal <> InvoiceEntTotal;

Si construimos el árbol de evaluación correspondiente a las fórmulas y regla que hemos definido enesta transacción:



vemos que las dependencias indican que cada vez que se agreguen, modifiquen o eliminen valores de los atributosInvoiceLinePrice e InvoiceLineQuantity en las líneas, se recalculará el valor del atributo InvoiceLineAmountcorrespondiente; en consecuencia, se recalculará el valor del atributo fórmula InvoiceCalcTotal que hemos definidopara tener el total calculado de la factura; y como este atributo está involucrado en la condición de disparo de laregla Error, si se cumple dicha condición de disparo, se disparará la regla Error( ‘El total ingresado no coincide conel total calculado’ ) i f InvoiceCalcTotal <> InvoiceEntTotal.

Ahora, prestemos atención a que la condición de disparo “InvoiceCalcTotal <> InvoiceEntTotal” se va a cumplirrepetidamente en la medida que el operador vaya ingresando líneas, porque para cada línea que se ingrese se

calculará el valor del atributo fórmula InvoiceLineAmount de la línea, y en consecuencia se recalculará el valor delatributo fórmula InvoiceCalcTotal. Pero el valor calculado de este atributo no coincidirá con el valor ingresado en elatributo InvoiceEntTotal hasta que no se hayan ingresado todas las líneas de la factura; entonces, se disparará laregla Error( ‘The calculated total doesn’t match with the entered total’ ) i f InvoiceCalcTotal <> InvoiceEntTotal; .

Concluimos entonces que en este caso no nos sirve lo que determina el árbol de evaluación, ya que no queremosque se evalúe la condición de disparo de la regla Error cada vez que el operador ingrese, modifique o elimine líneas,sino que recién necesitamos que se evalúe cuando el usuario haya terminado de trabajar con todas las líneas de lafactura.

GeneXus ofrece event os o m om ent os de d isparo en las transacciones, que ocurren antes o después dedeterminada acción, como la grabación del cabezal, o de una línea. Las reglas de las transacciones puedencondicionarse de manera tal de dispararse en el preciso instante en que ocurre alguno de esos eventos de disparo.

Siguiendo el ejemplo que veníamos viendo, existe un evento de disparo que ocurre luego de iterar en un nivel y

salir del mismo. La sintaxis de este evento de disparo es: AfterLevel Level A t r i b u t o , debiendo ser A t r i b u t o unatributo perteneciente al nivel que se ha iterado y se abandona.

De modo que a la regla Error de nuestro ejemplo, le agregaríamos este evento de disparo, y quedaría definida de lasiguiente forma:

Error( ‘The calculated total doesn’t match with the entered total’ ) if InvoiceCalcTotal<>InvoiceEntTotal OnAfterLevel Level I nvo iceL inePr ice ;

Con este evento de disparo que hemos agregado a la regla logramos controlar lo que deseábamos en el momentoadecuado.

Además de este evento de disparo, existen otros que veremos a continuación.



•BeforeValidate

•AfterValidate

•BeforeInsert, BeforeUpdate, BeforeDelete

•AfterInsert, AfterUpdate, AfterDelete

•AfterLevel

•BeforeComplete

•AfterComplete

Eventos de disparo

La mayoría de las reglas de transacciones permiten que se les

agregue de ser necesario un evento o momento dedisparo.

Al agregar un evento o momento de disparo a una regla,estaremos especificando que la regla se deberá ejecutar enese determinado momento.

Eventos de disparo:

Al momento de la confirmación de la transacción, ocurre una serie de acciones que es necesario conocer para poderprogramar correctamente el comportamiento de las reglas.

Para una transacción de dos niveles, podríamos enumerarlas como sigue:

• validación de los datos del cabezal

• grabación física del cabezal (ya sea inserción, modificación o eliminación)

• validación de los datos de la primera línea

• grabación física de los datos de la primera línea

• validación de los datos de la segunda línea

• grabación física de los datos de la segunda línea

• …

• validación de los datos de la n-ésima línea

• grabación física de los datos de la n-ésima línea

• commit

La acción de “validación de los datos del cabezal” ocurre cuando se han validado todos y cada uno de los camposingresados en el cabezal. Observar que en este punto ya se han disparado todas las reglas que correspondían aatributos del cabezal y que no tenían evento de disparo asociado (ejemplo: Default(InvoiceDate, &today)).Inmediatamente después se grabará el registro correspondiente al cabezal.

Análogo es el caso de las líneas: “la validación de los datos de una línea” ocurre cuando ya se han validado todos ycada uno de los datos de la línea, y también se han disparado todas las reglas correspondientes según el árbol deevaluación (ejemplo: subtract( InvoiceLineQuantity, ProductStock)). Inmediatamente después de esta acción devalidación, se grabará físicamente el registro correspondiente a la línea.

Cada transacción, al terminar de trabajar con un cabezal y sus líneas, realiza un commit (es automático; serácolocado en el código generado por GeneXus, a menos que el analista especifique lo contrario, como veremos másadelante). Es decir, si se van a ingresar los datos de dos facturas distintas utilizando la transacción “Invoice”, luegode ingresados los datos de la primera, se commitearán sus registros, y luego se ingresará la segunda, al cabo de locuál se commitearán sus registros.

Los eventos de disparo de reglas permiten definir que se ejecuten antes o después de alguna de las acciones queacabamos de enumerar. Veremos cuándo ocurre cada evento de disparo.



Evento de disparo: BeforeValidateEste evento de disparo ocurre un instante de tiempo antes de que la información de la instancia con la que se estátrabajando (cabezal o línea x) sea validada (o confirmada). Es decir, ocurrirá un instante de tiempo antes de laacción de “validación del cabezal” o “validación de la línea”, según corresponda. Observar que aquí también sehabrán disparado todas las reglas según el árbol de evaluación que no estén condicionadas a evento de disparoalguno.

Eventos de disparo: AfterValidate, BeforeInsert, BeforeUdate, BeforeDelete

El evento de disparo AfterValidate permite especificar que una regla se ejecute inmediatamente antes de que se

grabe físicamente cada instancia del nivel al cual está asociada la regla, en la tabla física correspondiente, y despuésde que se hayan validado los datos de esa instancia.

En otras palabras, si se le agrega el evento de disparo AfterValidate a una regla, la misma se ejecutará para cadainstancia del nivel al cual esté asociada, inmediatamente antes de que la instancia se grabe físicamente (yasea que se inserte, modifique o elimine) como registro en la tabla física asociada al nivel.

EJEMPLOS

1. Hay veces en las que no contamos con la posibilidad de utilizar la propiedad Autonumber para numerar de formaautomática y correlativa los atributos que son clave primaria simple. Tal funcionalidad es provista por losmanejadores de base de datos (DBMSs) y GeneXus la aprovecha y permite usarla; sin embargo en los casos en losque no se trabaja con un manejador de base de datos, no contamos con la posibilidad de utilizar esta facilidad.

En esos casos en los que necesitamos numerar de forma automática y correlativa ciertos atributos, y no podemosutilizar la propiedad Autonumber, debemos resolverlo programándolo. Para ello solemos definir una transacciónconteniendo dos atributos, uno para almacenar un literal y otro para almacenar el último número asignadoautomáticamente al atributo descripto por el literal1; la transacción conlleva la creación de una tabla, y definimos unprocedimiento que consulta esa tabla, obtiene el último número asignado para el atributo a ser numerado, le sumauno y devuelve el próximo número, además de actualizarlo en la tabla.Para invocar al procedimiento de numeración automática se debe definir en las transacciones que lo requieran unaregla del siguiente estilo:

CustomerId = PGetNumber.udp( ‘CUSTOMER’ ) if Insert on AfterValidate;

En este caso se está queriendo autonumerar el atributo CustomerId de la transacción “Customer”

Del mismo modo, si queremos autonumerar el identificador de facturas, escribiríamos en la transacción “Inovice” lasiguiente regla:

InvoiceId = PGetNumber.udp( ‘INVOICE’ ) if Insert on AfterValidate;

De esta forma definimos que se efectúen numeraciones automáticas en las transacciones únicamente cuando serealicen inserciones (por la condición de disparo: if Insert) e inmediatamente antes de que se grabefísicamente cada instancia a ser insertada (por el evento de disparo: on AfterValidate) a través del primer nivelde la transacción (porque en las dos reglas de invocación mostradas, hay solamente un atributo involucrado quepertenece al primer nivel de las transacciones "Customer" e "Invoice" respectivamente).

El motivo por el cual agregamos el evento de disparo on AfterVal idate a estas reglas es para invocar alprocedimiento de numeración automática inmediatamente antes de que se inserte el registro en la base de datos yluego de la validación, intentando de esta forma tener el mayor grado de seguridad posible de que el númeroasignado será utilizado (y no perder números). Piense unos instantes el lector cuándo se dispararía la regla anteriorde no estar condicionada a evento de disparo alguno, y qué podría pasar en el caso de que fallara la validación dealguno de los datos del cabezal. La respuesta es simple: se perdería un número. Es decir, si el número de facturaanterior fuera 5 y el usuario quisiera ingresar la siguiente factura, la regla de asignación con udp que invoca laprocedimiento de numeración se dispararía ni bien se ingresara a la transacción estando en modo insert, ya queinvolucra al primer atributo del cabezal. El procedimiento devolvería el número 6, y si validando los datos delcabezal se encuentra algún error que no permite continuar con el proceso, y se abandonara la transacción, porejemplo, ese número 6 se habrá perdido y la próxima factura, que correlativamente debería tener el número 6 no lotendrá, tendrá el 7.

----------------------------------------------------------------------------------------------------------------------------1 Cuando vimos la regla serial introdujimos este tema de numeración de cabezales, con la transacción “Number” queera la que tenía el literal: NumberCode y el último número asignado a la transacción correspondiente a ese literal:NumberLast



Existen tres eventos de disparo que ocurren en el mismo momento que el AfterValidate, pero que ya contienenintrínseco el modo. Ellos son: BeforeInsert, BeforeUpdate y BeforeValidate.Es equivalente escribir la regla presentada antes como lo hicimos, a escribirla:

InvoiceId = PGetNumber.udp( ‘INVOICE’ ) on BeforeInsert;

Observar que aquí es redundante condicionar la regla a “If Insert”. Por tanto, valen las siguientes equivalencias:

on BeforeInsert ∼ If Insert on AfterValidateon BeforeUpdate ∼ If Update on AfterValidateon BeforeDelete ∼ If Delete on AfterValidate

Si hacemos un esquema de las acciones que rodean al evento de disparo, quedarán claros los dos sinónimoselegidos para este evento (AfterValidate y BeforeInsert para modo insert)

VALIDACIÓN DE LOS DATOSAfterValidate – BeforeInsert – BeforeUpdate – BeforeDeleteGRABACIÓN DEL REGISTRO (insert, update, delete según corresponda)

2) Si definimos una regla a la cual le incluimos también el evento de disparo on AfterVa lidate, u onBeforeInsert, BeforeDelete, BeforeUdate pero a diferencia de los ejemplos recién vistos, se referencia en laregla al menos un atributo del segundo nivel de la transacción en la cual se está definiendo la regla, la misma estaráasociada al segundo nivel1. Por lo tanto, la regla se ejecutará inmediatamente antes de que se grabe

físicamente cada instancia correspondiente al segundo nivel de la transacción.

Eventos de disparo: AfterInser t, AfterUpdate, AfterDelete

Así como existe un evento de disparo que permite definir que determinadas reglas se ejecuten inmediatamenteantes de que se produzca la grabación física de cada instancia de un nivel (AfterValidate, BeforeInsert,BeforeUpdate, BeforeDelete), también existen eventos de disparo para definir que ciertas reglas se ejecuteninmediantamente después de que se inserten, modifiquen o eliminen físicamente instancias de un nivel.Estos eventos son AfterInsert, AfterUpdate y AfterDelete.

El evento de disparo AfterInsert permite definir que una regla se ejecute inmediatamente después de que se insertefísicamente cada instancia del nivel al cual está asociada la regla; el AfterUdate luego de que se actualicefísicamente la instancia, y el AfterDelete luego de que se elimine.

EJEMPLOS

Supongamos que en la transacción "Customer" queremos invocar a un reporte que realice la impresión de los datosde cada cliente con el cual se trabaje por medio de la transacción.

¿En qué momento debemos realizar la invocación al reporte desde la transacción?

Caso 1: RPrintCustomer.call( CustomerId ) on AfterValidate;

No es adecuado agregarle este evento de disparo a la regla de invocación al reporte, porque éste se invocaríainmediatamente antes de la grabación física de cada cliente. En consecuencia, el reporte no encontraría alcliente con sus datos en la tabla CUSTOMER (si se estaba insertando un cliente por medio de la transacción), o loencontraría con sus datos desactualizados (si se estaba modificando un cliente por medio de la transacción). Si encambio se estaba eliminando un cliente por medio de la transacción, el reporte encontraría los datos del cliente en latabla CUSTOMER y los listaría justamente antes de la actualización física (eliminación).

Si se desea esto, es decir, emitir un listado con los datos de cada cliente que se elimine, sería adecuado definir lasiguiente regla:

RPrintCustomer.call( CustomerId ) on BeforeDelete;o su equivalente:RPrintCustomer.call( CustomerId ) if delete on AfterValidate;

--------------------------------------------------------------------------------------------------------------------------1 Existe otra forma de provocar que una regla que contiene atributos de un nivel determinado, se dispare en el nivelsiguiente, mediante la cláusula Level que mencionamos cuando vimos conceptos importantes sobre reglas detransacciones.

t i e m p o



para restringir el disparo de la regla únicamente a cuando se esté eliminando un cliente, porque es el único caso enel sería correcto utilizar el evento de disparo AfterValidate (ya que justamente necesitamos emitir el reporte antesde la eliminación).

Caso 2: RPrintCustomer.Call( CustomerId ) on AfterInsert;

El evento de disparo AfterInsert ocurre inmediatamente después de que se inserte físicamente cada instanciaasociada a cierto nivel de la transacción (en este caso, como el único atributo involucrado en la regla es CustomerId,se trata de una regla asociada al primer y único nivel de la transacción "Customer").

Como lo indica claramente su nombre, el evento de disparo AfterInsert sólo ocurre al insertar una nueva instancia(precisamente luego de ser insertada como registro físico). Es por ello que cuando se agrega el evento de disparo onAfterInsert a una regla, no es necesario agregarle la condición de disparo i f insert.

Es correcto agregarle este evento de disparo a la regla de invocación al reporte, ya que el reporte se invocaríainmediatamente después de que se inserte físicamente cada cliente. Así que el reporte encontraría al clientecon sus datos en la tabla CUSTOMER y los imprimiría.

Lo que debe quedar claro es que con esta definición el reporte se invocará únicamente luego de realizar inserciones.

Caso 3: RPrintCustomer.Call( CustomerId ) on AfterUpdate;

El evento de disparo AfterUpdate ocurre inmediatamente después de que se actualice físicamente cada instanciaasociada a cierto nivel de la transacción (en este caso, como el único atributo involucrado en la regla es CustomerId,se trata de una regla asociada al primer y único nivel de la transacción "Customer").

Es adecuado agregarle este evento de disparo a la regla de invocación al reporte, ya que el reporte se invocaríainmediatamente después de que se actualice físicamente un cliente. Así que el reporte encontraría al clientecon sus datos actualizados en la tabla CLIENTES y los imprimiría.

El reporte se invocará únicamente luego de realizar actualizaciones.

Caso 4: RPrintCustomer.Call( CustomerId ) on AfterDelete;

El evento de disparo AfterDelete ocurre inmediatamente después de que se elimine físicamente cada instanciaasociada a cierto nivel de la transacción (en este caso, como el único atributo involucrado en la regla es CustomerId,se trata de una regla asociada al primer y único nivel de la transacción "Customer").

No es adecuado agregarle este evento de disparo a la regla de invocación al reporte, porque el reporte se invocaríainmediatamente después de la eliminación física de cada cliente. En consecuencia, el reporte no encontraría alcliente con sus datos en la tabla CUSTOMER.

Caso 5: RPrintCustomer.Call( CustomerId ) on AfterInse rt, AfterUpdate;RPrintCustomer.Call( CustomerId ) if delete on AfterValidate;

Para finalizar, estas dos reglas son las adecuadas para invocar a un reporte en la transacción "Customer", con elobjetivo de imprimir los datos de cada cliente con el cual se trabaje, abarcando los tres modos de trabajo.

Como se puede observar en la primera regla es posible incluir varios eventos de disparo separados por coma,cuando los mismos aplican a una misma regla.

Es decir, es lo mismo definir estas dos reglas independientes:

RPrintCustomer.Call( CustomerId ) on AfterInsert;RPrintCustomer.Call( CustomerId ) on AfterUpdate;

que esta regla:

RPrintCustomer.Call( CustomerId ) on AfterInsert, AfterUpdate;



Caso 6: Si definimos una regla a la cual le incluimos el evento de disparo on AfterInsert, pero a diferencia de losejemplos recién vistos, se referencia en la regla al menos un atributo del segundo nivel de la transacción en la cual seestá definiendo la regla, la misma estará asociada al segundo nivel. Por lo tanto, la regla se ejecutaráinmediatamente después de que se inserte físicamente cada instancia correspondiente al segundo nivel de latransacción.

Análogo es el caso de on AfterUpdate y on AfterDelete.

Ampliamos el esquema que habíamos efectuado antes, de las acciones que rodean a los eventos de disparo vistos

hasta ahora:

VALIDACIÓN DE LOS DATOS

AfterValidate – BeforeInsert – BeforeUpdate – BeforeDelete

GRABACIÓN DEL REGISTRO (insert, update, delete según corresponda)

AfterInsert – AfterUpdate – AfterDelete

Este esquema se repite para cada instancia del nivel. Por ejemplo, pensemos en el ingreso de las líneas de unafactura. Para cada línea ocurrirá este esquema, por lo que podemos pensar en un loop que se repite hasta que setermina de grabar la última línea.

La acción que sucede a la grabación de la última línea sería el abandonar ese nivel (en este caso el de las líneas defactura). Y luego de esa acción, a menos que venga otro nivel con el que se volvería a ingresar en el esquemaanterior, ocurrirá la última acción en la ejecución, que es el commit.

Entre la acción de abandonar el nivel, y el commit tendremos un evento (que admite dos nombres distintos) y otropara luego del commit. Son los que veremos a continuación pero que ya mostramos en esquema:

VALIDACIÓN DE LOS DATOS CABEZAL




VALIDACIÓN DE LOS DATOS LÍNEA




ABANDONAR NI VEL 2AfterLevel - BeforeComplete

COMMIT

AfterComplete

t i e m p o

t i e m p o

loop



Eventos de disparo: AfterLevel, BeforeComplete

El evento de disparo AfterLevel permite definir que una regla se ejecute inmediatamente después de terminarde iterar determinado nivel.

SINTAXIS: regla [if condición de disparo] [on AfterLevel Level atributo];

DONDE:regla: es una regla de las permitidas en transaccionescondición de disparo: es una expresión booleana que permite involucrar atributos, variables, constantes y funcionesasí como los operadores Or, And, Not.atributo: es un atributo perteneciente al nivel para el cual se desea que luego de ser iterado, se ejecute la regla.

FUNCIONALIDAD:

Si el atributo que se especifica a continuación del evento de disparo AfterLevel pertenece al segundo nivel de latransacción, la regla se ejecutará cuando se hayan terminado de iterar todas las líneas del segundo nivel.

Y si el atributo que se especifica a continuación del evento de disparo AfterLevel pertenece al primer nivel -siguiendoel mismo concepto- la regla se ejecutará cuando se haya terminado de iterar por todos los cabezales. Observar queesto se da al final de todo, es decir, una vez que se hayan ingresado todos los cabezales y sus líneas y se cierre latransacción (en ese momento se habrán iterado todos los cabezales). Por lo tanto, si el atributo especificadopertenece al primer nivel, la regla se disparará una vez sola antes del Evento Exit (es un evento que se ejecuta unasóla vez cuando se cierra una transacción en tiempo de ejecución, como veremos).

Ejemplo: Rever el ejemplo presentado antes, donde teníamos una transacción para representar las facturas que nosentregan nuestros proveedores, y donde queríamos controlar que el total calculado de cada factura coincidiera con etotal ingresado. Allí teníamos la regla:

Error( 'El total ingresado no coincide con el total calculado') if InvoiceCalcTotal<>InvoiceEntTotal;

que necesitáramos se disparara luego de ingresadas todas las líneas de la factura. Por tanto, el evento de disparoapropiado será AfterLevel Level att, donde att sea cualquier atributo de las líneas.

El evento de nombre BeforeComplete, en este caso, coincide con el AfterLevel . Si observamos el esquemapresentado en la página anterior, podemos ver que el instante de tiempo que hay entre que se abandona el últimonivel y se realiza el commit es el instante en que ocurren estos eventos. Son dos nombres para referirnos a lo mismo.

Cuidado que esto es así siempre y cuando el nivel abandonado sea el último. Supóngase por ejemplo una transaccióncon dos niveles paralelos. Por ejemplo, si agregamos al cliente sus direcciones de mail y sus números telefónicos(puede tener varios):

CustomerId*

CustomerName

…(CustomerPhone*…)

(CustomerEMail*…)

El momento en que deberá dispararse una regla condicionada a: On AfterLevel Level Custom erPhon e NOCOINCIDIRA con el de una regla condicionada a on BeforeComplete.

Mientras que la primera se disparará cuando se abandona el nivel de los teléfonos, y antes de entrar a validar todoslos emails, la segunda se disparará después de abandonar este último nivel.En este caso el evento BeforeComplete coincidirá con el AfterLevel Level Cust om erEMai l .

Evento de disparo: AfterComplete

Este evento corresponde al instante de tiempo que sucede al commit. Hablaremos más de este evento unas páginasadelante, cuando estudiemos la integridad transaccional.Si se abre la transacción de facturas, se ingresan 3 facturas (cabezal y sus respectivas líneas) y se cierra latransacción, ocurrirán 3 commits (uno al final de cada ingreso de cabezal + líneas) y 3 eventos AfterComplete.



REGLAS STAND-ALONE

EVALUACION DE REGLAS Y FORMULAS SEGÚN ARBOL


PARA

CADA

LINEA

Interactivamente (Web o Win con Client Side Validation) y antes de confirmar:

Ejemplo en transacción de 2 niveles

El siguiente ejemplo pretende mostrar visualmente en qué momentos se irán disparando las reglas yfórmulas definidas en una transacción1.

Esto dependerá en parte del tipo de diálogo, aunque el orden será el mismo para cualquiera de ellos.La diferencia radicará en el momento en que se realizará la grabación de los registros y el disparo dereglas que estén condicionadas a eventos.

Si tenemos un diálogo con validación a nivel del cliente (.Net o Java, ya sea interfaz Win con lapropiedad Client Side Validation en Yes, o interfaz Web) entonces las reglas que no posean eventode disparo, así como las fórmulas, se ejecutarán en forma interactiva a medida que el usuario vayapasando por los campos (ejecución en el cliente).

El disparo de reglas y fórmulas se irá haciendo de acuerdo al árbol de evaluación, siguiendo el ordenque éste determina.

Una vez que el usuario confirme la pantalla (esto es, en Win: presione el botón “Confirm”, cuyotítulo será: Add, Update, Delete, Confirm, según el caso; en Web: presione el botón “ApplyChanges”), los datos se enviarán al servidor y allí se realizarán las validaciones y disparo de reglas yfórmulas mencionadas antes, nuevamente, además de dispararse las reglas que estén condicionadasa eventos de disparo, por primera vez, junto con las grabaciones de los registros correspondientes,en el orden que se muestra en la siguiente hoja. Esto se realizará en el servidor.

Si el diálogo es a pantalla completa, en el cliente no se disparará nada, y todo se hará en elservidor, como se muestra en la siguiente hoja.

Con respecto al diálogo campo a campo, si bien el orden será el mismo que el de la siguiente hoja,la diferencia se encuentra en el momento en que esto se realiza: en este tipo de aplicaciones, seráabsolutamente interactivo, dado que cuando el usuario pase en la pantalla del cabezal a las líneas, ode una línea a la siguiente, ya en ese momento se realizará la grabación.



REGLAS STAND-ALONE

EVALUACION REGLAS Y FÓRMULAS SEGÚN ARBOL

AfterValidate / BeforeInsert / Update / DeleteGRABACION DEL CABEZAL

AfterInsert / Update / Delete

AfterValidate / BeforeInsert / Udpate / DeleteGRABACION DE LA LINEA

AfterInsert/Update/Delete

AfterLevel Level attNivel2 - BeforeComplete

AfterCompleteCOMMIT

VALIDACIÓN


PARA CADALINEA

Al confirmar los datos, se ejecutan en el siguiente orden:

VALIDACIÓN

ABANDONAR NIVEL 2

BeforeValidate

BeforeValidate


Reglas s tand a lon e

Las reglas stand alone son aquellas que:1. Pueden ejecutarse con la información provista por los parámetros recibidos.2. No dependen de nada para ejecutarse.

Ejemplos de reglas stand alone (por poder ejecutarse con la información provista por los parámetros):• &A = parámetro2;• Msg( ‘...’ ) if parámetro1 = 7;

Ejemplos de reglas stand alone (por no depender de nada para ejecutarse):• msg( ‘You are in the invoice transaction’);• &A = 7;

Por lo tanto, son las primeras reglas que pueden ejecutarse.

Luego de la ejecución de las reglas stand alone, se ejecutan las reglas asociadas al primer nivel de latransacción, que no tengan evento de disparo definido, siguiendo el orden de dependencias determinadopor GeneXus (así como las fórmulas asociadas al primer nivel). A modo de ejemplo, se disparará la regla:

“Default( InvoiceDate, &Today);”

Después de ejecutadas las reglas mencionadas para el cabezal, se ejecutarán todas las reglas que tengan

como evento de disparo BeforeValidate , ya que inmediatamente después ocurrirá la acción devalidación (o confirmación) de la información de ese primer nivel.

Inmediatamente después de la validación del primer nivel se ejecutan las reglas asociadas al primer nivelde la transacción que incluyan en su definición el evento de disparo Af te r Va l i da te , o los Before I nser t ,Be fo r eU pda te , Be fo r eD e le te , dependiendo del modo en el que se esté.

Por ejemplo: Si no podemos autonumerar las facturas con la propiedad Autonumber por no ser soportadapor el DBMS elegido:

InvoiceId = PGetNumber.udp(‘INVOICE’) on BeforeInsert;



Seguidamente a la ejecución de las reglas asociadas al primer nivel con alguno de estos eventos de disparo seejecuta la acción de grabación; es decir, se grabará físicamente la instancia correspondiente al primer nivelde la transacción como registro físico en la tabla correspondiente (en este ejemplo, en la tabla: INVOICE).

Inmediatamente después de haberse grabado esa instancia:

• si la grabación correspondió a una inserción: se ejecutarán las reglas asociadas al primer nivel de latransacción con evento de disparo AfterInsert.• si la grabación correspondió a una actualización: se ejecutarán las reglas asociadas al primer nivel de latransacción con evento de disparo AfterUpdate.•

si la grabación correspondió a una eliminación: se ejecutarán las reglas asociadas al primer nivel de latransacción con evento de disparo AfterDelete.

Aclaración importante: Todas las operaciones sombreadas, tanto en gris claro como en gris oscuro, seejecutan únicamente si se trata de una transacción de dos niveles; de modo que cuando se trata de unatransacción de un nivel, tales operaciones no se ejecutarán. El motivo de los dos sombreados distintos, espara diferenciar el conjunto de operaciones que se ejecuta para cada una de las líneas (sombreado gris claro)de las operaciones que se ejecutan solamente una vez finalizada la iteración en las líneas (sombreado grismás oscuro). A continuación seguimos explicando en orden, el resto de las operaciones que se ejecutan, así sea que se trate de una transacción de un nivel o dos.

Luego de haberse ejecutado todas las operaciones explicadas hasta el momento, se efectuará un com m it ,siempre y cuando el ambiente o plataforma de trabajo sea Cliente/Servidor.

Si se trata de una transacción de dos niveles, como en este caso, a continuación se ejecutará para cada unade las líneas:

En primer lugar, las reglas asociadas al segundo nivel de la transacción que no tengan evento de disparodefinido, siguiendo el orden de dependencias determinado por GeneXus (así como las fórmulas asociadas alsegundo nivel). Ejemplos de ello son la regla

Subtract( InvoiceLineQuantity, ProductStock );

la fórmula

InvoiceLineAmount = InvoiceLineQuantity*ProductPrice.

Después de ejecutadas las reglas mencionadas para una línea, se ejecutarán todas las reglas que tengancomo evento de disparo BeforeValidate , dado que inmediatamente después ocurre la validación de lalínea; esto es una acción que ocurre a continuación de haber terminado de trabajar con la línea.

Inmediatamente después de la validación de la línea, se ejecutarán las reglas asociadas al segundo nivelde la transacción que incluyan en su definición alguno de los eventos de disparo: AfterValidate,BeforeInsert, BeforeUpdate, BeforeDelete.

Seguidamente a la ejecución de las reglas asociadas al segundo nivel con alguno de estos eventos dedisparo se ejecutará la acción de grabación; es decir, se grabará físicamente la instancia correspondiente ala línea como registro físico en la tabla correspondiente (en este ejemplo, en la tabla: INVOICELINE).

Inmediatamente después de haberse grabado la instancia correspondiente a la línea como registro físico enla tabla correspondiente:

• si la grabación correspondió a una inserción: se ejecutarán las reglas asociadas al segundo nivel de la

transacción con evento de disparo AfterInsert.• si la grabación correspondió a una actualización: se ejecutarán las reglas asociadas al segundo nivel de latransacción con evento de disparo AfterUpdate.• si la grabación correspondió a una eliminación: se ejecutarán las reglas asociadas al segundo nivel de latransacción con evento de disparo AfterDelete.

Todas estas operaciones sombreadas de gris claro, se ejecutarán en el orden descrito, para cada una de laslíneas.

Luego de la iteración de todas las líneas, podemos suponer la existencia de una acción que podríamosllamar abandono del segundo nivel. Luego de la misma se ejecutarán las reglas definidas con evento dedisparo AfterLevel Level At r i bu to de l 2do n i v e l . Si no existe otro nivel, como es el caso del ejemplo,

entonces coincidirá con el evento de disparo BeforeComplete.



A continuación se ejecutarán las reglas con evento de disparo AfterComplete.

Es de fundamental importancia que quede claro que todas las operaciones explicadas se ejecutarán en el ordenen el que se han descrito, para cada factura con la cual se trabaje por medio de la transacción "Invoice" (ya seaque se ingrese, modifique o elimine).

Puede ser útil tener en cuenta que se han resaltado en negrita las acciones cada vez que se las ha mencionado.Las mismas son: validación, grabación , abandono del segundo nivel y commit.

Es indispensable asimilar el orden en el que se ejecutan las reglas en una transacción, cuáles son los eventos dedisparo disponibles para asignarles, cuándo se disparan exactamente, y qué acciones ocurren antes y después decada evento de disparo, ya que solamente conociéndolos bien se podrá programar el comportamiento de lastransacciones adecuadamente. Es sencillo comprender que si necesitamos programar determinados controles oacciones en las transacciones, tendremos que saber bien si hacerlo antes de que se grabe el cabezal, después deque se haya grabado el mismo, para cada una de las líneas después de que se hayan grabado, o antes, despuésdel commit o antes, por lo tanto es fundamental tener claro todo este tema.

Nos ha faltado mencionar cuándo ocurrirá una regla condicionada al evento de disparo: AfterLevel Level Atributo1er nivel.

Diferencia entre aplicación 3 capas Win y aplicación W eb

Aquí aparece una diferencia importante entre Win y Web, que tiene que ver con las características inherentes acada una. Mientras que en Win la capa de la aplicación que se encuentra en el cliente se mantiene conectada alservidor de manera continua (el servidor mantiene “estado”) , en Web la conexión es discreta: se logra cuandodeben intercambiar información y luego se desconectan; no se mantiene un estado. Esto establece algunasdiferencias en el comportamiento de las transacciones.

Mientras que una aplicación Win mantiene la conexión con el servidor de manera tal que éste pueda mantener elestado de una transacción que se esté ejecutando: controlar cuándo se abrió, cuántas instancias se haningresado y cuándo se ha cerrado la misma, en Web esto no es posible (no mantiene estado).

Por tanto una regla condicionada al evento de disparo AfterLevel Level atributo del 1er. nivel solo se dispararáen una transacción Win (para una Web no tiene sentido) y lo hará una sola vez, cuando se cierra latransacción. Recordemos que una regla con evento de disparo AfterLevel Level Atributo 1er nivel se ejecutaluego de que se haya iterado por todos los cabezales, y esto se da al final de todo, es decir, una vez que se hayatrabajado con todos los cabezales y sus líneas y se cierre la transacción (en ese momento se habrá iterado portodos los cabezales).

No podemos dejar de mencionar algo que también para Win se ejecutará una única vez en la ejecución de unatransacción: el Evento Start y el Evento Exit.

Como mencionaremos luego, en una transacción Web estos eventos se ejecutarán una vez por cada instancia detransacción con la que se trabaje.



Ejemplos

¿Cuándo se dispararán las siguientes reglas?

• PSomething.call( InvoiceId ) if Insert;

• PSomething.call( InvoiceId ) on BeforeInsert;

• PSomething.call( InvoiceId, ProductId ) on BeforeInsert;

• PSomething.call( InvoiceId ) on BeforeInsert Level ProductId;

Luego de validado el campo InvoiceId e inferido que se está en modo Insert

Luego de disparadas todas las reglas y fórmulas según árbol, y validadostodos los datos del cabezal. Un instante antes de insertar el registro.

Luego de disparadas todas las reglas y fórmulas según árbol, y validadostodos los datos de la línea. Un instante antes de insertar el registro.

Ídem que el anterior. Observar que Level ProductId especifica que se estáhablando del BeforeInsert de las líneas y no del cabezal.



Ejemplos

Algunas reglas están mal programadas. ¿Cuáles?

• InvoiceDate = &today on AfterInsert;

• PSomething.call( InvoiceDate ) on AfterInsert;

• PSomething.call( InvoiceId, ProductId ) on AfterLevel LevelProductId;

Incorrecto: El último momento para asignar valor a un atributo del cabezales inmediatamente antes de su grabación (BeforeInsert)

Correcto: aquí se está pasando el valor de un atributo del cabezal; mientrasse esté en la instancia de la factura se tiene ese valor en memoria. Últimomomento posible para utilizarlo AfterComplete.

Incorrecto: la regla, sin el evento de disparo está asociada al 2do. Nivel, esdecir, se dispararía por cada línea. Pero el evento de disparo la condiciona aejecutarse al salir de las líneas. ¿Qué valor tendría ProductId?



Reglas con el mismo evento de disparo

• Son disparadas en el orden en que fueron definidas

• Ejemplo 1 ‘xxx’.call() On AfterComplete; ‘yyy’.call() On AfterComplete;

• Ejemplo 2 ‘pgmname’.call( CustomerId, &flag) On AfterComplete;error(' ') if &flag = 'N’ On AfterComplete;

Reglas con el mismo evento de disparo

Cuando en una transacción se definen dos o más reglas con el mismo evento de disparo, y no existeninguna dependencia entre ellas, las mismas se ejecutarán respetando el orden de definición.

Ejem plos:

1) Se definen las siguientes reglas en una transacción:

‘xxx’.Call() on AfterComplete;

‘yyy’.Call() on AfterComplete;

Como las dos reglas definidas están condicionadas con el mismo evento de disparo, y no existeninguna dependencia entre ellas, las mismas se ejecutarán en el mismo orden en el cual se hanescrito.

2) En una transacción se necesita invocar a un procedimiento que realiza determinada validación yretorna un valor ‘S’ o ‘N’; si el valor devuelto es ‘N’, se debe dar un mensaje de error.

Para resolver esto, evaluaremos dos posibilidades:

2.1) Definir las reglas:PXXX.call(&flag) on AfterValidate;

error(‘…’) if &flag=‘N’ on AfterValidate;

2.2) O definir las reglas:

&flag = PXXX.udp() on AfterValidate;

error(‘…’) if &flag=‘N’ on AfterValidate;



En la primera alternativa, se ha definido una regla call y una regla error. Ambas reglas tienen el mismoevento de disparo, y aparentemente existiría dependencia entre ellas, ya que la regla de error estácondicionada al valor de la variable &flag, y la variable &flag se pasa por parámetro en la regla call.

Sin embargo, si bien la dependencia nos puede parecer evidente porque en el procedimientoprogramaremos a la variable &flag, de salida, en la sección de reglas de la transacción -que es donde seencuentran las reglas que estamos viendo-, el especificador de GeneXus no puede saber si los parámetrospasados en un call son de entrada, de salida, o de entrada-salida; en consecuencia el especificador no

encontrará interdependencia entre las reglas call y error, ya que la variable &flag podría ser pasada comovariable de entrada al procedimiento, y en ese caso por ejemplo, no habría una dependencia por la cualprimero se deba ejecutar la regla call y luego la regla error.

Así que concluyendo, no se detectan dependencias entre las reglas cal l y e r r o r de la alternativa 2.1), por loque las mismas se dispararán entonces en el orden en el que estén escritas. Es importante ver que si lasreglas call y error estuvieran escritas en orden inverso (es decir, primero la regla error y después la reglacall), el comportamiento no será el esperado en muchos casos.

Con respecto a la segunda alternativa, observemos que la misma consiste en una regla con udp y una reglaerror. Ambas reglas tienen el mismo evento de disparo, y en este caso sí existe dependencia entre ellas, yaque la regla error está condicionada al valor de la variable &flag, y como la invocación al procedimiento serealiza con udp, para el especificador de GeneXus queda claro que la variable &flag vuelve modificada delprocedimiento; por lo tanto el especificador de GeneXus entiende que primero se debe disparar la

invocación al procedimiento con udp y luego la regla error, porque la variable &flag se carga mediante lainvocación al procedimiento con udp, y luego de que dicha variable tenga valor, es que habrá que evaluar sidisparar la regla error, o no.

En el caso 2.2) entonces, independientemente del orden de definición de ambas reglas, la invocación alprocedimiento con udp se disparará primero, y luego de ello, se disparará la regla error (en caso de que secumpla la condición de disparo, claro está).

Por esta razón se recomienda que siempre que se quieran definir validaciones de este tipo, se utilice udp enlugar de call.



Consideración importante acerca deldisparo de reglas

• Reglas que no tienen evento de disparo asociado, se ejecutarán una vez o

dos o tres, dependiendo de si se trabaja con Confirmation (y en Win conClient Side Validation)

• Ejemplo: Client Side Validation √

Confirmation √

• ¡Cuidado si la regla es una invocación a un procedimiento que actualiza laBD!

Para que no se dispare más de una vez, habrá que asignarle evento de disparoespecífico a la regla, (o bien, para Win, dejar el diálogo a pantalla compl

eta para estatransacción), o estudiar bien la lógica del procedimiento y tener en cuenta la doble otriple ejecución del mismo.

• Esto no sucederá con reglas de GeneXus (como subtract, add) que actualizan

la BD porque GX tiene la inteligencia para realizar el update solo al confirmar(lo mostrado en forma interactiva se calcula en memoria).

Reglas que no tienen evento de disparoasociado, se dispararán 3 veces

Es importante tener en cuenta que las reglas que no tienen evento de disparo asociado, se ejecutarán unavez o dos o tres, dependiendo de lo que se haya configurado en la propiedad del modelo Confirmation yde tratarse de una aplicación .Net o Java Win, de la propiedad Client Side Validation (recordemos queen Web siempre se trabaja con este tipo de diálogo)

Por ejemplo, si se trabaja en Web o en Win (con la propiedad: Client Side Validation=Yes) y propiedadConfirmation=No, valor por defecto, las reglas que no tengan evento de disparo asociado se dispararán:

primero en forma interactiva en la medida que el usuario final vaya trabajando en el form, y luegonuevamente cuando el usuario final efectúe la confirmación.

Es especialmente importante considerar esto en aquellos casos de reglas que consistan eninvocaciones a procedimientos que actualicen la base de datos.

Si se tiene una invocación a un procedimiento que actualiza la base de datos, habrá que optar por algunade las siguientes alternativas para evitar que se dispare más de una vez:

• asignarle evento de disparo específico a la regla

• o bien decidir si configurar o no la propiedad CSV del modelo con Yes (solo Win) y la confimation

• o estudiar bien la lógica del procedimiento y tener en cuenta la doble o triple ejecución del mismo

Si trabajando en Win, en lugar de configurar la propiedad: Client Side Validation= Yes, se la dejara convalor No y se configurara la propiedad Confirmation= Yes, estaríamos en la misma situación de doble

disparo de las reglas que no tienen evento de disparo. En este caso no se dispararían en forma interactivalas reglas (ya que la propiedad Client Side Validation=No) pero se dispararían en la primera confirmacióndel usuario (en la cual se efectúan las validaciones pero no se graba) y en la reconfirmación del usuario(en la cual se efectúan las validaciones y se graba).

Por último, si se configurara Confirmation= Yes (y en Win Client Side Validation= Yes), las reglas sinevento de disparo asociado tendrían un triple disparo.



EVENTOS EN TRANSACCIONES

En las transacciones se permite la programación dirigida por eventos, que es un estilo deprogramación en el cuál se define código que permanece ocioso, hasta que suceden eventosprovocados por el usuario o por el sistema, que provocan que el código definido se ejecute.

Los eventos son acciones reconocidas por un objeto que pueden suceder o no. A cada evento se lepuede asociar código, que se ejecutará solamente si el evento se produce.

El código que se le puede asociar a un evento se escribe siguiendo el estilo procedural; y cuando elevento se produce, el código asociado al mismo se ejecutará secuencialmente.



Eventos en Transacciones

• Evento Start

• Evento ‘User Event’

• Evento After Trn

• Evento Exit

Los eventos Start y Exit difieren de acuerdo a la interfaz que se utilice.

Como en Web no se mantiene un estado en el servidor que permita saber qué es lo que se ejecutóen el cliente, no es posible saber si se está ingresando la primera instancia de una factura, o si es lan-ésima. Por esta razón, mientras que el evento Start se ejecutará en una aplicación Win una solavez cuando se abre la transacción, y luego con cada iteración no vuelve a ocurrir, en Web esto noes posible, por lo que se disparará el evento cada vez que se envíe al servidor la información de la

instancia con la que se esté trabajando.

Análogas consideraciones podemos hacer para el caso del evento Exit: en una aplicación Win esposible saber que se está abandonando la transacción, por lo que puede capturarse ese evento. Encambio en una aplicación Web esto no será posible, razón por la cuál el evento se ejecutará porcada iteración, al final de la misma.



Evento Start

• Se ejecuta:

• Win: una sola vez, cuando se abre una transacción entiempo de ejecución.

• Web: cada vez que se somete el form de latransacción al servidor.

Event Startcódigo

EndEvent

EJEMPLO: Event Start&entrada=Now()

EndEvent

SINTAXIS:

El evento Start es un evento del sistema, por lo tanto ocurre automáticamente. ¿En qué momento seejecuta? La respuesta dependerá de si se trata de una transacción Win o Web.

Win: Cuando comienza la ejecución del programa asociado a una transacción, es decir, ni bien se abreuna transacción en tiempo de ejecución. Entonces, en el evento Start de una transacción se puede incluircódigo que se desee se ejecute una única vez, cuando comience la ejecución de la transacción.

Generalmente el código que se incluye en este evento, es para inicialización (ejemplo, asignar valores avariables para inicializarlas una única vez en la ejecución del programa).

EJEMPLO:

En una transacción nos interesa capturar la fecha y hora de entrada a la misma. Para ello en el eventoStart le asignamos a una variable de nombre &entrada y tipo de datos DateTime, el resultado de lafunción Now() que devuelve la fecha y hora actual:

Event Start

&entrada = Now()

EndEvent

Web: Se ejecutará cada vez que se someta el form de la transacción, es decir cuando se presionecualquier botón del form (“Get”, “Apply Changes”, botones de navegación, botón Select o cualquierbotón con un evento de usuario asociado).

Notas generales:

En el evento Start fundamentalmente se trabaja con variables. En cuanto a utilizar atributos en esteevento, ya sea para evaluarlos y/o usarlos de algún modo menos para actualizarlos, se debe tener encuenta que los únicos atributos que se tienen disponibles son los que se reciben por parámetroen la regla parm. Ningún otro atributo tendrá valor en este evento, pues todavía no se ha editadoninguna instancia de la transacción.



Evento Exit• Se ejecuta:

• Win: una sola vez, cuando se cierra la transacción entiempo de ejecución.

• Web: se ejecuta cada vez que se somete el form de latransacción al servidor. Por ello no suele utilizarse.

• Ejemplo: En Win, llamar a un procedimiento que graba la

fecha/hora de entrada y la fecha/hora de salida del programa,para cada usuario en una tabla de control.

SINTAXIS: Event Exitcódigo

Endevent

El evento Exit es un evento del sistema (por lo tanto ocurre automáticamente) y es lo último enejecutarse. ¿En qué momento se ejecuta? Otra vez, esto dependerá de la interfaz:

• En Win se ejecuta una sola vez cuando se cierra una transacción en tiempo de ejecución.• En Web, ocurre una única vez, al final de c/iteración (es lo último que se ejecuta).

Al igual que en el evento Start, en el evento Exit fundamentalmente se trabaja con variables.

En cuanto a utilizar atributos en este evento, ya sea para evaluarlos y/o usarlos de algún modo salvoactualizarlos, se debe tener en cuenta que los únicos atributos que se tienen disponibles sonlos que se reciben por parámetro en la regla parm. Ningún otro atributo tendrá valor en esteevento.

WINEJEMPLO: Cada vez que se cierre cierta transacción en tiempo de ejecución, invocaremos a unprocedimiento que grabe la fecha y hora de entrada a la transacción (que se capturó en el evento Start,en una variable &in) y la fecha y hora de salida de la misma, para cada usuario en una tabla de control:

Event Exit&user = userid()&out = now()PControlStore.call(&in, &out, &user)

Endevent

¿Cuál es la diferencia en Win entre definir código en el evento Exit o en cambio definir unaregla con evento de disparo on AfterLeve l Level atributo 1er nivel, siendo que ambas cosas sedispararían una única vez al cerrar l a transacción, una a continuación de la otra?Si se define una regla con el evento de disparo AfterLevel Level a t r i bu to 1e r n i v e l , la misma sedisparará una sola vez cuando el usuario cierre la transacción, existiendo la posibilidad de retorno. Esdecir, si fuera necesario, se podría definir una regla Error para mantener la pantalla abierta. El EventoExit en cambio, si bien ocurre también una vez sola al cerrar la transacción, ya no brinda la posibilidadde retorno. Cuando ocurre el Evento Exit, la pantalla ya se cerró.

WEBComo se dispara cada vez que se dibuja la pantalla, al final, no hace las veces de un verdadero exit, porlo que no suele utilizarse en este ambiente.



Eventos de Usuario

• Además de los eventos ofrecidos por GeneXus, el analista puededefinir eventos creados por él, llamados eventos de usuario.

• Cada evento de usuario luego se asocia a algún control del form delos que aceptan evento de usuario (depende de la interfaz):• En Win: botón y/o tecla de función.• En Web: botón, imagen o text block

SINTAXIS: Event ‘nombre de evento de usuario’ <Key>código

Endevent

tecla de función(solo para Win)

Web:

Orden deejecución

1. Evento Start

2. Lectura de atributos y variables del form3. Evento de usuario seleccionado4. Evento Exit

Como se puede observar en la sintaxis, se le debe dar un nombre a un evento de usuario, debiéndosedeclarar a continuación de la palabra Event, encerrado entre comillas simples.

EJEMPLO:Se desea que en la transacción "Invoice", el usuario tenga la posibilidad de imprimir la factura con la cualesté trabajando, presionando F7 (esto solo es válido para Win):

Event ‘Print Invoice’ 7 //evento definido en la transacción "Invoice"

RPrintInvoice.Call( InvoiceId )EndEvent

Win: ¿Cómo asociar un evento de usuario a una tecla de función o a un botón ?Como también se puede observar en la sintaxis, opcionalmente se puede especificar a continuación delnombre del evento, el número correspondiente a una tecla de función. Por ejemplo, si se quiere que elevento se ejecute cuando el usuario presione la tecla de función F6, habrá que poner a continuación delnombre del evento, el número: 6.

Para asociar el evento a un botón, se debe insertar un control botón en el form GUI-Windows, y acontinuación se abrirá automáticamente un diálogo con las propiedades del botón; allí se deberá seleccionarel evento de usuario definido.

Si se trata de un botón ya insertado en el form, sólo habrá que abrir el diálogo con las propiedades delbotón, y seleccionar allí, el evento de usuario definido.

Web: ¿Cómo asociar un evento de usuario a un control?En el caso de interfaz web, además de los botones, también las imágenes y los text blocks admiten laasociación de evento de usuario. Para realizar la asociación se debe insertar el control correspondiente en elform Web y luego en las propiedades del control, se deberá seleccionar donde dice OnClickEvent uno de loseventos existentes, o se puede crear uno nuevo.

Nota: se pueden ejecutar eventos asociados a botones con Alt+<letra>. Se logra colocando un ‘&’ en elCaption del botón, antes de la letra con la que se desea acceder al evento. (Tanto Win como Web)Ejemplo: si se desea que el código del evento de usuario asociado a un botón de caption “MyEvent” sepueda ejecutar también con Alt+E, entonces en el Caption del botón, tendremos que escribir “My&Event” yse verá en el form web (en diseño) con un infraguión antes de la letra correspondiente, mientras que enejecución no se percibirá nada:



Evento After Trn

• Ocurre inmediatamente después de la ejecución de las

reglas con evento de disparo AfterComplete.

• Sintaxis:

• Ejemplo: Event After trnReturn

EndEvent

Event After Trncódigo

Endevent

El evento After Trn de las transacciones ocurre inmediatamente después de la ejecución de las reglascon evento de disparo AfterComplete. Por consiguiente, el código que se incluya en este evento seejecutará luego de culminada cada iteración completa por medio de la transacción (es decir,luego de haberse grabado cada cabezal con sus correspondientes líneas como registrosfísicos en las tablas que corresponda y de haberse efectuado COMMIT).

Existen las siguientes alternativas para programar comportamientos que se deseen ejecutar luego decada iteración completa por medio de una transacción:

1. Definir reglas individuales con evento de disparo AfterComplete y dejar el evento After Trn sin código2. Definir todas las sentencias en el evento After Trn con estilo procedural, y no definir reglas conevento de disparo AfterComplete3. Definir ambas cosas: algunas reglas con evento de disparo AfterComplete y código en el evento AfterTrn

Como venimos explicando, primero se ejecutan las reglas definidas con evento de disparoAfterComplete, e inmediatamente después de las mismas se ejecuta el código definido en el eventoAfter Trn.

Un concepto que es muy importante tener claro es que tanto en reglas con evento de disparoAfterComplete como en el evento After Trn, se conocen los valores de los atributos del primer nivel dela transacción.

Es decir, si bien ya se grabaron físicamente los registros correspondientes al cabezal y las líneas decierta iteración completa, e incluso se efectuó COMMIT, aún se tienen disponibles los valores de losatributos del primer nivel, pudiendo estos utilizarse para pasarlos por parámetro en una invocación, oevaluar su valor, o usarlos de algún modo salvo actualizarlos 1.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

1 Hay dos motivos por los cuales no es posible actualizar atributos en reglas con evento de disparoAfterComplete ni en el evento After Trn. El primer motivo es que ya se han hecho las grabacionescorrespondientes e incluso se ha efectuado COMMIT, de modo que ya es tarde para asignar valores aatributos. Y además, en lo que respecta al evento After Trn, en los eventos no se permite realizarasignaciones a atributos.



Un detalle a tener en cuenta es que en el evento After Trn -como en todo evento- es posible incluir comandos, adiferencia de en la sección de reglas de una transacción, en la que no es posible.

EJEMPLOS:

1. Event After Trn

return /*el comando return hace que se abandone el programa y se vuelva al objeto llamador*/

EndEvent

Si en el evento After Trn de una transacción se incluye el comando return, al terminar de ejecutarse la primeraiteración completa, se ejecutará el evento After Trn y se cerrará el programa correspondiente a la transacción,volviendo al objeto llamador.

2. Event After Trn // Evento After Trn en la transacción "Invoice"

RPrintInvoice.Call( InvoiceId )

Msg(‘Recuérdele al cliente nuestra promoción XXX’)

Endevent

3. Se necesita controlar la cantidad de iteraciones completas realizadas por medio de una transacción Win durante unasesión. Para ello definiremos código en varios eventos, no sólo en el evento After Trn.

Event Start&veces = 0

EndEvent

Event After Trn

&veces += 1

EndEvent

Event Exit

Msg( ‘Se han realizado la siguiente cantidad de iteraciones completas: ’ + str( &veces ) )

EndEvent

Con este ejemplo logramos dejar bien en claro que el evento Start se ejecuta una sola vez en ambiente Win, ni bien se

abre una transacción en tiempo de ejecución, el evento Exit se ejecuta una sola vez cuando se cierra una transacción entiempo de ejecución (lo veremos a continuación), y el evento After Trn por su parte, se ejecuta una vez por cadaiteración completa culminada.

Si la misma transacción se generara en ambiente Web , el resultado sería absolutamente distinto: el mensaje siempremostraría 1, ya que el start y el exit se ejecutan en este caso por cada iteración.



REGLAS STAND-ALONEEVALUACION REGLAS Y FÓRMULAS SEGÚN ARBOL

AfterValidate / BeforeInsert / Update / DeleteGRABACION DEL CABEZAL

AfterInsert / Update / Delete

AfterValidate / BeforeInsert / Udpate / DeleteGRABACION DE LA LINEA

AfterInsert/Update/Delete

AfterLevel Level attNivel2 - BeforeComplete

AfterCompleteCOMMIT

VALIDACIÓN


PARA CADALINEA

Resumiendo, al confirmar los datos, se ejecutan en orden todo lo siguiente:

VALIDACIÓN

ABANDONAR NIVEL 2

BeforeValidate

BeforeValidate


START (lo primero en ejecutarse)

EXIT (lo último en ejecutarse) After TRN

Para completar el diagrama visto anteriormente, agregamos al comienzo la ejecución automática delcódigo asociado al evento START y al final la ejecución automática del código asociado al evento EXIT.Además, incluimos la ejecución del evento After TRN en el lugar que corresponde a su ejecución.



Consideraciones

• En los Eventos no se permite asignar valores alos atributos.

• Eventos Start y Exit: son sin tabla base.

• Eventos de usuario y After Trn: son con tablabase.

No se permite asignar valores a atributos en los eventos.

Los valores de los atributos pueden modificarse en las transacciones:• haciéndolo el usuario final, en tiempo de ejecución, a través del form (sólo atributos de las tablas basesasociadas a la transacción, o aquellos de la extendida permitidos por regla update)• mediante reglas definidas por el programador (atributos de las tablas bases asociadas a la transacción y susextendidas)

Solemos decir que los eventos Start y Exit son sin tabla base. Con esta expresión nos referimos a que enlos eventos Start y Exit no hay consulta activa a la base de datos (ya que en el evento Start aún no se hahecho la consulta y en el evento Exit en Win ya se está cerrando el programa asociado a la transacción y enWeb se está cerrando la instancia y ya no disponemos de la consulta). Por este motivo es que no se conocenvalores de atributos en los eventos Start y Exit, salvo los recibidos por parámetro.

Por el contrario solemos decir que los eventos After Trn y de usuario son con tabla base, ya que cuandolos mismos se ejecutan, sí hay una consulta en edición. Entonces, en particular en el evento After Trn, seconocen los valores de los atributos del primer nivel (el segundo nivel ya se ha iterado a esa altura y no hayposibilidad de posicionamiento en alguna línea en particular); y en lo que respecta a los eventos de usuariose disponen los atributos de todos los niveles 1.

Es fundamental comprender que así se disponga de los valores de ciertos atributos u otros dependiendo delevento, los mismos podrán utilizarse para ser evaluados y/o pasados por parámetro a objetos que seinvoquen, y/o para alguna otra operación cualquiera que no sea asignarles valor.

Concluyendo, en ningún evento (no sólo de transacciones, sino de ningún objeto GeneXus) se permite realizarasignaciones a atributos.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

1 Si en un evento de usuario se referencian atributos de un segundo nivel u otro nivel subordinado, cuandoel evento de usuario se ejecute se tendrán en cuenta los atributos de aquella línea en la que se estéposicionado; al momento de ejecutarse el evento de usuario se considerarán los valores de los atributos dedicha línea. Y si el usuario no se había posicionado explícitamente en determinada línea, por defecto la líneaque estará seleccionada será la primera, así que se considerarán los valores de los atributos de la misma.



INTEGRIDAD TRANSACCIONAL



¿Qué es el concepto: integridad transaccional?

Un conjunto de actualizaciones a la base de datos tieneintegridad transaccional cuando en caso de unafinalización “anormal”, la base de datos permanece enestado consistente.

Muchos manejadores de bases de datos (DBMSs) cuentan con sistemas de recuperación antefallos, que permiten dejar la base de datos en estado consistente cuando ocurren imprevistostales como apagones o caídas del sistema.



Una unidad de trabajo lógica (UTL) es un conjuntode operaciones a la base de datos, que debenejecutarse o bien todas o bien ninguna de ellas.

¿Qué es el concepto: unidad de trabajo lógica

(UTL)?

Los manejadores de bases de datos (DBMSs) que ofrecen integridad transaccional permitenestablecer unidades de trabajo lógicas (UTLs), que corresponden ni más ni menos que alconcepto de transacciones de base de datos.



¿Qué es efectuar COMMIT?

• El comando COMMIT permite especificar que cierto conjunto de operacionesrealizadas sobre una base de datos, ha culminado de efectuarsecorrectamente:

...........Operación sobre Base de DatosOperación sobre Base de DatosFinaliza UTLComienza UTLOperación sobre Base de DatosOperación sobre Base de DatosOperación sobre Base de DatosOperación sobre Base de DatosFinaliza UTL

• De modo que efectuar COMMIT en una base de datos, significa que se da porfinalizada una unidad de trabajo lógica (UTL).

COMMIT

COMMIT

Podemos ver que una unidad de trabajo lógica (UTL) queda definida por el conjunto deoperaciones entre un par de Commits.



¿Qué es efectuar ROLLBACK?

• Hacer ROLLBACK (vuelta a atrás) provoca que se deshagantodas las operaciones efectuadas en la base de datos que nohayan quedado con COMMIT.

• Esto se resuelve deshaciendo todas las operaciones posterioresal último COMMIT.



Unidades de trabajo lógicas (UTLs)por defecto en GeneXus

Todo objeto GeneXus transacción y todo objeto GeneXusprocedimiento, determina unidades de trabajo lógicas (UTL).

Es decir, las transacciones y procedimientos son los únicos objetosGeneXus (*) que permiten actualizar la base de datos, y pordefecto GeneXus incluye en los programas generados asociados alos mismos, la sentencia COMMIT.

En el objeto procedimiento GeneXus incluye un COMMITautomático al final del Source.

En el objeto transacción GeneXus incluye un COMMIT automático alfinal de cada instancia, inmediatamente antes de las reglas conevento de disparo AfterComplete

(*) una excepción la brindan los Business Components, pero no realizan commit automáticamente.

Es importante aclarar que GeneXus incluye la sentencia COMMIT en los programas generados asociados atransacciones y procedimientos, sólo en ambientes de trabajo Cliente/Servidor (incluyendo, por tanto, losambientes Web). El motivo de esto es que en ambientes Cliente/Servidor existe un DBMS que asegura laintegridad transaccional, por lo tanto GeneXus efectúa la tarea de definir las unidades de trabajo lógicas(UTLs). En cambio, en ambientes de trabajo que no son Cliente/Servidor, GeneXus no incluye sentenciasCOMMIT pues no hay un DBMS por detrás que maneje la integridad transaccional.

¿Dónde incluye GeneXus COMMIT exactamente?

En cada procedimiento: al final del programa fuente.

En cada transacción: inmediatamente antes de las reglas con evento de disparo AfterComplete. Es decir,que por cada iteración completa que se efectúe en tiempo de ejecución por medio de la transacción, habráun COMMIT, justo antes de las reglas con evento de disparo AfterComplete.

Nota: El nuevo tipo de datos Business Component que veremos más adelante permite actualizar la basede datos desde cualquier objeto GeneXus, pero también como veremos, no realiza automáticamente unCOMMIT.



• Propiedad Commit on Exit de transacciones yprocedimientos:

Valores:

• Y e s ( D e fa u l t ) : Se ejecuta COMMIT

• N o : No se ejecuta COMMIT

Personalización de unidades de trabajo lógicas

(UTLs) por defecto en GeneXus

GeneXus ofrece una propiedad a nivel de cada objeto transacción y procedimiento, para definirsi se desea que su programa generado efectúe COMMIT, o no. El nombre de la propiedad esCommit on Exit y su valor por defecto es Yes (por eso, toda transacción y procedimiento pordefecto efectúa COMMIT).

Si se desea que cierta transacción o procedimiento no tenga en su programa generado COMMIT,

bastará con cambiar el valor de la propiedad Commit on Exit a No.



Trn. “X”

Commit on Exit = No

Proc. “Y”

• Ejemplo de uso de Commit on Exit = No

call

Es muy importante invocar desde la Trn. “X” al Proc. ”Y” utilizandoun evento de disparo que consideremos adecuado y que ocurraantes de la ejecución del COMMIT de la Trn “X” .

Commit on Exit = Yes

Personalización de unidades de trabajo lógicas

(UTLs) por defecto en GeneXus

¿Por qué motivo se puede necesitar no efectuar COMMIT en una transacción oprocedimiento?

Para personalizar una unidad de trabajo lógica (UTL). Es decir, podemos necesitar ampliar unaunidad de trabajo lógica (UTL) para que varias transacciones1 y/o procedimientos, conformen unaúnica unidad de trabajo lógica (UTL).

Ejemplo (mostrado arriba):

La transacción “X” invoca al procedimiento “Y”, y se desea que ambos objetos conformen una únicaUTL. La transacción actualiza ciertos registros, y el procedimiento otros, y se desea que ese conjuntototal de operaciones conforme una única UTL (para asegurarnos de que si ocurre una falla, quedeefectuado el conjunto completo de actualizaciones a la base de datos, o nada).

Para lograrlo podemos eliminar el COMMIT del procedimiento y dejar que se realice en la transacción(al retornar del procedimiento a la transacción, para que se ejecute al final de todas lasoperaciones); de modo que configuraríamos la propiedad Commit on Exit del procedimiento convalor: No y dejaríamos la propiedad Commit on Exit de la transacción con el valor por defecto:Yes . Pero además de esto, es fundamental que la invocación al procedimiento se realice antes deque se ejecute el COMMIT en la transacción (ya que la idea es que ambos objetos conformenuna única UTL, y para ello el COMMIT debe efectuarse en la transacción al retornar delprocedimiento); así que la invocación al procedimiento deberá definirse en la transacción, con unevento de disparo que ocurra antes de la ejecución del COMMIT (dependiendo de si la transacción esde un nivel o más, y de los requerimientos, podría servir AfterInsert por ejemplo, AfterUpdate, oAfterLevel Level Atributo del 2do nivel, o BeforeComplete, pero no AfterComplete).

No existe una única solución para personalizar una UTL. Lo fundamental es analizar cuál objetopuede hacer COMMIT (pudiendo haber más de una posibilidad) y una vez que se decida cuál objetoefectuará COMMIT, las invocaciones que se requieran hacer, deberán efectuarse en momentosadecuados, considerando si ya se efectuó el COMMIT o no.

-----------------------------------------------------------------------------------------------------------1 En ambiente Web existe una importante restricción a este respecto: si desde una transacción seinvoca a otra, el Commit que realice una no aplica sobre los registrosingresados/modificados/eliminados por la otra. Es decir, el Commit de cada transacción solo tiene

“visibilidad” sobre los registros operados por esa transacción, y no por la otra, por lo que dostransacciones distintas no pueden quedar incluidas en una misma UTL. No puede realizarsepersonalización en este caso, al contrario de lo que sucede con los procedimientos, donde elcomportamiento es idéntico al de ambiente Win.



Por ejemplo, para que la transacción y procedimiento vistos conformen una única UTL, podríamos haber optadotambién por la alternativa de que no efectúe COMMIT la transacción (Commit on Exit = No), sino que lo hagael procedimiento al final de todo; y de hacerlo así, no sería un error –como sí lo sería en la solución anterior-invocar al procedimiento utilizando el evento de disparo AfterCompete, porque la transacción no hará COMMIT,sino que lo hará el procedimiento.

Concluyendo, es cuestión de decidir cuál objeto hará COMMIT y que las invocaciones que se deban hacer, sehagan en momentos adecuados, para que la UTL personalizada quede bien definida.

Otro ejemplo:

Sea la transacción “Invoice” estudiada hasta el momento, en un modelo de Prototipo cliente/servidor.Supongamos que no modificamos el valor predeterminado de la propiedad Commit on Exit.

Supongamos ahora que el usuario ejecuta la transacción, ingresando la factura 1 con todas sus líneas. Luegopasa a ingresar la factura 2 y cuando está ingresando la 3era. línea de la misma, ocurre un apagón. Alrecuperarse la energía y reiniciarse la ejecución, ¿qué registros habrán quedado grabados en las tablas ycuáles se habrán perdido?

La factura 1 íntegra estará grabada (cabezal y sus líneas). ¿Por qué? Pues porque al terminar de ingresarla ypasar a ingresar la factura 2, se efectuó un Commit. La factura 2 con los registros que se habían grabado hastael momento de la falla de energía, se habrá perdido. ¿Por qué? Pues porque la transacción realiza el rollback detodo lo que se hubiere efectuado luego del último Commit. El cabezal de la factura 2 y las 2 líneas que sehabían ingresado no estaban “commiteadas” aún.

Observar entonces que el Commit no es por transacción entera (es decir, todas las iteraciones del cabezal ysus líneas) sino por cada instancia de cabezal + líneas.

Si el Commit se realizara una única vez antes de cerrar la transacción, entonces si se hubieran ingresado 29facturas y a la trigésima se cayera el sistema, se perderían las 29 facturas anteriores (se desharía todo, ya queaún no se habría alcanzado el Commit). Esto no es así, y si ocurriera una caída del sistema a la trigésimafactura ingresada, las 29 anteriores quedarán grabadas (no así la trigésima).



Trn.“X”

• No puede definirse una UTL compuesta por varias transacciones Web.

call

Personalización de UTLsen ambiente Web

• Una transacción Web solo puede Commitear los registros insertados por ellamisma, o por procedimientos en una cadena de invocaciones, pero no puedeCommitear los registros insertados por otra transacción.

Trn.”Y”

Trn.“X”

call

(luego del

Commit)

Trn.”Y” Proc.”Z”

call

(antes del

Commit)

UTL

No pueden quedar dentrode una misma UTL

UTL 1 UTL 2

En ambiente Web los registros “visibles” para ser commiteados por una transacción son losactualizados por la propia transacción, y por los procedimientos que ésta invoque antes de suCommit, pero no los de otra transacción.

Cada transacción trabaja, así, sobre UTLs distintas.

Es por ello que en el primer ejemplo presentado arriba, donde la transacción “X” llama a la

transacción “Y” luego de haber insertado un registro, aunque la transacción “Y” realice un Commit alfinal de que cabezal y líneas sean ingresados, este Commit no valdrá sobre el registro que habíasido ingresado previamente por la transacción “X”. Este registro quedará “perdido”, sin Commit.

Por la forma de trabajo en Internet, las transacciones Web “viven” solamente el tiempo entre que elusuario de un navegador selecciona el link o presiona un botón y la nueva página es mostrada.Toda modificación a la base de datos que se haga durante la “vida” de la transacción debe serconfirmada o eliminada antes de que la Transacción Web termine su ejecución y retorne la páginaresultante.

Como consecuencia, una Transacción Web inicia una UTL (unidad de trabajo lógica) al comenzar aejecutar y la cierra (ya sea por COMMIT o ROLLBACK) antes de terminar. No puede formar parte deotra UTL. Si un programa llama a una Transacción Web, ésta iniciará otra (nueva) UTL.

En cambio no sucede lo mismo con los procedimientos. En el segundo ejemplo mostrado arriba,vemos que podemos formar una UTL que engloba a la transacción “Y” y al procedimiento “Z”… sinembargo no podemos incluir a la transacción “X” en la misma UTL.



• Si deseamos que las inserciones mediante dos transacciones distintas

conformen una única UTL:

Tenemos una solución: utilizar Business Components y el comando Commit alterminar de insertar mediante las variables Business Components los registrosasociados a ambas transacciones (se verá más adelante).

Personalización de (UTLs)

Trn.“X” Trn.”Y”

Si se necesita que las operaciones de dos o más transacciones (con o sin procedimientos incluidos)conformen una misma UTL, se pueden emular las transacciones con Web panels y BusinessComponents y utilizar el comando Commit.

Dejamos aquí anotado simplemente el tema, para volver a él luego de estudiados los BusinessComponents, donde nos será posible comprender esta solución.



• GeneXus ofrece los comandos: COMMIT y ROLLBACK

• Se pueden incluir en Procedimientos, Work y Web Panels, así como en combinación con Business Components.

• Ejemplo (usuario final decide si ejecutar Commit o Rollback):Se invoca desde una transacción a varios procedimientosconsecutivos, se les configura a todos ellos la propiedadCommit on exit = No… y en el último procedimiento se lepregunta al usuario si confirma; dependiendo de la respuestadel usuario, habrá que ejecutar el comando COMMIT oROLLBACK

Comandos COMMIT y ROLLBACK de GeneXus



OBJETOS REPORTEy PROCEDIMIENTO



Reportes y Procedimientos

Reportes

• Procesos no interactivos de consulta de la base dedatos.

Procedimientos

• Procesos no interactivos de consulta y actualizaciónde la base de datos.

Reportes:Definen procesos no interactivos de consulta a la base de datos. Los reportes son listados quepueden (dependiendo de la interfaz win o web) emitirse por impresora, visualizarse por pantalla, ograbarse en un archivo.

Procedimientos:Definen procesos no interactivos de actualización de la base de datos. Los procedimientos pueden

hacer todo lo que los reportes hacen y además actualizar la base de datos1

. Por este motivo, todo loque se trate en la presente exposición referido al objeto reporte, será también válido para el objetoprocedimiento.

----------------------------------------------------------------------------------------------------------1 Como veremos más adelante, existe un tipo de datos especial, que no es estrictamente un tipo dedatos, sino algo un poco más complejo, el business component, por medio del cuál se podránrealizar actualizaciones a la base de datos en cualquier objeto GeneXus. Por tanto, utilizandovariables de tipo de datos business component, podrán realizarse actualizaciones incluso en losobjetos que por naturaleza no ofrecen esta posibilidad, como los reportes.



Características

• Definición procedural

• Definición sobre la base de conocimiento

• Independencia de la base de datos:definición a nivel de atributos

Definición procedural

A diferencia de las reglas de las transacciones donde las especificaciones se realizan en formadeclarativa y GeneXus determina en el momento de generar el programa la secuencia de ejecución,en los reportes y procedimientos las especificaciones se realizan en forma procedural. De esta forma,la secuencia de ejecución es determinada por el analista, utilizando para ello un lenguaje bastantesimple que contiene comandos de control, de impresión, de acceso a la base de datos, etc.

Definición sobre la base de conocimiento

La gran potencia del lenguaje de reportes y procedimientos radica en que las definiciones se hacensobre la base de conocimiento y no directamente sobre el modelo f í sico (tablas, í ndices, etc.). Estonos permite utilizar automáticamente todo el conocimiento ya incorporado o generado por GeneXus apartir de las especificaciones realizadas.

Por ejemplo, si deseamos desplegar el resultado de una f órmula alcanza con nombrar al atributof órmula en el lugar adecuado y GeneXus disparará su cálculo desplegando el resultado, sin necesidadde que el analista tenga que brindar ninguna otra información. La información de cómo se calcula unatributo f órmula está contenida en la base de conocimiento.

También podremos utilizar el concepto de tabla extendida, ya que GeneXus conoce las relacionesentre las tablas de la base de datos, por lo que el analista no necesita explicitar estas relaciones a lahora de recuperar datos.

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: no es necesario indicarexplí citamente cuáles tablas serán recorridas ni mediante qué í ndices. Con solo mencionar losatributos a los que se desea acceder es suficiente para que GeneXus determine esta información. Estoes posible porque GeneXus tiene un completo conocimiento de la estructura de la base de datos.

De esta manera logramos una real independencia de la base de datos, ya que cualquier cambio en lastablas será manejado automáticamente por GeneXus y de esta forma, para actualizar los programasalcanzará, gran parte de las veces, con regenerar los objetos sin tener que modificar nada de loprogramado en ellos.



Elementos

• Layout• Source• Reglas y Propiedades• Condiciones• Ayuda• Documentación

Como en las transacciones, pueden definirsevariables que serán locales al objeto.

Para cada reporte (procedimiento) se puede definir:

• Layout: Así como las transacciones tienen una pantalla (form), los reportes tienen un “layout” dela salida. En esta sección se define la presentación del reporte: los datos que se quieren listar y elformato de la salida.

• Source: Aquí se escribe el código correspondiente a la lógica del reporte. También pueden

definirse al final del código subrutinas1

que podrán ser invocadas desde el propio código mediante elcomando adecuado.

• Reglas-Propiedades : Definen aspectos generales del reporte, como su nombre, descripción, tipode salida (impresora, archivo, pantalla), parámetros que recibe el objeto, etc.

• Condiciones: Condiciones que deben cumplir los datos para ser recuperados (filtros).

• Ayuda: Permite la inclusión de texto de ayuda, para ser consultado por los usuarios en tiempo deejecución, para el uso del reporte. Se puede redactar una ayuda para cada lenguaje.

• Documentación: Permite la inclusión de texto técnico, para ser utilizado como documentación delsistema.

---------------------------------------------------------------------------------------------------1 No se tratarán en el presente curso. Véase Curso No Presencial de GeneXus.



área con datos fijos

área con datos fijos

área con datosvariables(acceso a labase de datos)

Ejemplo

• Queremos implementar un listado como el que

sigue:

Por ejemplo, supongamos que queremos implementar un reporte para imprimir el identificador,nombre y paí s de todos nuestros clientes y queremos que el listado luzca como se muestra en lafigura.

Para ello, debemos identificar en la salida del listado las distintas áreas que lo componen. A cadauna de ellas la representaremos con un print block.

Los primeros dos print blocks lucirán en GeneXus tal cuál las primeras dos áreas señaladas pueséstas contienen únicamente textos, lí neas, recuadros. También podrí amos haber fusionado estas dosáreas convirtiéndolas en una y utilizando por tanto un único print block.

El tercer print block será el correspondiente al área de datos variables de la figura anterior, querepresenta información que debe ser extraí da de la base de datos.Lo que queremos mostrar en este caso es el identificador y nombre de cada cliente, junto con elnombre del paí s al que pertenece. Esta información es la representada por los atributos CustomerId,CustomerName y CountryName de la base de conocimiento de la aplicación, por lo que el tercerprint block contendrá los tres controles atributo CustomerId, CustomerName y CountryName.

Transformando las áreas en print blocks, el Layout del reporte nos quedará como el que figura en lapágina siguiente.



print block

Layout: ejemplo

Layout:•Sucesión de print blocks•No importa el orden de definición•Cada print block debe tener un nombre único

•Solo se declaran, son invocados desde el Source con elcomando “print” (Ej.: print header)

Nombre de cada print block

El Layout de un reporte será una sucesión de print blocks que no tienen por qué seguir el orden enel que se desea que aparezcan en la salida.

En el ejemplo anterior, el mismo reporte habría sido impreso si se hubieran especificado los printblocks en el orden inverso (o en cualquier orden).

Aquí simplemente se declaran. El orden en el que se ejecutan queda determinado en la sección

Source que es la que contiene la lógica del reporte. Desde allí serán invocados mediante un comandoespecífico para tal fin (el comando print).

Por esta razón, cada print block deberá tener un nombre único para poder ser referenciado luegodesde el Source.

En el ejemplo, para listar todos los clientes, el print block de nombre “customer” deberá ser invocadodentro de una estructura repetitiva en el Source. Esta estructura repetitiva es el comando For eachque estudiaremos luego.



• Para definir los print blocks tenemos lossiguientes controles disponibles:

• Texto• Lí nea• Recuadro• Atributo/Variable• Bitmap

y para insertar un print block en el Layout aparece el control “print block”

Layout: print block

El print block es un tipo de control válido solamente en reportes y procedimientos, que es insertadoy eliminado del Layout por el analista, y que contendrá otros controles -atributos, textos, recuadros,lí neas, etc.-, siendo estos últimos los que efectivamente especifican qué es lo que se quieredesplegar en la salida.

Para insertar los controles en el Form de una transacción contábamos con una toolbar. La mismatoolbar se utiliza para insertar los controles en el Layout. De hecho esta toolbar está disponible para

todos los objetos GeneXus que se creen, y en cada caso tendrá habilitados los controles disponiblessegún el tipo de objeto y la interfaz (Win o Web).

Para los reportes (y procedimientos) se habilita el ícono correspondiente al print block para poderinsertar este tipo de control en el Layout.

Como todo control, el print block tiene propiedades que pueden ser configuradas por el usuario. Enparticular, tiene la propiedad “Name”, muy importante dado que es el identificador del print block.Con este identificador es que el print block puede ser invocado desde el Source para ser impreso.



Source

• Define la lógica del reporte• Programación procedural

• Lenguaje muy simple• Comandos usuales de control

• If, Do-case, Do-while, For

• Comandos de impresión• Print, Header, Footer, etc.

• Comando de acceso a la base de datos y de actualización• For each – new - delete

• Comandos para salir de un bucle, abandonar el programa,invocar a otro objeto, invocar a una subrutina, etc.

• Exit, Return, Call, Do, etc.

En esta sección se define la lógica del reporte (o procedimiento).

El lenguaje que se utiliza para programar el código fuente de los reportes y procedimientos es muysimple, y consta de algunos comandos que iremos viendo.

El estilo de programación es procedural –imperativo– por lo que el Source será una sucesión decomandos para los que el orden es fundamental: el orden en el que estén especificados

corresponderá, salvo excepciones, al orden en el que serán ejecutados.Existen, como en todo lenguaje imperativo, comandos de control para la ejecución condicional (if,do case), la repetitiva (do while, for), para invocar a otro objeto (call), para cortar las iteracionesdentro de un bucle (exit) o abandonar el programa (return), así como también comandosespecíficos de este lenguaje: para imprimir un print block del Layout (print), para acceder a la basede datos (for each), para insertar nuevos registros en una tabla (new: solo en procedimientos),para invocar a una subrutina (do), etc.

Al final de la sucesión de comandos que constituye el código general o principal del reporte, puedendefinirse subrutinas que podrán ser invocadas (mediante el comando do) desde el código general.No pueden ser invocadas desde otro objeto (son locales).

Por su importancia, empezaremos estudiando en profundidad el comando de acceso a la base dedatos, fundamental a la hora de recuperar la información almacenada. Luego se trataránbrevemente los comandos de control, que son comunes a todos los lenguajes de programación

imperativa, los comandos de asignación y los de impresión.



Comando for each

• Se utiliza para acceder a la información de la basede datos.

• Con un for each se recorre una tabla de la base dedatos: la tabla base del for each.

• Para cada registro de esa tabla, se quiere haceralgo con la información asociada.

(Ejemplo: imprimirla)

La definición del acceso a la base de datos para recuperación de información se realiza con un únicocomando: el comando for each1.

Usando el for each se define la información a la que se va a acceder. La forma de hacerlo se basa ennombrar los atributos a utilizar.

Así, con este comando se definen qué atributos se necesitan y en qué orden se van a recuperar, y

GeneXus se encarga de encontrar cómo hacerlo. No se especifica de qué tablas se deben obtener, niqué índices se deben utilizar para acceder a esas tablas: eso lo inferirá GeneXus. Evidentemente estono siempre es posible, y en tales casos GeneXus da una serie de mensajes de error indicando por quéno se pueden relacionar los atributos involucrados.

La razón por la cuál no se hace referencia al modelo físico de datos es porque de esta manera laespecificación del reporte es del más alto nivel posible, de tal forma que ante cambios en laestructura de la base de datos la especificación del mismo se mantenga válida la mayor parte de lasveces.

Cuando aparece un for each se está indicando que se quiere recuperar información de la base dedatos. Concretamente GeneXus sabe que con un for each se quiere recorrer (o navegar) unatabla. Para cada registro de esa tabla, se quiere hacer algo con la información asociada (ej:imprimirla).

Por lo tanto, todo comando for each tendrá una tabla física asociada: la tabla que será recorrida o

navegada. A esta tabla la llamaremos tabla base del for each.

------------------------------------------------------------------------------------------------------------1 Cuando estudiemos los business components veremos que utilizando su método Load también seconsigue consultar la base de datos.



Comando for each

• Ejemplo: Listado de clientes

• Layout:

• Source:

CUSTOMER COUNTRY

for each

print customerendfor

Intuitivamente resulta claro que con este comando estamos queriendo listar identificador, nombre ypaís de cada uno de los clientes de la base de datos. Es decir, queremos que se recorra la tablaCUSTOMER, y para cada cliente se recupere de la tabla COUNTRY el nombre del país al quepertenece, imprimiendo esta información, junto con el identificador y nombre del cliente. (Observarque la tabla COUNTRY pertenece a la extendida de CUSTOMER)

¿Cómo infiere esto GeneXus si todo lo que hicimos en el for each del ejemplo fue nombrar los

atributos que nos interesaba mostrar?



• Tabla que se recorre: CUSTOMER• Tabla que se accede para cada cliente: COUNTRY

INTERPRETACIÓN

For each record in table CUSTOMER

Find the corresponding CountryName in table COUNTRY


Comando for each

CUSTOMER COUNTRY

Dentro de todo for each se navega -recorre o itera- la tabla base, pero puede accederse a lastablas que constituyen su tabla extendida para recuperar información, que por pertenecer a laextendida estará unívocamente relacionada con cada registro de la tabla base con el que se estétrabajando en cada iteración (el concepto de tabla extendida es muy importante en este comando ysugerimos repasar su definición).

Es por ello que en el for each del ejemplo, la tabla base será CUSTOMER, y además se accederá

“para cada” cliente, no solo a los datos de su registro, sino a los del registro asociado en la tablaCOUNTRY (que está en la extendida de CUSTOMER). Decimos entonces que se recorre CUSTOMERy se accede además a COUNTRY para buscar el resto de la información requerida.

Como podemos ver claramente en el ejemplo presentado, no le damos explícitamente a GeneXusesta información. No es necesario, ya que GeneXus conoce las relaciones entre las tablas, y en basea los atributos mencionados dentro del for each, puede encontrar sin necesidad de másinformación una tabla extendida que los contenga.

La tabla base de esa extendida es la que elige como tabla base del for each.



• El acceso a la base de datos queda determinadopor los atributos que son utilizados dentro delcomando for each.

• Para ese conjunto de atributos, GeneXus buscarála mínima tabla extendida que los contenga.

• Su tabla base será la tabla base del for each.

Comando for each: determinación tabla base

A la tabla base correspondiente a esa tabla extendida la llamaremos tabla base del for eachy será recorrida en forma secuencial, ejecutando para cada registro lo que se indique en loscomandos internos al for each.



Comando for each: determinación tabla base

{CustomerId, CustomerName,CountryName} ⊂ ext(CUSTOMER)

{CustomerId, CustomerName,CountryName} ⊂ ext(INVOICE)

Pero:ext(CUSTOMER) < ext(INVOICE)

ext(CUSTOMER) es la mínima tablaextendida que contiene a los atributosdel for each.

Tabla base: CUSTOMER

Para el ejemplo presentado en el que se quieren listar de cada uno de los clientes su identificador,nombre y nombre de paí s, si observamos los atributos utilizados dentro del for each, vemos queellos son los contenidos en el print block de nombre “customer” : CustomerId, CustomerName yCountryName.

¿En qué tablas están estos atributos?

• CustomerId está en 2 tablas:- CUSTOMER como clave primaria (PK).

- INVOICE como clave foránea (FK).

• CustomerName está solo en CUSTOMER (es un atributo secundario).

• CountryName está solo en COUNTRY (es un atributo secundario).

GeneXus conoce las relaciones entre las tablas. Podemos ver el diagrama de Bachmancorrespondiente a las tablas en las cuales aparecen los atributos del for each (Tools/Diagrams).

Aquí puede verse claramente el por qué del requerimiento de que la tabla extendida sea la m í nima(entendiendo por mí nima aquella que involucra menor cantidad de tablas). La tabla extendida deINVOICE también contiene a todos los atributos del for each, pero no es mí nima, pues la deCUSTOMER también los contiene.

Por lo tanto, se va a recorrer secuencialmente la tabla CUSTOMER, y para cada registro de esatabla, se va a acceder a la tabla COUNTRY, para recuperar el registro de la misma que cumpla:COUNTRY.CountryId = CUSTOMER.CountryId y para el mismo se va a recuperar el valor del atributoCountryName, para poder imprimirlo, junto con el código y nombre del cliente.



Listado de navegación

tabla base

tabla base: la que se navega

Se accede para recuperar inforelacionada (CountryName)

Se resuelve la consulta ordenadapor la PK de la tabla base


GeneXus ofrece para todos sus objetos un listado conocido como listado de navegación, que es elresultado de la especificación del objeto. Este listado es muy útil para los reportes, ya que indicacuáles son las tablas que se están accediendo en cada for each del Source, si existe un índice pararecuperar los datos de la tabla base, y en caso de que así sea cuál es ese índice (su nombre), si seaplican filtros sobre los datos o se van a listar todos, etc.

De esta manera, el analista no tiene que ejecutar el objeto para verificar que la lógica sea laesperada. Con estudiar el listado de navegación ya tiene la información necesaria para saber si seestá recorriendo la tabla esperada, si se están aplicando correctamente los filtros deseados, etc.

Como puede verse en el listado correspondiente al reporte del ejemplo, muestra para el comandofor each del Source, cuál es su tabla base, por qué orden se va a resolver esa consulta (será elorden en el que se imprimirán los resultados), si existe un índice que satisfaga ese orden cuál es sunombre, y además aparecen dos elementos más: los filtros de navegación y el diagrama de tablas.

Los filtros de la navegación indican qué rango de la tabla base se va a a recorrer. En el ejemplose va a recorrer toda la tabla base del for each: empezando por el primer registro de CUSTOMER, yhasta que se alcance el fin de tabla (utilizando el índice ICUSTOMER).

El diagramita de tablas muestra la tabla base del for each con su clave primaria, e indentadastodas las tablas de la extendida que deban accederse para recuperar información asociada al

registro de la tabla base con el que se esté trabajando en cada iteración del for each.En el comando for each del ejemplo no aparece explícitamente ninguna información respecto alorden en el que queremos que se imprima la información. En este caso GeneXus elige como ordenla clave primaria de la tabla base del for each. Es por esta razón que para el for each delejemplo GeneXus determinó que el orden será el correspondiente al atributo CustomerId, claveprimaria de la tabla CUSTOMER.



For each: cláusulas Where

• Permiten establecer filtros sobre los datos a recuperar

• Ejemplo:

• Solo para los registros que cumplan las condiciones booleanas de lascláusulas where deben ejecutarse los comandos internos al for each.

• Las cláusulas where aplican siempre y cuando se satisfagan las

condiciones de sus cláusulas when (solo válidas para arquitecturacliente/servidor).

for eachwhere CustomerName >= &Start when not &Start.IsEmpty()where CustomerName <= &End when not &End.IsEmpty()


Para restringir los datos que se quieren listar en un for each se utilizan las cláusulas where delcomando.

Si en el listado de clientes no queremos listar todos los clientes, sino solo aquellos cuyo nombreesté dentro de un rango ingresado por el usuario, entonces debemos agregar al for each quehabíamos visto una clálusula where, para especificar los filtros deseados sobre los datos:

for each

where (CustomerName >= &Start) and (CustomerName <= &End)print customerendfor

donde las variables &Start y &End deben definirse en el reporte con el mismo tipo de datos queCustomerName, y cargarse con valores fijos ó recibidos por parámetro1.

Con la cláusula w here definida le estamos diciendo a GeneXus que no queremos quedarnos contodos los registros de la tabla base, sino solo con aquellos para los que se satisfaga la condiciónbooleana de la cláusula.

En el ejemplo escribimos una sola cláusula where con una condición compuesta, pero podríamoshaber programado lo mismo con dos cláusulas where, como se muestra arriba en la transparencia.

Es decir, cuando aparecen varios “where” la condición de filtro que se va a aplicar sobre los datos esla conjunción booleana de todas las condiciones de los “where” que aparezcan.

Observemos que en la transparencia las cláusulas where están a su vez condicionadas conclaúsulas when. Esto se lee de la siguiente forma: se aplicará el filtro establecido por el wheresolo cuando se satisfaga la condición del when.En el ejemplo, solo se aplicará el primer filtro: “CustomerName >= &Start” si la variable &Start noestá vacía. Si está vacía, este filtro no se aplicará. Análogo es el caso de la segunda cláusula when.Observar que si &Start y &End están vacíos, no aplicará ninguna de las cláusulas where, y por tantose listarán todos los clientes (como si las cláusulas where no hubiesen sido escritas).

----------------------------------------------------------------------------------------------------------1 A través de un objeto que los pide al usuario, como un Work Panel para ambiente Win y un WebPanel para ambiente Web. En el caso de ambiente Win, también podrá utilizarse la función Ask parapedir datos al usuario en ejecución.



Cada condición booleana de un “where” puede estar compuesta de varias expresiones booleanasconcatenadas con los operadores lógicos and, or y not.

La cláusula when para condicionar la aplicación de una cláusula where solo puede utilizarse en arquitecturascliente/servidor. Si no es el caso, y deseamos que si el usuario no ingresa valores en las variables (las dejavacías), no se realicen los filtros sobre los datos, podemos hacer:

For each

where CustomerName >= &Start or &Start.IsEmpty()where CustomerName <= &End or &End.IsEmpty())print customer

Endfor

Un cliente será impreso si cumple con las condiciones de ambos “where”. Si la variable &Start es vacíaentonces todo registro cumplirá la condición del primer where, ya que es una condición compuesta por “or”,donde una de las subexpresiones da True, por lo que la expresión completa también dará True.

Lo mismo ocurre si la variable &End está vacía.

Por lo tanto, si ambas variables están vacías, todos los registros cumplirán con las condiciones de los “where”, y por lo tanto no se aplicará filtro alguno sobre los datos. Se listarán todos los clientes.

Ped ido de da tos a l us ua r i o de l r epo r te

Interfaz Win: GeneXus cuenta con la función estándar Ask, que se ejecuta antes de entrar al objeto y pideal usuario el ingreso de un valor.

Utilizaremos esta función para pedir al usuario los valores que cargaremos en las variables &Start y &Endpor medio del comando de asignación. En el Source del reporte escribimos:

&Start = Ask( ‘Ingrese nombre de cliente inicial:’ )&End = Ask( ‘Ingrese nombre de cliente final:’ )

Notas• No importa el lugar del Source donde se especifiquen estos comandos, dado que la función Ask seejecutará siempre al principio.

• Lo mismo puede programarse utilizando la regla de asignación, en lugar del comando de asignación, enlas Rules del reporte, en lugar de hacerlo en el Source.

Interfaz Web: El reporte no tendrá ningún tipo de interacción con el usuario, por lo que la función Ask notendrá efecto alguno. Por tanto si el reporte va a ejecutarse en el marco de una aplicación Web, deberán

pedirse estos valores al usuario en uno de los objetos diseñados específicamente para tal fin: esto es, elWeb Panel y luego invocar al reporte enviándole estos datos por parámetro. También podrá utilizar estasolución en un ambiente Win, utilizando el objeto análogo: el Work Panel1.

-----------------------------------------------------------------------------------------------------------1 Para ver cómo realizar esto, puede dirigirse al capítulo del objeto correspondiente (Web Panel o WorkPanel según corresponda), y estudiar el primer panel presentado, clasificado como panel de entrada.





Aparece un nuevo elemento en este listado que no estaba presente antes, cuando no teníamoscláusulas where: las constraints (restricciones).

¿Qué información nos brinda este listado de navegación?

• que la tabla base del for each seguirá siendo CUSTOMER• que se seguirá ordenando la consulta por CustomerId, utilizando el índice ICUSTOMERcorrespondiente

• que seguirá recorriendo toda la tabla CUSTOMER en busca de la información

•pero que para cada cliente evaluará si cumple con las restricciones que aparecen enumeradas(CustomerName>= &Start si &Start no está vacía y CustomerName<=&End si &End no está vacía)y solo en caso de que las cumpla, ejecutará para ese cliente los comandos que aparecen dentro delfor each. En este caso, imprimirá los valores de los atributos del print block “customer”:CustomerId, CustomerName, CountryName.

• que debe acceder a la tabla COUNTRY cuya clave primaria es CountryId para obtener algún dato(CountryName)



For each: cláusulas Where

• Atributos permitidos: los de la tabla extendida dela tabla base del for each

• Ejemplo:for eachwhere CountryName = ‘Uruguay’


Los atributos utilizados en las condiciones de filtro pueden ser cualesquiera de la tabla extendidadel for each.

En el ejemplo, si bien la tabla base del for each es CUSTOMER, estamos filtrando los datos arecuperar utilizando el atributo CountryName, que es de la tabla COUNTRY, perteneciente a laextendida de CUSTOMER.

En este ejemplo tampoco se explicita nada con respecto al orden, por lo cuál los datos apareceránordenados por la clave primaria de la tabla base, es decir, por identificador de cliente, CustomerId.



For each: cláusula Order

• Permite establecer el orden en el que se quieren

recuperar los datos.• Ejemplos:

• Para determinar orden descendente se deben colocarparéntesis rodeando a los atributos del orden.Ejemplo: order (CustomerName)

for each order CustomerNameprint customer

endfor

for eachorder CustomerName when not (&Start.IsEmpty() and&End.IsEmpty())


Si queremos realizar un listado de todos los clientes pero ordenado por nombre del cliente en lugarde por código, lo único que tenemos que hacer es modificar el comando for each agregando estainformación del orden.

Esto se logra utilizando la cláusula order del for each, como se muestra en el primer ejemplo.

Como no existe un índice definido en la tabla CUSTOMER por el atributo CustomerName, GeneXusindicará en el listado de navegación mediante una advertencia (“warning”) que no existe un

índice para satisfacer el orden , lo que podría ocasionar problemas de performance, dependiendode la plataforma de implementación elegida, de la cantidad de registros que deben ser leídos de latabla, etc.

En algunas plataformas, como VFP o iSeries (AS/400), si no existe índice para satisfacer el ordenespecificado se crea uno temporal cada vez que se ejecuta el reporte y se elimina al finalizar laejecución. Este tipo de índice es el que llamamos índice temporal.

En otras plataformas, como VB con Access o en ambientes cliente/servidor, si no existe índice parasatisfacer el orden, el for each se traduce en una consulta SQL (“select”) que es resuelta por elmotor del DBMS de la plataforma.

Al igual que en el caso de las cláusulas where, en plataformas cliente/servidor la cláusula orderpuede condicionarse, como se muestra en el segundo ejemplo.En caso de no cumplirse la condición del when, no aplicará ese orden y de no existir ordenincondicional (sin cláusula when) como en el ejemplo, el orden a utilizar será indefinido,significando esto que el orden resultante podrá variar de DBMS a DBMS e incluso entre ejecucionessucesivas.

Pueden especificarse varias cláusulas order condicionadas (con cláusula when) consecutivas encasos de arquitecturas cliente/servidor y una sin condición (la última de la lista). La primeracláusula order cuya condición del when se satisfaga, será la elegida y su orden el utilizado.

Cláusula Order None: cláusula que evita que GeneXus elija por defecto el orden de los atributosde la clave primaria de la tabla base y utilice un orden de navegación indefinido.La cláusula order none admite condición para aplicarse (when).




for each order CustomerNameprint customer

endfor


Cuando no existe índice que satisfaga el orden de un for each, como es el caso del ejemplo, elanalista GeneXus puede resolver crearlo (índice de usuario). En la mayoría de los casos el reporteserá bastante más eficiente de esta manera, pero se debe mantener un índice más (lo que implicamayor almacenamiento y mayor procesamiento para mantener actualizado el índice)

No es posible recomendar a priori cuál de las dos soluciones es la mejor (no índice vs índice deusuario), por lo tanto se debe estudiar, caso por caso, la solución particular teniendo en cuenta laplataforma de implementación y siendo fundamental la frecuencia con que se ejecutará el reporte.De cualquier manera, si al comienzo no se definió el índice de usuario y posteriormente se decidedefinirlo, alcanza con regenerar el reporte (sin modificar nada de lo programado en el mismo) yéste pasará a utilizarlo.

El listado de navegación anterior nos informa que:

• la tabla base del for each es CUSTOMER• y se recorrerá ordenada por CustomerName• no existe un índice definido para ese atributo• se recorrerá toda la tabla CUSTOMER con el orden especificado• no hay condiciones de filtro, por lo que para todos los registros de la tabla se ejecutarán loscomandos dentro del for each (en nuestro caso, el comando print).



For each: cláusula Order

• Atributos permitidos:

• los de la tabla extendida del for each, salvo quese trate de una plataforma centralizada.

• en plataforma centralizada solo pueden utilizarseatributos de la tabla base.

De tratarse de una plataforma centralizada (Visual Basic / Access o Visual Fox Pro / DBFs), alespecificar un reporte que contenga:

For each order CountryNamePrint customer

endfor

se desplegará en el listado de navegación un mensaje de error indicando que no es posible ordenarpor CountryName. El motivo es que la tabla base del for each es CUSTOMER, y CountryName nopertenece a la misma.

En cambio, si se está generando en una plataforma cliente/servidor, no habrá ningún problema conun reporte que contenga el comando anterior.



for each order Cu st om erNa m e

where Cu st om erNam e >= &Startwhere Cu st om erNam e <= &End


for each

where CustomerName >= &Startwhere CustomerName <= &End


OPTIMIZACIÓN: Orden compatiblecon los filtros

No se recorretodala tabla base:¡optimizado!

Se recorretodala tabla base

Hay que evaluar asiduidad de esta consulta, creacióndel índice, y su mantenimiento.

Si nos interesa filtrar los clientes de forma tal que sus nombres pertenezcan a un rango, en el primerejemplo, como no especificamos cláusula order GeneXus ordena por clave primaria, es decir, porCustomerId.

En este caso, el listado de navegación nos va a informar que se debe recorrer toda la tablaCUSTOMER, y para cada registro de la misma se debe evaluar si el registro cumple o no con lascondiciones (restricciones o “constraints”). En caso afirmativo, se imprimen para el mismo los datos

correspondientes.Si en lugar de ordenar los datos por CustomerId pedimos que se ordenen por CustomerName, comose presenta en el segundo ejemplo, la tabla base se recorre ordenada por CustomerName y como enlos filtros establecemos que queremos quedarnos solo con aquellos clientes cuyo nombre,CustomerName, esté en el rango determinado, entonces ¡ya no será necesario recorrer toda la tablabase para obtener los datos que cumplen con las condiciones!

Diremos que esta segunda consulta está optimizada en ese sentido. Tener en cuenta, sin embargo,que GeneXus no tiene creado un índice en forma automática por CustomerName, y aquí habrá queevaluar si conviene crear un índice de usuario (que debe ser mantenido por Genexus luego) o nocrear índice y que se cree un índice temporal en ejecución para resolver la consulta si el DBMS nopuede resolverlo de otra forma.

El listado de navegación nos informará si una consulta está o no optimizada, de acuerdo a sirecorrerá toda la tabla (desde “First Record” hasta “End of table”) o si recorrerá por el contrario un

rango más reducido.



Definición de la estrategia deacceso a las tablas

READREADREADREADREADREADREADREAD

READREADREADREADREADREADREADREAD

Begin of table Begin of table

End of table End of table

Start point

End point

1. Se define el orden en que se recorrerá la tabla.2. Se elige el punto de comienzo (Starting Point)3. Se elige la posición final (End Point).

4. Se leen secuencialmente los registros entre el puntoinicial y el punto final, seleccionando los registros quecumplen las condiciones y descartando los restantes.

Normalmente los programas procesan registros agrupando aquellos que tengan ciertascaracterísticas comunes, por ejemplo, todas las facturas de un determinado cliente, o las ventas deuna clase de artículos.

Estas características comunes se establecen a través de condiciones que determinan un filtro sobrelos registros. Tales condiciones se especifican en GeneXus de diversas formas, una de las cuales esel caso de las cláusulas where en un For each.

En el ejemplo que estamos viendo: de todos los clientes, quiero imprimir los datos de aquellos cuyonombre esté en un rango determinado.

El tiempo necesario para realizar el proceso con los registros que cumplen las condiciones determinael grado de "optimización" que tiene la estrategia de acceso elegida. Decimos que una estrategia deacceso está más "optimizada" que otra cuando es necesario un menor tiempo para leer todos losregistros que cumplen las condiciones establecidas.

La optimización consiste en posicionarse lo más cerca posible del primer registro del grupo quecumple las condiciones y desde allí leer secuencialmente hasta el último que las cumpla. Lo que seestablece, en definitiva, es un intervalo que cubre todos los registros que cumplen las condiciones,de manera tal que los que están fuera de ese intervalo ni se consideran, pues ya se sabe que nopodrán cumplir 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 quecumplirán la condición. Igualmente las lecturas se realizarán para todos los registros de esteintervalo, pero solamente se considerarán aquellos que cumplan con las condiciones.

Para definir una buena estrategia de acceso, GeneXus cuenta con una inteligencia razonable.

Se determinará, estableciendo (de acuerdo al orden en que deban considerarse los registros y a lascondiciones), una posición inicial y una posición final en el archivo, leyendo en forma secuencial eneste intervalo.



For each:cláusula Defined by

• No ofrece funcionalidad alguna en lo que respecta a los datos arecuperar.

• Se utiliza exclusivamente para dar un elemento más para ladeterminación de la tabla base del for each deseada.

• Ejemplo: for eachdefined by InvoiceDate


Mín. extendida que contiene a InvoiceDate, CustomerId,

CustomerName, CountryName:

ext(INVOICE) tabla base INVOICE

Puede darse el caso de que para un For each haya más de una tabla base cuya extendida contengaa los atributos del for each, siendo mínima. Ante esta ambigüedad, GeneXus escoge la “primera” deestas tablas extendidas mínimas.

Para resolver este tipo de ambigüedad surge la cláusula defined by, que permite nombrar atributosde la tabla base deseada, que no se utilizarán para devolver la consulta ordenada por esosatributos, ni para filtrar la información a recuperar, ni para ser desplegados en el listado (es decir,no tienen funcionalidad alguna con respecto a los datos a recuperar), sino solo para aportar más

información que permita determinar la tabla base del for each.En la cláusula Def ined by se debe hacer referencia a por lo menos un atributo de la tabla basedeseada.

De la misma manera, se puede (y se suele) utilizar para modificar la que sería la tabla base en casode no nombrarse ningún atributo más dentro del For each. Este es el caso del ejemplo presentado,en el que no queremos listar todos los clientes de la tabla CUSTOMER, sino por el contrario,queremos listar todos los clientes de las facturas. De no nombrarse dentro del For each algúnatributo de INVOICE, la tabla base sería CUSTOMER.

En la mayoría de los casos no es necesario utilizar esta cláusula. Sin embargo, para reportes más omenos complejos, aún cuando no exista problema de ambigüedad, se recomienda el uso delDef ined by porque mejora bastante el tiempo de especificación del reporte.Sin embargo, no puede aconsejarse un uso indiscriminado. La contra de utilizar esta cláusulacuando no es necesaria es que ata un poco más el código al diseño de las tablas.

Supóngase por ejemplo que no se tiene creada una tabla COUNTRY, y se tiene de cada cliente el

país al que pertenece, como atributo secundario. Si lo que queremos es listar los clientes y su país,serían equivalentes:

For each For eachDefined by CountryName

print customer print customerendfor endfor

donde customer es un print block con los atributos CustomerId, CustomerName y CountryName.Si ahora decide crearse la tabla COUNTRY y tener en la transacción “Customer” a CountryId comoFK, si bien el primer for each continuará siendo válido y haciendo lo que queremos, el segundodejará de funcionar, ya que en el Defined By no hay ningún atributo de la tabla base.



For each:cláusula Defined by

• Atributos permitidos: pueden aparecer variosatributos de la tabla extendida, pero al menos unodebe corresponder a la tabla base que se desea(en caso contrario dará un error)

Pueden aparecer varios atributos, para el posible caso en el que no alcance uno solo paradeterminar completamente la tabla base deseada, donde al menos uno de ellos deberá estarasociado a la tabla base deseada.

Se recomienda el uso en el Defined by de atributos secundarios de la tabla base que se deseanavegar, ya que como sabemos, los atributos secundarios solo pueden estar en una tabla delmodelo y de esta forma eliminamos por completo toda posible ambigüedad.

Esto sin embargo, no es obligatorio, es decir, pueden nombrarse en el Defined by atributosprimarios cuando se sepa que no habrá ambigüedad en la elección de la tabla base.

Un error común es creer que cuando un for each tiene esta cláusula, la tabla base del mismo quedadeterminada exclusivamente a partir de los atributos mencionados en el defined by.

La realidad es que los atributos del defined by arrojan una o más tablas base candidatas a ser latabla base del for each, pero luego hay que ver si tomando cada tabla base candidata, su extendidacontiene a todos los demás atributos del for each, además de los del defined by.

Si ninguna de las posibles tablas base candidatas cumplen esta condición, entonces el reporte daráun error al ser especificado, y no podrá ser generado (recordemos que debe cumplirse que todos losatributos del for each estén contenidos en una misma tabla extendida).



For each:cláusula When none

• Permite ejecutar determinado código cuando en un for eachno se encuentra ningún registro que cumpla las condiciones.

• Ejemplo:for eachwhere CustomerName >= &Startwhere CustomerName <= &End

print customerwhen none

print message

endfor

El print block message (que podrá contener un texto advirtiendo al usuario de que no existenclientes que cumplan los filtros) se ejecuta sólo cuando no se entra en el For each, es decir, cuandono hay ningún registro correspondiente a la tabla base del for each para el que se cumplan lascondiciones de filtro.

También se aplica a for each [selected] line, XFor Each y XFor First, comandos que veremos másadelante.

La cláusula when none debe ser la última dentro del For each. Las acciones a realizar cuando noexiste ningún registro para el que se cumplan las condiciones, quedan determinadas por el bloquede código que hay entre la cláusula when none del for each y el endfor.

Cuando un for each no tiene condiciones de filtro, los comandos del when none se ejecutarán soloen el caso en que se cumpla que la tabla base del For each esté vacía, porque solo en ese caso nohabrá ningún registro que cumpla las condiciones de filtro.

Importante:

• Si aparecen atributos en el bloque de código correspondiente al when none, éstos no son tenidosen cuenta para determinar la tabla base del for each.

• Si se incluyen for eachs dentro del when none no se infieren Joins ni filtros de ningún tipo conrespecto al for each que contiene el when none, ya que son considerados for eachs paralelos.



Comando For each - Sintaxis

for each

[{[order] order_attributes [when condo] }…|[order none] [when condon]]

[{where condition when condw }…][def ined by defined_attributes]

code1

[when duplicatecode2]

[when none

code3]

endfor

La sintaxis presentada generaliza el ejemplo con el que vinimos trabajando. Es la sintaxis generalque aplica a plataformas Cliente/Servidor. Para plataformas centralizadas existen algunaslimitaciones (cláusulas when y order none no aplican a este caso).

Orderorder_attributes::= att1, …, attn

Es una lista de atributos, que indican el orden en el que será devuelta la consulta, siendo atti unatributo de la base de conocimiento escrito simple, o entre paréntesis curvos. Cuando un atributodel order aparece rodeado de paréntesis curvos se está indicando orden descendente para el

mismo.Aquí pueden mencionarse atributos de la tabla extendida, a menos que se esté trabajando enuna plataforma centralizada, en cuyo caso solo podrán utilizarse atributos almacenados en latabla base.

Para plataforma centralizada, podrá especificarse a lo sumo una cláusula order, sin condición(when). Sin embargo puede no especificarse cláusula order. En tal caso se asume como orden elde la clave primaria de la tabla base , salvo excepciones que estudiaremos oportunamente.

Para plataforma cliente/servidor es posible definir varias cláusulas order condicionales, y unaincondicional, que debería ser la última listada. El por qué responde al hecho de que comosolamente una de esas cláusulas order tomará efecto, se van evaluando sus condiciones (las delwhen) hasta la primera que de True, y con esa se queda. Si ninguna da true y existe una cláusulaincondicional (es decir, sin when), se tomará ese orden. Si no existe tal cláusula, el orden seráindefinido, queriendo esto significar que dependerá de la plataforma, e incluso podrá variar entreejecuciones sucesivas. La justificación para escribir cláusulas order condicionales, deriva de siqueremos aplicar cláusulas where condicionales. Es decir, por motivos de optimización de lasconsultas.Por ejemplo, si queremos filtrar por CustomerName > &Name when not &Name.IsEmpty(),entonces para optimizar la consulta deberíamos ordenar por CustomerName, pero si no se va aaplicar el filtro, dado que &Name está vacía, entonces será mejor dejar un orden indefinido.Para ello especificamos la cláusula order condicional:

order CustomerName when not &Name.IsEmpty()

En lugar de todo lo anterior, también puede especificarse una cláusula order none que seagrega para cuando no nos interesa un orden en particular y queremos que éste quede indefinido.



Elección del índice: GeneXus elige automáticamente el índice a utilizar para satisfacer el orden. En caso de queno exista, informa de esta situación en el listado de navegación y dependiendo de la plataforma, crea un índicetemporal o deja en manos del DBMS la elección de la estrategia para procesar la consulta.

Los atributos del order son tenidos en cuenta a la hora de determinar la tabla base del for each. Pero ellos porsí solos no la determinan. Deben examinarse también otras partes del for each.

WhereCondition

Condición booleana que deberán cumplir los datos para ser procesados dentro del for each, pudiendo ser unacondición compuesta, utilizando los operadores lógicos and, or y not.

Los atributos que aparezcan en la condición booleana pueden ser tanto de la tabla base del for each como dela extendida.

Como se desprende de la sintaxis, para un mismo for each pueden especificarse n cláusulas where sucesivas, cadauna con una condición:where cond1

where cond2

...where condn

La ocurrencia de n cláusulas where es equivalente a la ocurrencia de una sola cláusula, con la conjunciónbooleana de las condiciones:

where cond1 and cond2 and … and condn

Los datos de la tabla extendida del for each que cumplan con todas las condiciones de los “where” serán losprocesados en los comandos internos al for each (los del bloque de código code1).

Para el caso de plataformas cliente/servidor, al igual que ocurre con la cláusula order, podrán condicionarse losfiltros (con cláusulas when). De esta manera, primero se evalúa la cláusula when de cada cláusula where, y decumplirse su condición, aplicarán el filtro especificado en el where.

Para que una restricción condicional pueda ser generada como tal, se debe estar en una arquitecturaCliente/Servidor y la condición del when tiene que ser "evaluable" por el DBMS que se está utilizando, es decir,GeneXus tiene que saber cómo escribir la condición en el lenguaje propio del DBMS utilizado.

Si no se puede generar como tal (porque el generador no lo soporta o porque la condición no puede ser escrita enel lenguaje del DBMS) se transformará en un filtro "común" sustituyendo el WHEN por un OR. Además, segenerará el mensaje de código spc0053 – ‘Unsupported conditional constraint”%1” changed to standardconstraint %2.’ - en el Diagrama de Navegación.

Nota: Existe también la cláusula Option Distinct del For Each que permite retornar los registros que cumplan

unicidad de valores de los atributos referenciados. No veremos esta cláusula. El lector interesado puede recurrir alas distintas fuentes de documentación para estudiarla (Help, GXDL, Wiki, Release Notes, etc.)

Def ined bydefined_attributes::= att1, att2,…,attp

Es un conjunto de atributos que serán utilizados a los solos efectos de determinar la tabla base del for each.

Al mencionar aquí algunos atributos de la tabla que se desea recorrer, éstos participarán en la determinación de latabla base del for each.

La cláusula defined by aparece para solucionar algunos problemas de ambigüedad en la determinación de latabla base (cuando existen varias tablas extendidas mínimas que contienen a los atributos del for each) o cuandose desea que la tabla base sea otra, distinta de la que sería determinada por los atributos que aparecen en elresto del for each (este caso cobrará sentido cuando se estudie “corte de control”). También se utiliza paramejorar el tiempo de especificación en reportes complejos.

Los atributos de esta cláusula no determinan por sí solos la tabla base del for each. Podría darse el caso de que deestos atributos surja determinada tabla como la candidata a tabla base, pero si luego el resto de los atributosdel for each no están contenidos en la extendida de esa tabla, el for each dará un error y el objeto que lo contieneno podrá ser generado.

code1

Es una sucesión de comandos en los que pueden utilizarse atributos de la tabla extendida del for each. A estebloque de código le llamaremos cuerpo del for each.

Los atributos que figuren en este bloque de código participarán en la determinación de la tabla base del for each.



Los comandos especificados se ejecutarán secuencialmente para los datos de la tabla extendida que cumplan lascondiciones de filtro, considerándose los datos en el orden especificado.

When DuplicateEsta cláusula solo tiene sentido en procedimientos (dado que tiene que ver con la actualización) y se verá másadelante.Se ejecutará esta cláusula si dentro del cuerpo del For each code1, se intenta actualizar un atributo que es clavecandidata (tiene índice unique) y ya existe un registro con ese valor. GeneXus utiliza el índice unique para

asegurar la unicidad de esa clave candidata y en caso de encontrar duplicados, si el for each tiene programadaesta cláusula, ejecutará su código: code2 .De no existir la cláusula no se ejecutará código alguno.

When noneEn caso de que no existan datos que cumplan las condiciones de filtro no se ejecutarán los comandos del code1

sino que se ejecutarán los del bloque de código code3.

Tanto para When Duplicate como para When none: Si se incluye dentro de alguno de los dos un comando foreach, no se infieren joins ni filtros con respecto al for each que los contiene (el del when none | when duplicate).Son consideradas navegaciones independientes (la del code1, code2 y code3).



For eachs paralelos

• Llamamos de esta forma al caso de for eachs que están escritosen forma secuencial (no anidada)Ejemplo:

• También aplica al caso en el que un for each aparece dentro de lacláusula when none o when duplicate de otro.

• Las navegaciones son totalmente independientes

for eachprint invoice

endforfor each

print billendfor

El For each es un comando como otros, y por tanto puede aparecer varias veces dentro del Source,tanto en forma paralela (independiente), como anidado a otro for each.

Cuando dentro del cuerpo del for each (code1) aparece otro for each, decimos que se trata de foreachs anidados. GeneXus soporta varios niveles de anidamiento para los for eachs.

El caso en el que un for each aparece en el bloque de código code3, si bien puede verse como un

anidamiento de for eachs porque uno aparece dentro de otro, el comportamiento en cambio, escomo el del caso de for eachs paralelos.

Un for each “anidado en el when none” de otro, solo se ejecutará si no existe ningún registro de latabla base del for each que lo contiene que cumpla las condiciones de filtro.

En el ejemplo, “invoice” y “bill” son dos print blocks del Layout que continen atributos de las tablasINVOICE y BILL (recibo) respectivamente.

Hemos definido dos for eachs paralelos. El primero recorrerá todas las facturas y el segundo todoslos recibos.



For eachs anidados

• Se busca recuperar por cada registro del for eachprincipal, muchos registros del anidado

for each...for each

...endfor...

when none

...endfor

Cuerpo del for each principal

El for each es una estructura repetitiva que permite recuperar muchos registros de una tabla. Cuandouno piensa en for eachs anidados, es evidente que lo que se busca recuperar es, por cada registro delprincipal, muchos registros del anidado.

¿Qué cosas podría GeneXus detectar que se quiere hacer con este tipo de estructuras, de forma tal depoder inferir el comportamiento automáticamente con la menor codificación posible?

• para cada registro de una tabla recuperar algunos de otra: los relacionados.• para cada registro de una tabla recuperar todos los de otra.• procesar información por grupos, esto es, agrupar los registros de una tabla según el valor de unatributo o conjunto de atributos y para cada grupo, recuperar algunos registros: los correspondientesal grupo.

Siempre la relación es uno a muchos: por cada registro de una tabla recuperar muchos de la otra(pudiéndose tratar de la misma tabla).

Utilizando esta lógica es que GeneXus infiere las tablas base y el comportamiento de los for eachsanidados, sabiendo que lo que se desea es implementar alguna de las tres opciones anteriores.

Por ejemplo si queremos realizar un listado de todas las facturas del sistema, donde para cada unaqueremos imprimir también el detalle de la misma, debemos recorrer dos tablas: INVOICE (quealmacena los cabezales) e INVOICELINE (que almacena las líneas), y lo haremos de una forma biensimple, sin nombrar las tablas, y sin tener que explicitar todo, como veremos.

Otro ejemplo es el de un listado de todos los clientes, donde para cada uno se quieren imprimir,además de sus datos personales, los datos de todas sus facturas. Este comportamiento se logra con unpar de for eachs anidados, donde el primero recorrerá la tabla CUSTOMER y el segundo recorrerá latabla INVOICE, recuperando solo las facturas de ese cliente, como veremos en breve.



For eachs anidados

• Ejemplo: imprimir todas las facturas con sus respectivaslíneas

for eachprint invoice_headerfor each

print invoice_linesendforprint invoice_total

endfor

{InvoiceId, InvoiceDate, CustomerName}

{ProductDescription, ProductPrice,InvoiceLineQuantity, InvoiceLineAmount}

{InvoiceTotal}

Queremos realizar un listado de todas las facturas del sistema, donde para cada una se muestretanto información de su cabezal como de sus líneas.

En el Source programado, claramente recorremos la tabla INVOICE, imprimiendo los atributos quenos interesan del cabezal y para cada registro de esa tabla, recorremos la tabla INVOICELINE, paraimprimir los atributos que nos interesan de sus líneas.

¡Tan simple como eso! Otra vez, nos alcanza con nombrar los atributos que queremos utilizar y delresto se encarga GeneXus.

Observemos que ni siquiera tuvimos que especificar condición de filtro sobre los registros deINVOICELINE a recuperar. GeneXus se da cuenta de la relación existente entre las tablas, y aplicaautomáticamente la condición de filtro sobre los datos, de manera tal de solo imprimir las líneas de

“esa” factura (recordar que algo idéntico ocurría con las fórmulas verticales, como InvoiceTotal,donde la condición de filtro sobre los registros a ser sumados o contados quedaba implícita, y nohabía que especificarla).



• Ejemplo: imprimir todas las facturas con sus respectivas líneas

INVOICE INVOICELINE

Para cada registro de INVOICE imprimir algunos de sus datos(InvoiceId, InvoiceDate) y de su extendida (CustomerName).

Luego navegar INVOICELINE y recuperar los registros quecorrespondan a la factura que se está imprimiendo.

Los que cumplan la condición implícita:INVOICELINE.I nv oi ceI d = INVOICE.I nv oice I d

For eachs anidados

Como para un for each simple, GeneXus debe determinar para cada for each (principal y anidado)cuál es su tabla base. Y luego, a partir de esa determinación, inferirá la lógica correspondiente.

Más adelante veremos con exactitud cómo es que GeneXus determina cada tabla base. Aquí nosquedaremos con la idea intuitiva de que lo hace en forma similar a como lo hacía para el caso de unfor each simple.

Encuentra, pues, que debe recorrer las tablas INVOICE e INVOICELINE.Como esas tablas están relacionadas de acuerdo a una relación 1-N infiere más que eso: infiereademás que debe aplicar la condición sobre los datos de INVOICELINE que se indica arriba.



GeneXus debe:

1. Determinar la tabla base de cada for each.

2. A partir de eso definir las navegaciones querealizará para cada for each (existen 3 casosposibles).

La lógica de los for eachs dependerá de lasrelaciones que encuentre entre las tablasdeterminadas.

For eachs anidados

Cuando tenemos for eachs anidados, GeneXus debe determinar la tabla base de cada uno, y esasserán las tablas que se navegarán.

Para cada registro de la tabla base del for each principal, se ejecutarán los comandos del cuerpo delmismo. Entre esos comandos, se encuentra el for each interno, que se ejecutará, como cualquierotro comando, en el lugar donde se encuentre, realizando una navegación sobre su tabla base.

Pero para la determinación de la tabla base del for each anidado, podrá influir la tabla base del foreach principal, por lo que las determinaciones no son por completo independientes, como podríapensarse.

A partir de la determinación de las tablas base de cada for each primero y de las relacionesque encuentre GeneXus entre las tablas involucradas luego, surgen tres posibles casos de for eachsanidados: join, producto cartesiano y corte de control, respectivamente.

Estudiaremos en lo que sigue cada uno de estos casos con ejemplos, para luego generalizar todo lovisto.



For eachs anidados:determinación tablas base

• Se procede en forma ordenada, determinandocada vez la tabla base de un nivel de anidación,yendo de afuera hacia adentro: primero sedetermina la tabla base del for each másexterno, luego del que está anidadoa éste y así sucesivamente.

• Para cada for each, intervienen únicamentelos atributos propios de ese for each: delorder, where, defined by y todos los del cuerpo que nopertenezcan a un for each anidado (tampoco intervienen

los de la cláusula when none).

for each...for each

...endfor...

when none...

endfor

Consideremos el caso más simple, de un par de for eachs anidados.

• La determinación de la tabla base del for each principal, es análoga al caso de for eachsimple (sin anidamientos). En este caso se consideran todos los atributos del for each principal,descartando los for eachs anidados que éste contenga (y todos sus atributos). GeneXus encuentrala mínima tabla extendida que contenga a los atributos referidos y define así la tabla base a travésde la cual llega a todas las demás.

• Para determinar la tabla base del for each anidado, GeneXus se fija si los atributosutilizados dentro del cuerpo del mismo están incluidos o no dentro de la tabla extendidapreviamente determinada (la del for each principal). En caso afirmativo, GeneXus determina que latabla base del for each anidado será la misma que la del for each principal.En caso contrario, se busca la mínima tabla extendida que cumpla que contiene a todos losatributos del for each anidado. Su tabla base será la del for each. (Observar que solo en este casose procede a determinar la tabla base como si se tratase de for eachs independientes).

Veremos un esquema resumiendo lo anterior más adelante.



For eachs anidados:determinación tablas base



endfor

{ I nv oiceI d , I nvo iceDate ,Cust om erNam e}

{ I nv oiceTot al }

Tabla base for each externo



endfor

{ ProductDescr ip t ion , ProductPr ice ,

I nvo iceL ineQuant i ty ,I nvo iceL ineAm ount }

Tabla base for each interno

INVOICE

INVOICELINE

Para el ejemplo que presentamos antes, mostramos arriba cómo se determina cada tabla base.

Para la del anidado, como los atributos que figuran no están contenidos en la tabla extendida deINVOICE (que es la tabla base del principal), entonces se pasa a determinar su tabla base como sise tratase de un for each independiente.

Este es el caso general, pero en algunas circunstancias particulares GeneXus toma un criterio más

exhaustivo intentando encontrar relación 1-N entre los for each y en esos casos, la determinaciónde la tabla base del for each anidado (cuando los atributos del mismo no están incluidos en laextendida del principal) no es independiente. GeneXus busca otra relación, pero no entraremos enestos casos particulares en el presente curso. De sucederle al estudiante, lo notará claramente en ellistado de navegación.



For eachs anidados:lógica asociada

• Tablas base distintas

• Tablas base iguales• Corte de Control: Corresponde al caso en el que queremos

recuperar información por grupos.

(Caso 1)

(Caso 2)

(Caso 3)

Fe externo

Fe anidado

¿

?

¿Existe relación implícita que lo vincule conun número N de registros del for each anidado?

Join: se recuperan algunos registros delanidado, los relacionados.

Producto cartesiano: se recuperantodos los registros del anidado.

Sí

No

1

N

De la determinación de las tablas base, surgen los tres casos de for eachs anidados que semencionan y que estudiaremos uno a uno en lo sucesivo.

Este tema es de vital importancia, ya que la mayoría de las aplicaciones requierennavegaciones complejas sobre las tablas, donde se requiere una mixtura de todos estos casos.



Caso 1: Join

• Distintas tablas base pero existe una relación 1-N directa o

indirecta entre ellas

• Ejemplo: Listado de todos los clientes y sus facturas

for eachprint customerfor each

print invoiceendfor

endfor

{CustomerId,CustomerName}

{InvoiceId, InvoiceDate,InvoiceTotal} INVOICE

CUSTOMER

CustomerId

En el for each anidado se ordena por atributo relación: CustomerId

ext(principal) ∩ base(anidado) = {CustomerId}

Este es el caso en el que GeneXus determina que las tablas base de cada for each son distintas y hayuna especie de relación 1-N (pudiendo ser ésta indirecta, como veremos luego) entre las tablas quese recorren.

Es decir, por cada registro de la tabla base del for each principal, GeneXus encuentra que hay Nrelacionados con él, directa o indirectamente, en la tabla base del for each anidado.

Al encontrar esta relación, aplicará condiciones de filtro automáticas en el for each anidado, de forma

tal de solo quedarse con esos registros relacionados.El ejemplo del reporte en el que se imprimen todas las facturas del sistema, con sus detalles, caedentro de esta categoría. En ese caso hay una relación 1-N directa entre las tablas que se recorren:para cada cabezal de factura, se lista el mismo, junto con todas sus líneas de factura, es decir, todoslos registros de INVOICELINE que están relacionados con el registro de INVOICE en el que se estáposicionado en cada iteración.

Este es uno de los casos más comunes de for eachs anidados, donde se quiere recorrer una tabla, ypara cada registro de la misma, recorrer otra tabla, relacionada con la primera por una relación N-1.GeneXus encuentra esta relación, y en la navegación interna solo recupera los registros asociados, yde ahí el nombre de “join” para este caso.

En el ejemplo presentado arriba ocurre lo mismo. La tabla base del primer for each es CUSTOMER, yla del segundo, INVOICE. Como encuentra atributo en común entre la tabla extendida del for eachprincipal y la tabla base del anidado1, CustomerId, determina que ese atributo actuará comocondición de filtro en la recorrida de la tabla del for each anidado.

------------------------------------------------------------------------------------------------------------1 Esta es una forma de expresar formalmente lo que habíamos dicho en términos informales: relacióndirecta o indirecta 1-N entre las tablas base. La relación será directa cuando la tabla base delprincipal tenga relación 1-N con la tabla base del anidado, es decir, sea superordinada de esta última.La relación será indirecta cuando esto no exista una relación directa entre las tablas base, pero sí entre la tabla extendida del primero y la tabla base del segundo. También será indirecta cuando latabla extendida del anidado incluya a la tabla base del principal. De esto veremos ejemplos luego.



Caso 1: Join

Veamos, por ahora intuitivamente, cómo hace GeneXus para determinar las tablas base. Losatributos utilizados en el for each externo son CustomerId y CustomerName, por lo que la tablabase de este for each será claramente CUSTOMER. Observemos que solo participan en ladeterminación de esta tabla base los atributos del for each principal, no los del anidado.

Luego GeneXus debe encontrar la tabla base del for each anidado. Los atributos que participan sonInvoiceId, InvoiceDate y InvoiceTotal, es decir, los atributos internos a este for each. Observemos

que estos atributos no pertenecen a la tabla extendida del principal, que era CUSTOMER. Por tantose pasa a determinar su tabla base como la de cualquier for each simple: la tabla extendida deINVOICE contiene a todos los atributos del for each anidado, y es la mínima tabla extendida que loscontiene. Por lo tanto, INVOICE será elegida como tabla base del segundo for each.

Observemos, nuevamente, que no explicitamos cláusula where en el for each anidado para filtrar lasfacturas del cliente del for each principal. Justamente, por tratarse de tablas relacionadas por unarelación 1-N directa, esta condición es aplicada implícitamente por GeneXus y puede verseclaramente en el listado de navegación que se muestra arriba.

Hay otro hecho interesante que podemos observar en este listado: si bien en el for each anidado noespecificamos cláusula order, GeneXus no eligió el orden por clave primaria de la tabla base sinopor el atributo relación, CustomerId. De esta manera, está optimizando automáticamente laconsulta.

Acá se presenta, pues, una excepción a la regla que enunciaba que cuando no se especifica cláusula

order en un for each, GeneXus determina como orden el de la clave primaria de la tabla base dedicho for each.



• Ejemplo: Listado de todas las facturas por país

for eachprint countryfor each

print invoiceendfor

endfor

{CountryId, CountryName}

{InvoiceId, InvoiceDate, InvoiceTotal}

COUNTRY ⊂ ext(INVOICE) por lo que hay una relación 1-Nindirecta condición implícita: se listan las facturas del país

base(principal) ⊂ ext(anidado)

Caso 1: Join

INVOICE

CUSTOMER

CustomerId

COUNTRY

CountryId

Si queremos realizar un listado de las facturas emitidas por país, tenemos otro caso de for eachsanidados con distintas tablas base, donde la información que se quiere listar está relacionada.

Aquí queremos recorrer las tablas COUNTRY e INVOICE.

Observemos que si bien no están relacionadas directamente, sí lo están en forma indirecta. Dehecho, COUNTRY pertenece a la tabla extendida de INVOICE. Por lo tanto, por cada factura se

puede encontrar un solo país relacionado con la misma.Hilando fino, este es un caso un poco más complejo que el anterior, porque si bien la tablaextendida del for each principal no tiene intersección con la tabla base del anidado (ext(COUNTRY)∩ INVOICE = φ), sin embargo sí existe una relación 1-N indirecta, y GeneXus la encuentra.

En este caso, la tabla base del for each principal está incluida en la extendida del anidado(COUNTRY ⊂ ext(INVOICE)), por lo que hay una relación 1-N indirecta.

Por este motivo, no necesitamos especificar cláusula where en el for each interno para filtrar lasfacturas del país del for each principal.

Esto puede verse claramente en el listado de navegación, que mostrará el filtro: “CountryId = CountryId” para el segundo for each, pero esta vez como ‘Constraint’ dado que nopuede optimizar la recorrida.

Puede probar el lector este caso en GeneXus y estudiar detenidamente el listado de navegaciónresultante.



• Distintas tablas base, pero no existe relación 1-N directa ni indirecta entre las mismas.

• El resultado que obtenemos es el productocartesiano de dichas tablas: para cada registro dela tabla base del for each principal, se recuperantodos los registros de la tabla base del anidado.

ext(principal) ∩ base(anidado) = φ

ybase(principal) ⊄ ext(anidado)

Caso 2: Producto Cartesiano

En este caso GeneXus no logra encontrar una relación 1-N directa o indirecta entre las tablas y porlo tanto no aplica filtros implícitos a los registros del for each anidado, vale decir, realiza unproducto cartesiano entre las tablas.

El caso se da cuando:• ex t(for each principal) ∩ base(for each anidado) = φ y• base(for each principal) ⊄ ex t(for each anidado)

Para cada registro de la tabla base del for each principal se recorre toda la tabla base del for eachanidado.

Por ejemplo, si la tabla base de un for each fuera COUNTRY y la del anidado PRODUCT,evidentemente no existirá relación y se hará un producto cartesiano y se recorrerá para cada país,todos los productos.

Por supuesto que el programador podrá establecer filtros sobre los datos a recuperar, pero éstos yano serán condiciones implícitas inferidas por GeneXus, sino especificadas explícitamente por elprogramador.



Caso 3: Corte de Control

• Ejemplo: Para cada cliente que tiene facturas, listar

sus facturas.

En el ejemplo que habíamos visto antes, del listado de clientes y sus facturas, ¿qué ocurre si uncliente no tiene facturas?

Como la tabla base del for each principal es CUSTOMER, el cliente sale impreso antes de saberse sitiene o no facturas.

Si no deseamos que esto ocurra, es decir, que salgan listados clientes que no tengan facturas,

entonces la solución es acceder únicamente a las facturas, pues si un cliente está en esta tabla,¡es porque está en una factura!.

Pero para poder agrupar las facturas por cliente, de forma tal de poder desplegarlas de ese modo,debemos recorrer la tabla INVOICE ordenada por CustomerId. De esta forma procesaremos lainformación de un cliente, y luego pasaremos al siguiente, para procesar su información, y así sucesivamente.

Si imaginamos un puntero que se va desplazando secuencialmente por la tabla INVOICE, podemosescribir el pseudocódigo de nuestro reporte como sigue:

1. Para el registro apuntado, retener el valor del atributo de corte o agrupamiento, CustomerId.

2. Acceder a la tabla CUSTOMER (que está en la extendida de INVOICE) para recuperar elCustomerName e imprimirlo junto con el CustomerId (“print customer”)

3. Mientras el valor de CustomerId del registro apuntado coincida con el valor retenido en el paso1 (aquí se procesan todas las facturas del cliente)

a. Imprimir InvoiceId, InvoiceDate e InvoiceTotal del registro apuntado.(“print invoice”)

b. Avanzar el puntero al siguiente registro y volver al paso 3.

4. Volver al paso 1. (cuando se llegó a este punto, es o bien porque se llegó al fin de tabla o bien secambió de cliente).




Ejemplo: Para cada cliente que tiene facturas, listar sus facturas.

for each order Cust om er I d defined by I nv o iceDate

print customerfor each

print invoicesendfor

endfor

orden determina elcriterio de corte

Cada vez que cambia el cliente sedefine un nuevo grupo

Se utilizó “defined by” para que la tabla base fuera INVOICE y noCUSTOMER y así implementar corte de control y no join.

• Source

• Layout

GeneXus brinda una forma de implementar lo anterior de una forma absolutamente sencilla.

El pseudocódigo visto en la página anterior se implementa en GeneXus con el par de for eachsanidados que se muestran arriba.

Si se compara este código con el que vimos unas páginas atrás para el caso de join, vemos queexisten solamente dos diferencias: la cláusula order que aparece en este código, en conjunción con el

defined by. Con solo esos dos cambios al listado original, cambiamos radicalmente elcomportamiento, puesto que en este caso solamente se listarán los clientes si tienen facturas.

En este caso, ambas cláusulas (order y defined by) son indispensables para que este reporte funcionedel modo que queremos. Si agregamos solo una de ellas, pero no la otra, el resultado será otro.

No en toda implementación de un corte de control deberá especificarse una cláusula defined by en elfor each principal, mas sí una cláusula order.

La cláusula order es indispensable, porque es la que especifica por qué atributo o conjunto deatributos se realizará el corte (o agrupamiento). Es decir, especifica esa información común al grupo,que se procesará una sola vez (dentro el código del for each externo).

La cláusula defined by no es indispensable en todos lo casos. En este sí lo fue, porque de noespecificarla, GeneXus determinaría como tabla base del for each principal CUSTOMER, que no es loque queremos (pues no queremos implementar un join, cosa que ya hicimos antes, sino un corte de

control, para solo recorrer la tabla INVOICE).

Pero también podríamos haber utilizado otra solución para modificar la tabla base del for eachprincipal: utilizar en vez del defined by el comando print i f detai l dentro del cuerpo del primer foreach (este comando le dice a GeneXus que tome como tabla base del for each, la que determine parael anidado).



• Condiciones que deben cumplirse para implementar Cortesde Control:

1. for each anidados

2. Tienen la misma tabla base

3. ¿Cuántos for each? Uno más que la cantidad de cortes

4. Debemos establecer en la cláusula order de cada foreach externo, el atributo o conjunto de atributos por los que

queremos “cortar”.


Un corte de control es bien simple de implementar y puede hacerse siguiendo las consideracionesanteriores.En el order del for each más externo, debemos mencionar el “primer” atributo de corte, en el orderdel segundo for each debemos mencionar el “segundo” atributo de corte, y así sucesivamente. Noes obligación mencionar atributo/s en el order del for each más interno (en todos los demás foreach sí lo es).

Corresponde al caso en el que nos interesa trabajar con la información de una tabla, pero agrupadapor algún atributo o conjunto de atributos.

Los cortes de control pueden ser simples, dobles, triples, etc.

A continuación veremos un ejemplo de un corte de control doble.



Ejemplo: Corte de control doble

Supongamos que queremos como antes listar los clientes y sus facturas, pero queremos agrupar lasfacturas de cada cliente por fecha. Es decir, queremos mostrar, para cada cliente, para cada fecha,las facturas existentes.

Ejemplo:

Customer: 1 Juan Pérez

Date: 12/05/05Invoice Total

1 15


9 353 30

Customer: 3 María Donoso


2 20Date: 12/08/05

Invoice Total

4 408 15Date: 02/02/06

Invoice Total7 20

…

Como ahora queremos agrupar por cliente, y dentro de ese grupo por fecha de factura, necesitamostres for eachs anidados:

For each order Cust om erI d defined by InvoiceDate

print customerfor each order I nvo iceDate

print datefor each

print invoiceendfor

endforendfor

Como ejercicio, sigamos todos los pasos que realiza GeneXus para inferir el comportamiento delreporte.

1. Determinación de la tabla base de cada for each

Como siempre, para determinar las tablas base de for eachs anidados, se empieza de afuera haciaadentro, determinando la de cada for each, sin tomar en cuenta los atributos de los for eachsinternos al que se está considerando.

for each order Cust om erI d

defined by I nvo iceDate print customerfor each order InvoiceDate

print datefor each

print invoiceendfor

endforendfor

Tabla base 1er. for eachSolo intervienen los atributos de loslugares señalados en negrita.

Mínima tabla extendida que loscontiene: ext(INVOICE)



2. Determinación de l a navegación

Luego de determinadas las tablas base, GeneXus determina la navegación. Como en este caso son tres for eachssobre la misma tabla base, se trata de un doble corte de control.

Podemos pensar que cuando hablamos de corte de control, ya sea simple, doble, triple, cuádruple, etc., tenemos unsolo puntero, que se utiliza para avanzar en los registros de la tabla base.

Recordemos que la cláusula order es fundamental para establecer el criterio de corte en cada par de for eachs.

Como en nuestro caso queremos agrupar por CustomerId y luego, para todas las facturas con ese cliente, agruparpor InvoiceDate, entonces tendremos que ordenar el primer for each por CustomerId y el inmediatamente anidadopor InvoiceDate.

En el ejemplo estamos diciendo que:

Mientras no se alcance el fin de tablaImprimir los datos del cliente de la factura actualMientras no cambie el cliente

Imprimir la fecha de la factura actualMientras no cambie la fecha

Imprimir los datos de la factura actual (nro y total)Avanzar el puntero al siguiente registro

Recomendamos al lector implementar en GeneXus este reporte y observar detenidamente el listado de navegación.

Verá que GeneXus elige un único orden, para el que no tiene un índice creado: el compuesto por la concatenaciónde los órdenes de cada for each con cláusula order. Esto resulta evidente si pensamos en términos de un únicopuntero que se va desplazando por la tabla base.

Tabla base 2do. for eachIntervienen los atributos de los lugares señalados ennegrita y como todos ellos están incluidos en laextendida del 1er. for each, entonces se determina la

misma tabla base: INVOICE

for each order CustomerIddefined by InvoiceDate

print customerfor each order I nvo iceDate

print datefor each

print invoice

endforendforendfor

for each order CustomerIddefined by InvoiceDate

print customerfor each order InvoiceDate

print datefor each

print invoiceendfor

endforendfor

Tabla base 3er. for eachIntervienen los atributos de los lugares señalados ennegrita y como todos ellos están incluidos en laextendida del 2do. for each, entonces se determina lamisma tabla base: INVOICE



Resumen: Determinación general de las tablas base

Se procede en forma ordenada, determinando cada vez la tabla base de un nivel de anidación,yendo de afuera hacia adentro: primero se determina la tabla base del for each más externo, luegodel que está anidado a éste y así sucesivamente.

Determinación tabla base del for each externo

Se determina a partir de los atributos que aparecen dentro de ese for each: cláusulas order,where, def ined by y cuerpo del for each, exceptuando los atributos que estén dentro del foreach anidado. No participan los atributos que estén dentro del when none, en caso de que el foreach principal tenga esta cláusula. Al igual que en el caso de un for each simple, se encuentra lamínima tabla extendida que contenga los atributos mencionados.

Determinación tabla base del for each anidadoPodemos vernos tentados a pensar que por analogía lo que se debería hacer es extraer losatributos del for each anidado, y hacer lo mismo que antes, es decir, encontrar la mínima tablaextendida que contenga a esos atributos, como si se tratase de un for each independiente. ¡Pero noson for eachs independientes!

Para el for each anidado, GeneXus se fija primeramente si los atributos utilizados dentro del cuerpodel mismo están incluidos o no dentro de la tabla extendida previamente determinada. En casoafirmativo, GeneXus determina que la tabla base del for each anidado será la misma que la del foreach principal (y será un caso de corte de control).

En caso contrario, sí se determina como si fueran independientes: busca la mínima tabla extendidaque contenga a todos los atributos del for each anidado1.

Esquema general de determinación de la tabla base de un for each anidado.

Presentamos a continuación un esquema con notación matemática, que pretende mostrargráficamente lo que hemos dicho por escrito en los párrafos anteriores acerca de cómo sedetermina la tabla base del for each anidado.

En la siguiente página mostramos otro esquema, pero esta vez con los casos de for eachs anidadosde acuerdo a las tablas base encontradas.

----------------------------------------------------------------------------------------------------------1 Existe alguna excepción, pero no entraremos aquí en este tema.



Esquema de casos

Luego de determinadas las tablas base de los for eachs anidados, el siguiente paso que realizaGeneXus es determinar la lógica que se asociará a los mismos.

Esa lógica viene determinada de acuerdo al caso (join, producto cartesiano o corte de control) en elque caigan los for eachs anidados bajo análisis.

Un esquema de los casos puede verse más claramente con el diagrama de flujo que se muestra acontinuación:



Comandos de control

if cond

bloque1

[elsebloque2]

endif

do while condbloqueenddo

do casecase cond1

bloque1

[case cond2

bloque2]......

[case condn

bloquen]otherwise

bloquen+1

endcase

for &var=inicio to fin [step salto]bloque

endfor

for &var in &arraybloque

endfor

Los comandos introducidos son similares a los existentes en los lenguajes de programaciónimperativa conocidos, por lo que no incluimos documentación de este tema. Puede encontrarla en elcurso no presencial o en el Help de GeneXus. Los dos últimos, no obstante, incorporan algunoselementos interesantes sobre el manejo de arrays y de colecciones1 en GeneXus, por lo quemostraremos algunos ejemplos.

For to s tep:

• inicio, fin son expresiones numéricas• salto es una constante numérica• var es alguna variable numérica• bloque es una sucesión de comandos válidos del lenguaje

Permite iterar una cierta cantidad de veces: desde el valor i n ic io que toma la variable & v a r cuandose ingresa al bucle, hasta el valor f in que tomará la misma luego de cierta cantidad de iteraciones.De iteración en iteración la variable & v a r se va incrementando automáticamente en una cantidadigual a s a l to . El valor por defecto de s a l to es 1, por lo que si no se especifica la cláusula step elincremento de la variable será de uno en uno. El valor de s a l to puede ser negativo y en ese caso seirá decrementando la variable de iteración en iteración.

EjemploFor &i = 1 to 5

&ok = PInvoicing.udp( &month )endfor

----------------------------------------------------------------------------------------------------------1 Las colecciones representan listas de largo variable. Se verán cuando estudiemos el tipo de datosestructurado (SDT).



For in array:• array es un vector o matriz (variable de una o más dimensiones). También puede ser una variable SDTcollection (este tema se estudiará más adelante)• var es una variable que debe tener el mismo tipo de datos que array o compatible (en caso de tratarsede un SDT, deberá ser un SDT correspondiente a los í tems)

Esta estructura de programación permite recorrer con menos código una variable array de una o más

dimensiones. Se almacena en la variable &var los valores de cada posición del array.Para el caso de arrays de una dimensión, es equivalente a:

&x = 1

do while &x <= rows(&array())

&var = &Array(&x)

bloque

&x += 1

enddo

En el caso de dos dimensiones el comando es equivalente a:

&x = 1do while &x <= rows( &array() )

&y = 1

do while &y <= cols( &array() )&var = &array( &x, &y )bloque&y += 1

enddo&x += 1

enddo

Consideraciones:

• No es posible modificar los valores del array en la recorrida. Esto significa que cambios en el valor de&var en el alcance de la estructura, no afectan al correspondiente valor del &array(&x) (o de &array(&x,&y))

• No es posible obtener la posición del array durante la recorrida, para esto es necesario definir unavariable que actúe como contador

Ejemplo

For &i= 1 to 4

For &j=1 to 3

&array(&i,&j) = &i + &j

endfor

endfor



Comandos de impresión

• Print

• Se utiliza para imprimir en la salida un print block definidoen el Layout• Sintaxis: Print nombrePrintBlock

• Header

• Se utiliza para definir lo que se quiere imprimir como encabezadode cada página del listado

• Sintaxis: Header

bloque

end

• Footer• Define las lí neas de pie de página a ser impresas al final de cada

página del reporte.• Sintaxis: Footer

bloque

end

Aquí veremos algunos comandos de impresión, que permiten diseñar la salida del reporte.

Printdonde nombrePrintBlock es el identificador de un print block del Layout. Si no existe en el Layoutun print block con ese nombre, al intentar salvar el objeto se desplegará un mensaje de errorinformando sobre esta situación.

De esta forma se implementa la impresión en la salida de los print blocks del Layout.Cuando el print block que se quiere imprimir no contiene atributos, entonces este comando sepuede utilizar en cualquier lugar del Source.

Los atributos indican acceso a la base de datos y este acceso no puede realizarse en cualquier lado,sino únicamente dentro del comando especí fico para ello, esto es, el comando for each.

Por tanto no es correcto escribir el comando print fuera de un “for each” si el print block que se estáqueriendo imprimir contiene atributos.

La única excepción a esta regla se produce cuando los atributos del print block están incluidos entrelos parámetros recibidos por el reporte, pues en este caso no es necesario acceder a la base dedatos para recuperar sus valores, dado que ya vienen instanciados.

Header

Aquí se define lo que se quiere imprimir como encabezado de cada página del listado.Este encabezado es opcional. Si no se especifica, entonces las páginas del listado no tendránencabezado.

Ejemplo: En el reporte en el que quer í amos imprimir un listado con el código, nombre y paí s decada uno de los clientes de nuestro sistema, si queremos que en cada página del listado aparezca elencabezado: “CUSTOMERS REPORT” , entonces alcanza con escribir en el Source:

HeaderPrint title

End

Donde “title” es el nombre de un print block del Layout que contiene este texto.



También podrí amos haber escrito directamente: Print title al comienzo del Source, pero en estecaso, si el listado tiene varias páginas, solo saldrá impreso este texto en la primera. En el otro caso,saldrá en cada una de las páginas, como encabezado.

FooterDefine las líneas de pie de página a ser impresas al final de cada página del reporte.

Los comandos del bloque de código son ejecutados cuando se llega al final de una página.Ejemplo:

Footerprint endOfPageText

end

donde endOfPageText es el nombre de un print block del Layout



Diseño de la salida

Existen algunos comandos para diseñar la salida del reporte. Presentamos aquí algunos a losefectos de la documentación.

MT nline: nline es el número de línea en el que se quiere empezar a imprimir el listado. En caso deno especificarse un valor se asume el valor por defecto que es 0.

MB nline: 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 nline: Setea el largo de página. El número de líneas que será impreso es el número especificadomenos el margen de abajo (valor por defecto es 6). Ej: PL 66Setea el largo de página a 66 líneas, aunque sólo 60 líneas serán impresas en el form, con unmargen inferior de 6 líneas.

CP nlines: 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 nline: Define el número de línea donde va a ser impresa la siguiente línea. Si el número delínea actual es mayor al número especificado, entonces, la línea será impresa en la próxima página.El conteo de líneas comienza en la línea 0.

Eject: Fuerza a un salto de página.

Noskip: Tiene que estar inmediatamente después de un print block. Si el comando se encuentraentre dos líneas, este comando las imprimirá en la misma línea.



Reportes PDF

• Configurar las propiedades:• Main Program = True• Call Protocol = HTTP• Report Output = ‘Only to file’

• Regla• output_file( ‘xx.pdf’, ‘PDF’)

En Web los reportes solamente pueden ser PDF y se deben configurar las propiedades y reglaanteriores para que funcionen.

Definición de un objeto como main

Al definir que un objeto es main (en este caso un reporte, pero podría ser una transacción, web

panel, etc.), GeneXus genera un programa ejecutable con la lógica del objeto mismo y la detodos los objetos invocados directa o indirectamente por él.

El programa ejecutable generado se podrá compilar y ejecutar de forma independiente, es decir,al seleccionar Bui ld / Run se verá como programa independiente del Developer Menu y podrácompilarse y ejecutarse.

La definición de un objeto como main se realiza editando las propiedades del objeto, yconfigurando la propiedad Main program del mismo con valor True.



Condiciones

• Permiten especificar condiciones globales quedeberán cumplir los datos a ser recuperados.

Ejemplo:

En esta sección se permiten establecer condiciones que deben cumplir los datos para serrecuperados.

Una “condición” es equivalente a la cláusula “where” del comando for each (incluso tiene la mismasintaxis) con una salvedad: mientras que la cláusula “where” está ligada a un for each específico:aquel al que pertenece, las “condiciones” están ligadas a todos los for eachs del Source en los quetenga sentido aplicarlas.

¿Y para qué for eachs tiene sentido aplicarlas?Las condiciones generalmente involucran atributos. Si en la tabla extendida de un for each seencuentran los atributos que intervienen en una “condición”, entonces la misma se aplicará a estefor each para filtrar los datos quedándose únicamente con aquellos que satisfagan tal condición.

En el listado de navegación del reporte se indican los for eachs a los que se aplica cada condición delas especificadas en la sección “Conditions”.

Si en el Source del reporte “PrintCustomers” tenemos:

For eachPrint customer

endfor

Entonces al especificar las condiciones que se muestran en la transparencia, estaremos filtrando los

clientes, de acuerdo a las condiciones (es equivalente a tener las condiciones como “where”).



Condiciones

• Si el Source del reporte es:

For eachPrint customer

Endfor

For eachPrint invoice

Endfor

For eachPrint product

Endfor

For eachwhere CustomerName>=&start

Print customerEndforFor eachwhere CustomerName>=&startwhere InvoiceId < 100

Print invoiceEndforFor each

Print productEndfor

Conditions: CustomerName >= &Start;InvoiceId < 100;

donde:• “customer” es un print block que contiene los atributos CustomerId, CustomerName,CountryName• “invoice” es un print block que contiene los atributos InvoiceId, CustomerId, CustomerName,InvoiceDate, InvoiceTotal• “product” es un print block que contiene los atributos ProductId, ProductDescription, ProductStock

Si el reporte anterior tiene definidas las condiciones mostradas arriba, el reporte será equivalente auno sin “condiciones” y con el Source que se muestra a la derecha.

Observemos que en este caso las condiciones se traducen en cláusulas where pero que se aplicansolo a los for eachs para los que tiene sentido aplicarlas. En la tabla extendida del último for eachno se trabaja con nombre de cliente, ni con identificador de factura. No tiene sentido aplicar lascondiciones en este for each ya que no existe ninguna relación.En el primero, solo tiene sentido aplicar la que involucra a CustomerName y no la otra.

ObservaciónLos atributos involucrados en las “condiciones” no participarán en la determinación de las tablasbase de los for eachs del Source (a diferencia de los filtros que se especifican mediante cláusulaswhere).

Es decir, las tablas base de los for eachs que aparezcan en el Source se determinan sin mirar las “condiciones”. Una vez determinadas, recién en ese momento las condiciones son examinadas para

determinar a cuáles for eachs se aplicarán y a cuáles no.Lo mismo ocurre con los atributos que se reciban como parámetro. Aplicarán como filtro global porigualdad para los for eachs en los que tenga sentido, pero no participarán en la determinación delas tablas base.



Filtros en la navegación

Formas de filtrar los datos:

• Cláusulas Where

• Condiciones

• Regla Parm (Atributos recibidos comoparámetros)

Parm(Att1 ... Attn)

Participan en determinación de tabla base

NO participan en determinación de tabla base

Resumimos aquí las distintas formas de filtrar en un reporte o procedimiento la información arecuperar de la base de datos:

a. cláusulas whereb. Condicionesc. parm( att, ..., att )

Estudiemos las diferencias y similitudes entre ellas.1. Las cláusulas w here aplican exclusivamente al for each en el que se encuentran, mientras que losfiltros especificados como condiciones o los que quedan determinados por los atributos en la reglaparm son globales, es decir, aplicarán a todos los for eachs del Source en los que tenga sentidoaplicarlos.

2. Los filtros que quedan determinados al recibir en atributos en la regla parm son filtros porigualdad, es decir, para los for eachs en los que tenga sentido aplicarlos, se instanciarán únicamentelos registros que tengan el mismo valor que el recibido por parámetro. En cambio, los filtrosespecificados en las cláusulas where de un for each o en las condiciones pueden ser expresionesbooleanas cualesquiera, incluso compuestas.

3. Mientras que los atributos que aparecen en las cláusulas where participan en la determinación de latabla base del for each donde se encuentran, los que aparecen en las condiciones o en la regla parm nolo hacen. Recién entran en juego LUEGO de determinadas las tablas base de los for eachs del Source.



PROCEDIMIENTOS

Actualización de la base de datos

Los procedimientos definen procesos no interactivos (batch) de consulta y/o actualización de lainformación de la base de datos.

En lo anterior estudiamos los reportes y mencionamos que la mayoría de las características yconceptos introducidos eran comunes a los procedimientos.

Aquí nos abocaremos a profundizar en los comandos que son específicos para este tipo de objetos,es decir, aquellos que tienen que ver con la actualización de la base de datos.

Dijimos que los procedimientos eran un “superset” de los reportes, en el entendido de que todo loque se realiza con un reporte puede realizarse con un procedimiento, pero en cambio no se cumpleel recíproco, es decir, no todo lo que se realiza con un procedimiento puede realizarse con unreporte1.

En este capítulo estudiaremos ese “plus” que es lo que diferencia a ambos tipos de objetos y queviene dado por la posibilidad que tienen los procedimientos de actualizar la base de datos.

Estudiaremos entonces cómo se dan las altas, bajas y modificaciones en la base de datos utilizandoprocedimientos.

La pantalla de edición de procedimientos es idéntica a la de reportes.

----------------------------------------------------------------------------------------------------------1 A menos que se utilicen business components para hacer actualizaciones a la base de datos,como veremos cuando estudiemos este tema.



Actualización

• No hay un comando específico de actualización: se realiza en

forma implícita dentro del comando for each.• Ejemplo:

Reglas:Parm( &Inf );

Source:for eachwhere ProductDate = &Today

ProductPr ice = ProductPrice*(1+&inf /100)

endfor

Procedimiento “P riceIncrease”

ProductId*ProductDescriptionProductStock

(ProductDate*ProductPrice)

Transacción “Product”

La modificación de datos de la base de datos se realiza en forma implícita, ya que no hay uncomando específico de actualización.

Para actualizar uno o varios atributos de una tabla se utiliza el comando for each, y dentro delmismo el comando de asignación.

Supongamos que queremos tener un proceso batch que actualice para todos los productos

almacenados que tengan el precio fijado para el día de hoy, el atributo ProductPrice para adecuarlosegún el porcentaje de inflación.

La tabla base del for each será PRODUCTLINE y estamos asignando valor a un atributo de la misma,para todos los registros.

Se pueden actualizar varios atributos dentro del mismo for each, pudiendo éstos pertenecer tanto ala propia tabla base como a la tabla extendida.



• Atributos actualizables: los pertenecientes a latabla extendida del for each.

• Salvo:• los que forman parte de la clave primaria de la tabla

base del for each.• los que forman parte del índice por el que se está

accediendo a dicha tabla.

• La actualización se realiza en el endfor.

Actualización

Supongamos que tenemos el siguiente diagrama de Bachman genérico:

Y en el Source de un procedimiento hacemos:

for eachC = &CE = &ED = &D

endfor

Aquí la tabla base del for each será claramente la de clave primaria A y dentro del for each estamosactualizando tanto atributos de la propia tabla base como de la extendida.

¿En qué momento ocurre efectivamente la actualización de los registros involucrados?

Al final de cada iteración del for each se actualiza el registro de la tabla base y el/los registro/s de

la extendida que deban ser actualizados.Es decir, la actualización no ocurre ni bien se encuentra un comando de asignación dentro del foreach, sino luego de que se encuentran todos, para cada instancia de la tabla base, es decir, cuandose llega al endfor para cada iteración.

A*BC

D

B*EF



• Claves candidatas: índices unique• Se utiliza cláusula when duplicate en el for each

for each ...bloque1

[when duplicate...]

endfor

Actualización

Como vimos antes, no podemos actualizar dentro del comando for each atributos de la claveprimaria. Sin embargo podríamos querer actualizar un atributo que sin ser clave primaria, estádefinido como clave candidata (mediante un índice unique).

Si el atributo es clave candidata, debe controlarse que no se dupliquen sus valores, por lo que deencontrarse duplicado el registro en este sentido, no se permitirá hacer la actualización.

Si se desea tomar una acción en caso de que esto ocurra, el comando for each agrega la cláusulawhen duplicate. Solo tiene sentido si existe alguna clave candidata para ese for each.



Eliminación

• Comando Delete

• Debe ir dentro de un for each• Elimina el registro de la tabla base en el que se

esté posicionado• Se ejecuta ni bien se encuentra el comando (y no

en el endfor)

• Ejemplo:

for eachdefined by InvoiceDate

Delete

endfor

Borra todos losregistros de latabla base:

INVOICE

Para eliminar datos se utiliza el comando Delete dentro del comando for each.

El comando Delete elimina el registro en el que se está posicionado en un momento dado. Es porello que no puede aparecer “suelto” dentro del Source. Debe colocarse dentro de un comando foreach, cuya tabla base sea la tabla de la que se quieren eliminar registros. Solo se eliminan losregistros de la tabla base, no de la extendida.

Si deseamos eliminar todas las facturas anteriores a una fecha dada, podemos programar unprocedimiento:

for eachwhere InvoiceDate < =&date

for eachdefined by InvoiceLineQuantity

DELETE //se eliminan las líneasendforDELETE //luego de eliminar las líneas se elimina el cabezal

endfor



Inserción de registros

• Comando New : permite insertar un registro enuna tabla

• Ejemplo:

ProductId*ProductDescriptionProductStock

(ProductDate*ProductPrice)

Transacción “ Product” Rules:

Parm( &ProductId, &price );

Source:New

ProductId = &ProductIdProductDate = &Today

ProductPrice = &priceendnew

Procedimiento “NewPrice”

Supongamos que queremos implementar un procedimiento que haga lo siguiente: para el productocuyo código es recibido por parámetro, dé de alta un nuevo precio (también recibido por parámetro)en su lista de precios, para la fecha correspondiente al día en que se ejecuta el procedimiento.

El procedimiento debe crear un nuevo registro en la tabla PRODUCTLINE, que está compuesta porlos atributos ProductId, ProductDate y ProductPrice, siendo su clave primaria una compuesta,conformada por ProductId y ProductDate.

Para ello se utiliza el comando new que escribimos arriba. Observemos que dentro del mismoaparecen comandos de asignación, donde se le da valor a los atributos de la tabla en la que sequiere insertar el registro.

En este caso queremos insertar un registro en la tabla PRODUCTLINE y le especificamos medianteasignaciones el valor que queremos que tomen los atributos de dicha tabla para ese registro.

¿Cómo entiende GeneXus que la tabla en la que queremos insertar el registro es PRODUCTLINE, sino la mencionamos?

Cada vez que GeneXus encuentra un new, debe determinar la tabla en la que se realizará lainserción (tabla base del new ).

Esta tabla es determinada a partir de los atributos que aparecen dentro del comando new, de llado izquierdo en una asignación .

En el ejemplo, son tres los atributos que aparecen dentro del new del lado izquierdo de un comandode asignación.



• El comando new realiza el control de duplicados(clave primaria y claves candidatas)

NewProductId = &ProductIdProductDate = &TodayProductPrice = &price

When duplicatefor each

ProductPr ice = & pr i c e endfor

endnew

Ejemplo (cont.)

En caso de que exista unprecio para ese productoy esa fecha, queremoscambiar ese precio


Solo se insertará uno, pues el comando new realiza el control de duplicados. Es decir, alintentar insertar un nuevo registro, se controla previamente que ya no exista uno en la tabla con elmismo valor en la clave primaria que el que se está intentando insertar. De existir claves candidatas(definidas mediante índices unique) también se controlarán.

El comando new cuenta con una cláusula opcional: la cláusula when duplicate. Con ella seprograma la acción a realizar en caso de encontrarse duplicado el registro. Por ejemplo,

supongamos que en caso de que el producto ya tenga en su lista de precios una entradacorrespondiente a la fecha de hoy, entonces en tal caso queremos cambiar ese precio.

Para ello agregamos al comando new la cláusula when duplicate.

Aquí estamos actualizando el valor del atributo ProductPrice en caso que el registro se encuentreduplicado. Es decir, si ya existe un registro en la tabla con los valores de &ProductId y &Today ensu clave primaria, entonces para ese registro se actualiza el precio.

Observemos que para realizar la actualización del atributo, la asignación debe estar dentro de uncomando for each. Si no colocamos el for each no se realizará la actualización del precio para eseregistro, es decir, es como si no se hubiera incluido cláusula when duplicate.

Como hemos visto, para actualizar la base de datos se emplea el comando for each, y por tantoaquí simplemente se uniformiza el comportamiento, de manera tal que siempre que se pretendaactualizar la base de datos vía comando, se hará con un for each (a excepción del uso de business

components, que veremos más adelante en el curso).



new[Defined by att1,…, attN]

bloque_asignaciones1

[when duplicatefor each

bloque_asignaciones2

endfor]endnew


• Sintaxis del new:

La inserción de datos en la base de datos utilizando procedimientos se realiza exclusivamente con elcomando new , que permite dar de alta un registro en una tabla de la base de datos.

En la sintaxis presentada, bloque_asignaciones1 es un bloque de código compuesto mayormente porsucesivos comandos de asignación (aquí se asigna valor a los atributos de la tabla en la que seinsertará el registro, aunque también pueden asignarse valores a variables).

La cláusula Defined By opcional, se incorpora a los mismos efectos que lo hacía para el comandofor each: ayudar a determinar la tabla base.

El comando new realiza un control de duplicados, de manera tal que no se permitirá insertar unregistro que ya exista en la tabla.

La cláusula when duplicate del comando permite programar la acción en caso de que el registroya exista en la tabla base (tanto por clave primaria como por clave candidata).

Normalmente, de ocurrir lo anterior, se quiere actualizar algunos de los atributos de dicho registro.Para ello, en bloque_asignaciones2 se realizan tales asignaciones, pero como lo que se hace esactualizar un registro (y no insertar uno nuevo), estas asignaciones aparecen rodeadas de “for each– endfor”, pues como hemos visto, las actualizaciones solo pueden realizarse dentro de un for each.

De no especificarse cláusula when duplicate para un new, si el registro que quiere insertarse seencuentra duplicado no se realizará acción alguna y la ejecución continuará en el comando

siguiente. Es decir, como no puede insertar el registro porque ya existe uno, no hace nada y sigueadelante, con el próximo comando.



Determinación tabla base del new:

• De existir, se consideran los atributos que seespecifiquen en la cláusula Defined by.

• Se consideran todos los atributos que aparezcanen bloque_asingaciones1 a la izquierda encomando de asignación.

• Estos atributos deben pertenecer a una mismatabla física tabla base


La tabla física en la que se insertará el registro del new (tabla base del new) se determina a partirde los atributos que aparecen en bloque_asignaciones1 del lado izquierdo del comando deasignación. Al igual que en el comando for each, se incluye la cláusula Defined by para agregarmás elementos que permitan determinar la tabla base. Es decir, la tabla base del new será aquellaen la que se encuentren físicamente almacenados los atributos att1,…, attN que figuran en lacláusula Defined by, junto con los que aparezcan en el bloque de asignaciones, del lado izquierdo.

Observar que marcamos en negrita “físicamente almacenados” y esto introduce una diferenciaimportante con respecto al comando for each: aquí, tanto los atributos del Defined by como los quese encuentren en asignaciones del lado izquierdo, deberán pertenecer a la tabla base (no a laextendida). Es más restrictivo, puesto que con el comando new estamos insertando un únicoregistro en una sola tabla de la base de datos.

GeneXus buscará una tabla física que contenga a todos estos atributos. De no existir tal tabla, alespecificar el procedimiento se desplegará un error en el listado de navegación informando de estasituación y el objeto no será generado.



Determinación tabla base del new:


A*BF

B*C

NewA = & AB = & B C = & C

endnew

¿Es correcto?

¿Cuál será elcomportamiento?

¡No!: no existe una tabla física que incluya los atributos A, B y C.

El New solo permite insertar UN REGISTRO en UNA TABLA.

El ejemplo pretende dejar claro a qué nos referimos con tabla física, en contraposición a tablaextendida.

Mientras que en el caso de la determinación de la tabla base del for each los atributos debíanpertenecer a una misma tabla extendida, en el New es más restrictivo: deben pertenecer a unamisma tabla física.



• Atributos asignados en el new

• No es necesario asignar valor a todos y cada uno de losatributos de dicha tabla.

• Algunos atributos vienen instanciados por el contexto delnew y no es necesario asignarles valor para el registro ainsertar.

• Contexto:• parámetros atributo

• new anidado a un for each

• new anidado a un new

• New siempre se ejecuta por la clave primaria.


Una vez que GeneXus determinó la tabla del new, los atributos pertenecientes a la misma y noasignados explícitamente dentro de este comando tomarán como valor:• Para aquellos que estén instanciados en el contexto donde se encuentra el new, tomarán losvalores correspondientes al contexto.• Para los que no estén instanciados en el contexto, tomarán el valor nulo (o empty, dependiendo dela propiedad “Empty As Null” en conjunción con la Nulls).

At r i bu t os i ns tanc iados en e l con tex t o :

Atributos recibidos por parámetroSi los atributos no asignados explícitamente en el new son recibidos en la regla parm, entonces parael registro a ser insertado toman el valor que viene en el parámetro.

New anidado a un for eachEl new es un comando como otros, por lo que puede aparecer anidado a un for each (es el caso enel que se quiere navegar determinada tabla, y para cada registro que cumpla determinadascondiciones dar de alta un registro en otra tabla que puede también ser la misma. Veremos unejemplo a continuación).En este caso, todos los atributos de la tabla del new que no estén asignados explícitamente y queestén instanciados en el for each que contiene al new, tomarán el valor que tienen en la instancia delfor each para el registro a ser insertado.

New anidado a otro new

Dentro del comando new puede aparecer otro new sobre la misma o distinta tabla. Los atributos delnew anidado que no estén asignados explícitamente y que estén en el principal tomarán sus valoresdel mismo.



• New anidado a un For each, con igual tabla base.


MDoctor I d* MDoctorNam e MDocto rAddress MDocto rPhone

MDoctor I d* Consu l t a t i onDate* Consu l t a t i onSh i f t * Consul ta t ionOf f iceNbr

“MedicalDoctor” “ConsultationHour” Date

Shift

M.Doctor’s office

Procedimiento que susti tuya al médico &SourceMD ( recibido porparámetro) en todas sus consultas, por el médico &r ep lacem entMD

For eachWhere MDoctorId = &SourceMDDefined by ConsultationDate

new

MDoctor I d = &r eplacem ent MD endnewDelete

endfor

Parm(&SourceMD,&replacementMD);

Queremos escribir el Source de un procedimiento que sustituya a un médico por otro para lasconsultas que el primero tenía asignadas.

Es decir, debemos recorrer la tabla CONSULTATIONHOUR que es la que representa las consultasasignadas a cada médico en una fecha y turno determinado, filtrando por el médico que debemossustituir, y luego reemplazar a ese médico por el sustituto para esos registros.

Haríamos una simple actualización de registro, a no ser por el hecho de que el atributo a sustituir esparte de la clave primaria, por lo que no podemos modificarlo.

Deberemos, por tanto, crear un nuevo registro con el médico sustituto, y el resto de los atributostomarán los valores del registro original. Luego borraremos el registro original, así queda el nuevoregistro, con el médico sustituto.

Observemos que dado que el new está anidado al for each, en el contexto del new existirán todos losatributos de la tabla extendida del for each. En este caso, estarán instanciados los atributos deCONSULTATIONHOUR y los de MEDICALDOCTOR, para un registro en particular.Es por ello que en el new solamente asignamos valor al atributo MDoctorId, pues los demás:ConsultationDate, ConsultationShift, ConsultationOfficeNbr están instanciados y queremos queconserven esos valores.

Sin embargo, aquí tenemos un problema. ¿Cuál elegirá GeneXus como tabla base del new?



• New anidado a un For each, con igual tabla base.



newMDoctor I d = &r eplacem ent MD

endnewDelete

endfor

¿Tabla base del new?


newdef ined by Consu l t a t i onDate

MDocto r I d = &r eplacem ent MD endnewDelete

endfor

CONSULTATIONHOUR

MEDICALDOCTOR

En este ejemplo lo que pretendemos mostrar es el cuidado que hay que tener cuando queremos queciertos atributos de la tabla base del new tomen sus valores del contexto.

Es decir, primero tenemos que asegurarnos que por los atributos que figuren dentro del new, quededeterminada la tabla base que deseamos, para que a partir de allí, sí puedan quedar implícitos losatributos del contexto.



Restricciones

• No se realiza control de integridad referencial.

• El único control que se realiza es el deduplicados.

• No actualiza atributos definidos como redundantes.

En los procedimientos el único control de integridad que se realiza automáticamente es el control deduplicados. El control de integridad referencial queda a cargo del programador, lo que no ocurre enlas transacciones. Por lo tanto, en el ejemplo anterior podríamos haber eliminado primero elcabezal, y luego las líneas, sin ningún problema. Incluso podríamos haber eliminado solo el cabezal,y estaríamos dejando referencias colgadas (las líneas).

Por ejemplo, al dar de alta por procedimiento una nueva factura, cuando se da de alta el cabezal nose controla que el valor de CustomerId ingresado exista en la tabla CUSTOMER.

Los atributos definidos como redundantes no se actualizan.

Un caso particular de ello son las fórmulas redundantes. Como en procedimientos no se actualizan,hay que calcularlas y actualizarlas en forma manual.

Las fórmulas redundantes deben ser mantenidas explícitamente con los comandos de asignación.

Por ejemplo, si en la transacción "Invoice" tenemos definido el atributo InvoiceTotal como unafórmula vertical redundante, siendo:

InvoiceTotal = SUM( InvoiceLineAmount )

y por procedimiento damos de alta una o varias líneas, debemos tener en cuenta que no seactualizará el valor almacenado de InvoiceTotal. Habrá que actualizarlo explícitamente en elprocedimiento, por cada línea dada de alta.



OBJETO WEB PANEL



Características

• Permiten definir consultas interactivas a la base dedatos.

• Son flexibles por lo que se prestan para múltiplesusos.

Los web panels son objetos GeneXus que permiten al usuario en tiempo de ejecución, realizarinteractivamente consultas a la base de datos a través de una pantalla.

El término “interactivamente” se refiere a que el usuario podrá ingresar en la pantalla de un web panel una yotra vez distintos valores de filtros, y consultar a continuación los datos que concuerden con los mismos.Además, sobre los datos consultados, el usuario podrá realizar distintas acciones, como veremos.

Los web panels no permiten la actualización de la base de datos, sino sólo su consulta1.

El objetivo primordial de este objeto GeneXus es la definición de consultas interactivas a la base de datos, sinembargo se trata de un objeto muy flexible por lo que se presta para diversos usos.

En este capítulo estudiaremos algunos detalles de este tipo de objeto.

--------------------------------------------------------------------------------------------------------------------1 A menos que se utilicen en combinación con los business components (estudiados más adelante)



Elementos

• Algunos de ellos son:

• Web Form• Reglas

• Condiciones

• Subrutinas

• Eventos

• Propiedades

• Ayuda

• Documentación

Los elementos de los web panels son:

Web Form: Cada web panel contiene un form Web, el cual debe ser diseñado por el analista agregándolevariables, atributos, así como otros controles, para que el usuario pueda interactuar con el mismo.

Reglas: Las reglas de un web panel permiten definir ciertos comportamientos puntuales de dicho objeto. Porejemplo, declarar qué parámetros recibe, definir qué variables no queremos que sean aceptadas en el formsino utilizadas para desplegar información, etc.

Condiciones: Es para definir las condiciones que deben cumplir los datos a ser recuperados (filtros).

Subrutinas: Son rutinas locales al web panel.

Eventos: Los web panels emplean la programación orientada a eventos. Este tipo de programación permitedefinir código ocioso, que se activa en respuesta a ciertas acciones provocadas por el usuario o por el sistema.En esta sección de un web panel es donde se define el código ocioso asociado a los eventos que pueden ocurrirdurante la ejecución del web panel.

Propiedades: Son características a ser configuradas para definir ciertos detalles referentes al comportamientogeneral del web panel.

Ayuda: Permite la inclusión de texto de ayuda, que los usuarios podrán consultar en tiempo de ejecución del

web panel.

Documentación: Permite la inclusión de texto técnico como documentación para los desarrolladores.



Clasificación de web panels

• Web panels de Entrada

• Web panels de Salida

• Web panels Mixtos

Todo web panel tiene un form asociado, y en el mismo, contrariamente al comportamiento del form de unatransacción, los atributos que se incluyan serán de salida, y las variables que se incluyan serán deentrada.

Es fácil de comprender que el objetivo del form de un web panel es exactamente el contrario al objetivo delform de una transacción, ya que:

• a través del form de una transacción se ingresan los valores de los atributos en la base de datos.• a través del form de un web panel, se consultan / recuperan los valores de los atributos de la base de datos.

Es por esto que los atributos son de entrada en las transacciones y de salida en los web panels.

Y en lo que respecta a las variables, las mismas son de salida en las transacciones y de entrada en los webpanels.

La siguiente clasificación describe los distintos usos posibles de los web panels:

· Web panel de entrada: le damos este nombre a un web panel que tiene la única función de aceptar valoresdigitados por el usuario (esto significa que su form contendrá únicamente variables).

· Web panel de sal ida: le damos este nombre a un web panel que tiene la única función de mostrarinformación (esto significa que su form contendrá únicamente atributos, pudiendo también contener variablesa las cuales se les haya cambiado el comportamiento por defecto de ser de entrada, definiéndolas de salida ycargándoles valores explícitamente).

· Web panel mixto: le damos este nombre a un web panel que permite tanto ingresar valores como mostrarinformación (en este caso su form contendrá tanto variables como atributos, o bien sólo variables, algunas conel comportamiento por defecto de ser de entrada y otras definidas explícitamente de salida y cargándolesvalores).

Vale aclarar que esta clasificación es independiente de la herramienta; es decir, GeneXus internamente noclasifica a los web panels.



Web panel de Entrada

Las variables adquieren el valor digitado luego depresionar algún botón.

Event Enter

Event EnterRList.call( &InitialCustomerName, &FinalCustomerName )

endevent

Denominamos web panels de entrada a aquellos web panels cuya única función es que el usuario realiceingresos de valores por medio de los mismos. Por lo tanto, sus forms contendrán solamente variables.

Por ejemplo, un web panel de entrada puede contener dos variables &InitialCustomerName y&FinalCustomerName como se muestra arriba. En tiempo de ejecución, el usuario podrá ingresar valores en lasvariables &InitialCustomerName y &FinalCustomerName dado que en los web panels las variables son pordefecto de entrada.

En el evento Enter del web panel (asociado al botón Confirm), se invocará a un reporte, al cual se le pasaránpor parámetro las variables &InitialCustomerName y &FinalCustomerName para que el reporte liste todos los

clientes cuyos nombres se encuentren en el rango solicitado:

Event Enter

RListCustomerRange.call( &InitialCustomerName, &FinalCustomerName )

EndEvent // Enter

De modo que la definición de este web panel de entrada es para que el usuario ingrese el rango de clientesa listar, y al seleccionar el botón Confirm, se ejecute el reporte correspondiente.



Web panel de Salida

Regla: parm(in:Cus tom er I d );

tabla base:

CUSTOMER

Denominamos web panels de salida a aquellos web panels cuya única función es exhibir datos.

Para que un web panel únicamente muestre datos, su form debe contener solamente atributos, ya que losatributos en los forms de web panels son indefectiblemente de salida1. Otra posibilidad es incluir en el formvariables, pero habrá que cambiarles su comportamiento por defecto de ser de entrada, a ser de salida, ycargarles valores explícitamente2.

El web panel mostrado arriba ha sido creado para exhibir los datos de un cliente. Se necesita invocarlo desdeotro objeto, pasándole por parámetro el código del cliente del cual se quiere mostrar la información.

Para resolver esto, una vez creado el web panel “View Customer Data”:

• se han agregado los atributos que se desean visualizar en su form

• se ha definido la regla: Parm( in: CustomerId); en la sección de reglas del objeto

Tan sólo definiendo esto obtendremos el comportamiento deseado.

¿Qué concluirá GeneXus acerca de este web panel, cuando lo especifiquemos?

Primeramente GeneXus observará que los atributos incluidos en el form pertenecen a las tablas CUSTOMER yCOUNTRY respectivamente. El siguiente diagrama de Bachman explicita la relación entre ambas tablas:

--------------------------------------------------------------------------------------------------------------------1 Al contrario de lo que sucede con los atributos en las transacciones (salvo los inferidos o los que tienen reglanoaccept o propiedad Enabled deshabilitada).2 El comportamiento por defecto de las variables también es opuesto entre Web Panels y Transacciones.

CUSTOMER COUNTRY



Teniendo en cuenta la relación entre las tablas involucradas, GeneXus descubrirá que deberá recorrer la tablaCUSTOMER y acceder a la tabla COUNTRY por el concepto de tabla extendida. La tabla COUNTRY no podrá serelegida para ser recorrida porque su tabla extendida no incluye a la tabla CUSTOMER.

Así es que GeneXus determinará un for each asociado al web panel, en este caso con tabla base CUSTOMER;nosotros no escribimos el for each, pero GeneXus lo infiere automáticamente.

A su vez, como en la regla parm definida en el web panel se recibe un atributo, el mismo actuará como filtro

por condición de igualdad. Es decir, que al ejecutarse la recorrida de la tabla CUSTOMER (accediendo a la tablaCOUNTRY para traer el nombre de país), se filtrará por el código de cliente recibido por parámetro.

Concluyendo, se recorrerá la tabla CUSTOMER, con condición de filtro por el cliente recibido en la regla parm yse mostrarán los datos en la pantalla. El nombre del país del cliente (CountryName) se inferirá por el conceptode tabla extendida y se mostrará también en la pantalla.

Decimos que este web panel tiene tabla base , y la misma es CUSTOMER. Esto significa que el web paneltiene un for each implícito / automático asociado, cuya tabla base es CUSTOMER.



Regla: parm(in:Cus tomer I d );

Web panel de Salida

grid: Se cargan losregistros de la base dedatos correspondientesen archivo temporal

tabla base:

INVOICE

Este web panel ha sido creado para mostrar las facturas de determinado cliente. Se necesita desde otro objeto,invocar a éste, pasándole por parámetro el código del cliente del cual se quieren mostrar sus facturas.

Para resolver esto, una vez creado el web panel “View Customer Invoices”:

• se han agregado los atributos que deseamos visualizar en su form (utilizando el control grid para mostrar lasN facturas del cliente en cuestión)

• se ha definido la regla: Parm( in: CustomerId); en la sección de reglas del objeto

Este web panel, a diferencia del anterior no es plano, pero continúa siendo un web panel de salida, ya que loúnico que hace es mostrar datos de la base de datos, sin permitir que el usuario ingrese nada.

Cuando se incluye un grid en un form, se está indicando que se va a mostrar una cantidad indefinida de datos(en este caso, facturas).

Dado que en este web panel hay involucrados atributos de las tablas CUSTOMER e INVOICE y que la relaciónentre ambas tablas es:

GeneXus determinará que recorrerá la tabla INVOICE y accederá a la tabla CUSTOMER por el concepto de tablaextendida. La tabla CUSTOMER no podrá ser elegida para ser recorrida porque en su tabla extendida no seencuentra la tabla INVOICE.

De modo que GeneXus determinará un for each implícito asociado al web panel, con tabla base INVOICE,accediendo a la tabla CUSTOMER por el concepto de tabla extendida.

Como en la regla parm definida en el web panel, se recibe un atributo, el mismo actuará como filtro porigualdad. Es decir, que al ejecutarse la recorrida a la tabla INVOICE accediendo a la tabla CUSTOMER, sefiltrará por el código de cliente recibido por parámetro.

Decimos que este web panel tiene tabla base, y la misma es INVOICE. Esto significa que el web panel tieneun for each implícito/automático asociado, cuya tabla base es INVOICE.

INVOICE CUSTOMER



Web panel Mixto: “Work With”

•Event Enter

•Evento Usuario

generales

versus

particulares

Lasvariablesadquierenel valor

digitadoluego depresionaralgúnbotón

Tabla Base:

CUSTOMER

Los web panels no tienen por qué ser sólo de entrada o sólo de salida. El web panel que se muestra arriba es deentrada/ salida (mixto), su form contiene tanto variables como atributos.

La funcionalidad de este web panel es cargar en el grid los datos de todos los clientes cuyos nombres cumplancon la condición de filtro especificada. La idea es digitar sobre la variable &CustomerName el valor de filtrodeseado, y a continuación presionar el botón Search para que se ejecute la consulta en el servidor y elresultado de la misma sea cargado en la página.

El evento asociado al botón Search puede ser el Evento Enter (evento del sistema) ó cualquier evento definidopor el usuario (volveremos sobre esto más adelante).

Las condiciones de filtro pueden definirse de dos maneras posibles:• A nivel de un grid en particular (botón derecho sobre el grid/Conditions): de hacerlo así, se tratará decondiciones particulares para ese grid (las que se muestran arriba).

• A nivel de todo el web panel (en la sección Conditions del objeto): de hacerlo así, se tratará decondiciones globales, es decir que aplicarán a todos los grids del web panel en los que tenga sentido aplicarlas(más adelante veremos web panels con múltiples grids).

En el web panel del ejemplo tenemos un sólo grid, por lo cual ambas opciones serían equivalentes desde elpunto de vista lógico. Sin embargo es recomendable escribir las condiciones a nivel del grid ya que en un futuropodrán agregarse más grids al web panel. Además teniendo las condiciones a nivel del grid se optimiza almomento de la especificación (ya que en caso contrario, GeneXus deberá estudiar para cada grid si aplicar lascondiciones generales a ese grid particular o no).

¿Qué lógica inferirá GeneXus al momento de la especificación del Web Panel?

Como los atributos involucrados en el web panel pertenecen algunos a la tabla CUSTOMER y otros a la tablaCOUNTRY, y en la tabla extendida de CUSTOMER está la tabla COUNTRY, GeneXus determinará que la tabla arecorrer es CUSTOMER y que accederá por su extendida a la tabla COUNTRY para cargar el valor del atributoCountryName. Es decir, GeneXus determinará un for each implíci to asociado al web panel, con tabla baseCUSTOMER.

Las condiciones definidas antes (a nivel de grid) se incluirán en el for each implícito (como cláusulas where),de modo tal que al ejecutarse la consulta, se recorrerá la tabla CUSTOMER, filtrando por dichas condiciones.

Es importante considerar que tanto en las condiciones globales del web panel, como en las condiciones locales aun grid de un web panel, es posible utilizar la cláusula when al igual que cuando se definen filtros en los objetosreportes y procedimientos.



• Decimos que un web panel es “con tabla base” cuando GeneXuspuede determinar un for each implícito asociado a él.

• Es decir, si bien el analista no escribe un for each explícitamenteen el web panel para efectuar la consulta, GeneXus lo determinaautomáticamente (por eso lo llamamos: for each implícito).

• Tabla base del for each implícito = Tabla base del web panel.

• Un Web Panel es “sin tabla base” cuando GeneXus no puededeterminar una tabla de la base de datos a recorrer para mostrarla información que se presenta en el form.

• En este caso en el form solamente aparecen variables (y no

atributos).

Web panel ¿con tabla base?

Un web panel es con tabla base cuando de los atributos que aparecen, GeneXus puede determinar una tablade la base de datos a recorrer para, recuperando sus registros, mostrar la información que aparece en losatributos del web panel.

De este modo, es como si hubiéramos escrito un for each para navegar esa tabla base y trabajar con algunosatributos de la misma, y de la extendida.

Si en el Web Panel no aparecieran atributos, sino solo variables, evidentemente GeneXus no podrádeterminar una tabla a ser navegada. En este caso el web panel será sin tabla base.



Orden de los datos a recuperar

• Botón derecho sobre el grid:

Para definir que una consulta se efectúe ordenando por ciertos atributos, y por ende que los datos extraídos de laconsulta se muestren ordenados con dicho criterio, se debe hacer clic con el botón derecho del mouse sobre elgrid, y seleccionar el ítem Order del menú pop up que se muestra arriba.

A continuación, se presentará el diálogo para que se ingresen los atributos por los que se desea ordenar.

Definir esto es equivalente a definir la cláusula order en el comando for each, y se aplica todo lo visto en dichotema: desde que para ordenar en forma descendente por un atributo se debe encerrar el atributo entreparéntesis (), la creación de índices temporales cuando no exista un índice físico correspondiente a los atributosde ordenamiento, así como la posibilidad de utilizar la cláusula when para condicionar la aplicación de ese order.

En nuestro web panel “Work With Customers” ordenamos los clientes que se listan en el grid por CustomerName.

El poder definir order para un grid permite entre otras cosas optimizar la consulta, cuando se establecencondiciones de filtro. Así, si en las conditions generales y/o las del grid particular, siendo la tabla base CUSTOMERestablecemos los filtros, teniendo dos variables ingresadas por el usuario:

CustomerName >= &customerStartName;

CustomerName <= &customerEndName;

Entonces, de no especificar un orden por Cus t omerName , se deberá recorrer toda la tabla, de principio a fin,para cargar los registros que cumplan con las condiciones. Especificando un order optimizamos la consulta.

Nota: Solamente si el form del web panel no tiene ningún grid (atributos sueltos), y se necesita definir un ordenespecífico para la consulta, se contará con la posibilidad de definir en la sección de reglas del web panel, la reglade sintaxis: order(att1, att2, attN); siendo att1, att2, attN: la lista de atributos que define el orden de laconsulta.



Eventos en web panels

• En los web panels se utiliza la programación dirigida poreventos.

• Eventos disponibles en web panels:

– Evento Start– Evento Refresh– Evento Load– Evento Enter– Eventos de Usuario

– Evento Click asociado a control

Dado que la programación de los Web Panels está dirigida por eventos, para poder programar adecuadamenteun objeto de este tipo es necesario conocer los eventos existentes y el momento y orden en que éstos sedisparan.



Evento Start

• Es un evento del sistema, que ocurre automáticamente siempreque se hace Get o Post y es el primer evento que se ejecuta.

• No se conocen valores de atributos, salvo los recibidos porparámetro. Esto se debe a que aún no se ha efectuado laconsulta.

• Ejemplo: se puede utilizar para que un control del form noaparezca visible, para cargar un bitmap, para asociarle un Link aotro control, etc.:

Event Start&var.Visible = 0&Update = LoadBitmap("images/edit.gif")newControl.Link = Link(TCustomer)

endevent

En el ejemplo, tendremos 3 controles en el form: la variable de nombre var, la de nombre Update de tipoBitmap y un control de nombre newControl que puede ser, por ejemplo, un control imagen.

En el evento Start se le asigna a la propiedad Visible del control variable &var el valor 0, indicando que nodeberá verse en el form.

A su vez, a la variable de tipo bitmap, &Update, se le carga la imagen que contendrá, y al control quesuponemos imagen, newControl, se le define la propiedad Link, de manera tal que cuando el usuario hagaclic sobre el control, se invocará a la transacción Customer.



Evento Refresh

• El evento Refresh es un evento del sistema

• Se ejecuta cada vez que se realiza un Get o Post.

• Provoca que se ejecute la consulta a la base dedatos.

• Es decir, al ocurrir el evento Refresh, se ejecuta locodificado en dicho evento, y a continuación se ejecutala consulta a la base de datos. Viene seguido siempredel evento Load.



Evento Load

• Cada vez que se ejecute el evento Refresh en un web panel,

seguidamente se ejecutará el evento Load.

• La cantidad de veces que el evento Load será ejecutado,dependerá de si el web panel tiene tabla base o no la tiene:

• Tiene tabla base:• Cuando aparecen atributos que le permiten automáticamente

determinar que se desea navegar una tabla determinada de labase de datos

• El evento Load se ejecutará N veces

• No tiene tabla base:• Cuando no ocurre lo anterior (en el form solo hay variables)• El evento Load se ejecutará solamente una vez.

Cuando el web panel es con tabla base, al producirse el evento Refresh se accede a la base de datos, a esatabla base (la asociada al web panel), y se la recorre cargando los registros que cumplan las condiciones(conditions del grid y generales). Ocurrirá en ese proceso un evento Load por cada registro en el que seesté posic ionado, inmediatamente antes de cargarlo. Esto nos permite realizar alguna operación querequiera de ese registro (y de su extendida), antes de efectivamente cargarlo en el grid. Inmediatamenteluego de ejecutado el código asociado al evento Load, se cargará la línea del grid y se pasará el puntero alsiguiente registro de la tabla base, para realizar lo mismo (evento Load, carga de la línea). Este proceso se

repetirá hasta cargar todas las líneas del grid.

Si un web panel es sin tabla base, GeneXus no puede determinar automáticamente una tabla de la base dedatos a recorrer para mostrar la información que se presenta en el form. En este caso en el form solamenteaparecen variables (y no atributos) y también ocurrirán los eventos Refresh y Load, sólo que el evento Loadse ejecutará una única vez, dado que no se estará posicionado en ningún registro de ninguna tabla.



Evento Loaden web panel con tabla base

Luego delevento Refreshse ejecuta elevento Load Nveces:

una vez por cadaregistro de latabla base leídopara ser cargadoen la línea delgrid

Por cada registro leído en la consulta efectuada a la base de datos, se disparará el evento Load (ejecutándoseel código incluido en el mismo, y cargándose a continuación una línea en el grid con los datos asociados alregistro).



Evento Loaden web panel con tabla base: ejemplo

Si en el grid que muestra los clientes que cumplen con las condiciones de filtro, quisiéramos agregar unacolumna al final, que marque que el cliente es moroso (deudor) si su saldo es mayor a $10.000, es decir, queen ejecución sobresalga su condición de moroso apareciendo un literal DEBTOR en ese caso, alcanza conagregar una variable &type al grid, de tipo Character(10) y cargarla en el evento Load del web panel como semuestra arriba.

Para cada registro de la tabla base CUSTOMER que se vaya a cargar como línea en el grid, se ejecutará el

código del evento Load, cargándose en la columna &type el valor DEBTOR únicamente si el saldo de esecliente que va a listarse supera los $10.000.

Luego, si para cada cliente del grid además de mostrar su nombre, país, sexo, saldo y tipo, queremosmostrar la cantidad de facturas que se le han emitido, alcanza con agregar una variable &quantity al grid, eincluir en el código del evento Load, el for each para contar esas facturas.

Observar que el for each definido en el evento Load estará anidado al for each implícito (el de la tabla base),por lo que se efectuará un join, recorriéndose solamente las facturas de ese cliente, el que se está cargando.



Evento Loaden web panel sin tabla base

• En un web panel sin tabla base, el evento Load se ejecutará solamente una vez.

Evento Refresh

Evento Load

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



Evento Loaden web panel sin tabla base: ejemplo

Comando (que solo puede ir dentro deevento Load) para efectivamentecargar una línea con el valor quetengan las variables en ese momento.

El objetivo del comando LOAD dentro del evento Load es cargar efectivamente una línea en el grid.

Una vez que se hayan asignado valores a todas las variables que sean necesarias, y se desee agregar la línea algrid, deberá ejecutarse el comando LOAD.

Solamente se puede especificar el comando LOAD dentro del evento Load del grid de un web panel y enningún otro lado.

Event Load

for each&CustomerId = CustomerId

&CustomerName = CustomerName

&CustomerGender = CustomerGender

&CustomerBalance = CustomerBalance

if CustomerBalance > 10000&type = ‘DEBTOR’

else&type = ‘’

endif &quantity = 0

for eachdefined by InvoiceDate

&quantity += 1endforLoad /* LUEGO DE HABER CARGADO TODAS LAS VARIABLES CON LOS VALORES

CORRESPONDIENTES A LA LÍNEA A SER CARGADA EN EL GRID, DEBEMOS INCLUIR EL COMANDO LOAD,EL CUAL AGREGARÁ EFECTIVAMENTE LA LÍNEA AL

GRID. */endfor

Endevent

Si en la codificación del evento Load definimos comandos For each y asignamos valores a las variables en lasiteraciones pero no incluimos el comando LOAD, en tiempo de ejecución estaremos asignando una y otra vezvalores a las variables, pero no se estarán agregado líneas en el grid (solamente quedará una línea en el gridcon los últimos valores cargados en las variables). Por esta razón es muy importante no olvidar escribir estecomando en el lugar apropiado.



Evento Enter

• Cuando se inserta un nuevobotón en el form de un Web

Panel, por defecto aparece conel Caption “Confirm” y apareceasociado al evento del sistemaEnter.

• El evento Enter puedeasociarse a cualquier botón,atributo, imagen, text block, enla propiedad de los controles:OnClickEvent.

• De modo que si se necesitaejecutar acciones cuando elusuario final haga clic en el

control asociado, en esteevento deberán codificarse.



Eventos de usuario

• Además de los eventosofrecidos por GeneXus, el

analista puede definir eventoscreados por él, llamadoseventos de usuario.

• Cada evento de usuario debeasociarse a un control insertadoen el form del web panel de losque soportan el OnClickEvent(botones, text blocks,imágenes, atributos)

• En tiempo de ejecución, elevento de usuario ocurriráluego de que el usuario haga

clic sobre el control asociado almismo.

Casi todos los controles que aparecen en el form brindan la posibilidad de disparar un evento cuando elusuario hace clic con el mouse sobre ellos (aparecen como hipervínculos en ejecución); se consigue de dosmaneras distintas:

1. Editando las propiedades del control, y definiendo un evento de usuario en la propiedadOnClickEvent

2. Dándole un nombre al control y en la sección de Eventos programando:

Event nombreControl.click

…

Endevent

Con esta última alternativa no tendremos que definir un evento de usuario, sino que

estaremos programando el evento click del control.



Web panel "Work With Customer”

Acciones sobre

el cliente

seleccionado

Para que el web panel con el que venimos trabajando sea un verdadero “trabajar con” se le deben agregaracciones a ser efectuadas sobre los clientes: la posibilidad de insertar un nuevo registro (nuevo cliente), elmodificar uno existente, o el eliminarlo (así como también poder simplemente “visualizarlo”).

Una forma de implementar esto es agregar los cuatro botones que aparecen arriba, en el form:

. un botón que ofrezca insertar un cliente (Insert)

. un botón que ofrezca modificar un cliente (Update)

. un botón que ofrezca eliminar un cliente (Delete)

. un botón que ofrezca visualizar los datos de un cliente (View)

Además debemos permitir la selección de una línea de la grilla para aplicarle alguna de las accionesdefinidas en los botones del form. Para ello, accedemos a las propiedades de la grilla con botón derecho sobre elcontrol grid y configuramos la propiedad AllowSelection con el valor ‘True’ como muestra la figura. Al hacerlose nos habilitan tres propiedades más, que permiten especificar SelectionColor: el color que tendrá la líneacuando el usuario la seleccione (haciendo clic con el mouse sobre la misma); AllowHovering: la posibilidad deque cambie el color de las líneas cuando el usuario se desplaza con el mouse sobre ellas, y HoveringColor: elcolor que tendrá una línea cuando el mouse pasa sobre ella. Estas funcionalidades se implementan con código

javaScript que se envía al Browser al ejecutar el Web Panel.

En la sección de eventos del web panel, definiremos el código asociado a estos botones. Lo veremos en lapágina siguiente.



Eventos de usuario en el web panel “Work With Customer”

Event ‘Insert’ Tcustomer.call(‘INS’, 0)

Endevent

Event ‘Update’

Tcustomer.call(‘UPD’, CustomerId )

Endevent

Event ‘Delete’

Tcustomer.call(‘DLT’, CustomerId )

Endevent

Event ‘View’

Tcustomer.call(‘DSP’, CustomerId )

Endevent

En las reglas de latransacción “Customer”:Parm(&Mode , &CustomerId );

Variable del Variable desistema usuario

CustomerId = &CustomerId if not&CustomerId.IsEmpty();

La variable &Mode es del sistema y su tipo es Character(3). Tiene la particularidad de “entender” 4 valores:

• ‘INS’: este valor indica ‘ejecutar la transacción en modo Insert’ • ‘UPD’: este valor indica ‘ejecutar la transacción en modo Update’ • ‘DLT’: este valor indica ‘ejecutar la transacción en modo Delete’ • ‘DSP’: este valor indica ‘ejecutar la transacción en modo Display’

¿Cuál es el resultado de recibir por parámetros en una transacción el modo de ejecución y la clave primaria?El permitir insertar, modificar o eliminar puntualmente una instancia y luego retornar al objeto llamador.

Es por ello que en todos los eventos definidos en el Web Panel “Work With Customer” estamos invocando a latransacción “Customer”, pasándole dos valores por parámetro: un literal de 3 letras, que es el modo y el códigode cliente correspondiente a la línea del grid que fue seleccionada (por ello necesitamos habilitar la selección delíneas del grid, mediante la propiedad AllowSelection que vimos antes).

En definitiva la regla parm a definirse en la transacción "Customer", es:

parm(&Mode, &CustomerId);

Como se puede observar, no recibimos el código de cliente directamente en el atributo CustomerId, sino en unavariable. ¿Por qué?Si declaráramos el atributo CustomerId en vez de una variable, el valor que se recibiera en él actuaríaautomáticamente como filtro por igualdad. Sin embargo cuando invocamos a la transacción "Customer" con losparámetros ‘INS’ y 0, el modo ‘INS’ indica que queremos que la transacción se ejecute en modo insert; y comoen dicho caso no tenemos que enviar el código de cliente para instanciarlo, completamos el segundo parámetrocon valor 0 (porque la cantidad –y el tipo de datosde los parámetros enviados, debe coincidir con la cantidad –y el tipo de datosde los parámetros recibidos). De modo que el valor 0 es para completar el parámetrosimplemente, no para que se filtre por él tratando de instanciar un cliente de código 0.En los otros 3 casos en que se invoca a la transacción "Customer" (con los parámetros ‘UPD’ y CustomerId ;

‘DLT’ y CustomerId ó ‘DSP’ y CustomerId respectivamente) sí se quiere filtrar por el valor del código de clienterecibido; pero basta que haya un caso en el cual se invoque a la transacción y que no sirva filtrar por el valorrecibido, para que no sirva recibir el parámetro en el atributo y esa es la razón por la cuál se está recibiendo enuna variable. Si la clave primaria, CustomerId es autonumerada, entonces en ese caso sí podrá recibirse enatributo.

Recuerde que a partir de la inclusión de la regla parm en un objeto, éste desaparece del Developer Menú,debido a que desde el mismo no es posible el envío de parámetros.



Web panels - Funcionamiento

• Esquema de trabajo en Internet: el servidor no sabe

lo que se está haciendo en el Browser, hasta que sesometa la página. Es decir, hasta que se dispare unevento (enter, de usuario, click).

• Orden de disparo de eventos: es diferente si setrata de la primera carga del web panel (Get) o siya estaba cargado cuando se dispara un evento deusuario, enter, click (Post)

Es importante entender que en Internet, cuando el usuario accede a una página del servidor Web paravisualizarla, el Browser baja la página al cliente. Por lo tanto, no existe forma de detectar lo que realiza elusuario: el servidor Web volverá a tener el control cuando se dispare el evento ENTER o algún evento de usuarioo click. En ese momento se envía (se somete, se hace un post) el resultado al servidor para continuar con suprocesamiento. Es decir, una vez que el objeto web finaliza la ejecución en el servidor, no queda en memoria.Como consecuencia, la forma en que programamos este tipo de aplicaciones presenta algunas diferencias conrespecto a lo acostumbrado en ambientes no web.

Es por esta razón que es importante destacar el orden en que se disparan los eventos y el momento en que lasvariables adquieren el valor ingresado por el usuario.

El orden de ejecución de los eventos en web panels es diferente si se trata de la primera llamada al mismo (GET)o si se disparó algún evento de usuario, enter o click (POST).



GET: Orden de disparo de eventos

• Al ejecutar un web panel por primera vez se

disparan los siguientes eventos:

• Start• Refresh• Load

La primera vez que se ejecuta el web panel (se conoce también como el momento en que se hace el “GET” de la página) los eventos que se disparan son los siguientes y en el siguiente orden:

1. Start

2. Refresh

3. Load

Luego de esto, cuando el usuario haga clic sobre un control que tenga asociado el evento Enter o uno de usuarioo click se ejecutará nuevamente el web panel y el orden de disparo de los eventos será diferente, como se indica

en la siguiente página.



POST: Orden de disparo de eventos

• Start• Lectura de variables

en pantalla• Evento Enter o de

usuario (submit)• Refresh• Load

• Resto de las ejecuciones del web panel:

En el resto de las ejecuciones del web panel, que ocurren cuando se presiona un botón, o se fuerza la ejecucióndel evento asociado a una imagen, text block, etc. (haciendo clic sobre el control que tiene asociado el evento deusuario o Enter o click) momento que se conoce también como el “POST” de la página, los eventos se dispararánen el siguiente orden:

1. Start (nuevamente se dispara el evento Start)

2. Lectura de las variables de la pantalla. Esto se realiza porque el usuario puede haberlas modificado (porejemplo las variables de la parte fija del web panel que están involucradas en las conditions, como en el ejemploque se presenta arriba, donde se quieren cargar en el grid los clientes cuyo nombre contenga el string cargado

por el usuario en la variable &CustomerName)3. Evento Enter o click o evento de usuario (código correspondiente al evento asociado al control que se presionóy produjo el POST).

4. Refresh

5. Load

En el ejemplo no necesitamos codificar nada en el evento asociado al botón Search. Solo lo pusimos para poderenviar al servidor la variable con el valor que ingresó el usuario y que la página se refresque cargando en el gridlos clientes que cumplan con el filtro que el usuario estableció mediante esa variable.



Web panels - Variables

• Variables: adquieren valor ingresado por el usuario luego desometido evento (POST)

• Si en un evento se usa una variable que se carga en otroevento la variable debe estar en el form, y además debeestar después del control en el que se carga su valor.

• Ejemplo:

Event Load

&cont+=1

endeventEvent Enter

if &cont<5

…

endevent

Event Refresh

&cont= 0

endevent

Relacionado con el orden de disparo de los eventos, es importante destacar el momento en que las variablesadquieren los valores ingresados por el usuario: solamente lo harán después de presionar un botón1 (que escuando el servidor Web tiene el control del procesamiento).

Por ejemplo, cualquier Link especificado en el evento Start a otro web panel con una variable que se ingresa en elform no va a tener ningún valor cuando se haga clic sobre el Link.(Ej: control.Link = HWebPanelX.Link(&var). No se debe escribir esto en el start si la &var esta en el form, porqueal momento de armarse el link no se tiene el valor de la variable)

Si en un evento se usa una variable que se carga en otro evento, entonces esa variable debe estar presente en elform. Si no está en el form, la variable no tendrá valor cuando se disparen los eventos que la consultan (esto espor el “orden” en que ocurren los eventos).

Además, deberá estar en el form después del control en el que se carga. Por ejemplo, si la variable se carga en elLOAD de un grid entonces la variable tiene que estar en pantalla después del grid.

Ejemplo: web panel con grid que lista las facturas existentes, y queremos contar la cantidad de facturas que selistan en el grid. Para ello definimos una variable &cont que debemos incrementar cada vez que se carga unanueva línea, es decir, en el evento Load del grid.

Para que la variable se cargue correctamente, deberá incluirse luego del grid, puesto que de lo contrario ya sehabrá dibujado en la página, antes de que pueda ser cargada por el evento Load.

Gracias a tenerla en el form, cuando el usuario presione el botón Confirm que consulta por el valor de la variable,la misma podrá tener el valor cargado antes por el Load.

Recordemos que al presionar el botón Confirm se realizará un POST al servidor, y en él se dispararán Start,lectura de variables de pantalla (aquí se leerá el valor de &cont que había sido cargado antes por el evento Load),luego se disparará el evento Enter asociado al Confirm y dentro del mismo se consulta por el valor de la variable,que gracias a que fue enviada al servidor por estar en el form, tiene el valor que se había cargado antes. Luegose dispararán Refresh y Load.Observemos que aquí, cuando se dispare el Load, se incrementará la variable, por lo que deberemos resetearlaantes de que se empiecen a cargar las líneas, porque de lo contrario mostrará el doble de las líneas que teníaantes. ¿Dónde resetearla?

Event Refresh&cont = 0

endevent-----------------------------------------------------------------------------------------------------------------------1 O hacer clic sobre algún control del form que tenga un evento de usuario o click o Enter asociado (ya sea con lapropiedad Link, o la propiedad OnClickEvent, o el evento click).



Ejemplo: Supongamos que tenemos un web panel donde en un sector del form se puede ingresar usuario ycontraseña para loguearse al sistema.En el evento donde validamos el usuario y la contraseña (asociado a algún botón o text block), guardamos enuna variable el código de usuario para poder utilizarlo en otro evento. Esto nos permitiría, por ejemplo,llamar a un objeto que permita visualizar los datos del usuario (por ejemplo un web panel de nombre

“CustomerData”, que recibirá por parámetro el identificador de cliente).En consecuencia, primero que nada, deberíamos programar lo siguiente en el evento donde validamos elusuario:

Event ‘Login’ For eachWhere CustomerUser = &CustomerUser

If CustomerPassword = &CustomerPassword

&CustomerId = CustomerId

Mensaje.Caption = ‘Bienvenido/a ’+trim(CustomerName)Else

Mensaje.Caption = ‘La contraseña ingresada no es correcta’ Endif When none

Mensaje.Caption = ‘El usuario ingresado no existe’ Endfor

Endevent

donde Mensaje es el nombre de un text block que dinámicamente (con la propiedad Caption) cambia detexto.Obsérvese que tenemos una tabla CUSTOMER que contiene la info de usuario y password.

Para realizar la llamada al web panel Datos del Cliente (CustomerData), existen varias alternativas, una delas cuáles sería agregar un botón o una imagen con un evento click asociado (o definir un evento de usuarioy asociárselo al control mediante la propiedad OnClickEvent), entonces el código seria el siguiente:

Event Ver.clic // “ver” es el nombre de la imagen o botón.HCustomerData.Call(&CustomerId)

Endevent

Repasemos entonces lo que ocurre:

1. En la primera ejecución se disparan los eventos: Start, Refresh y Load y podemos ingresar el usuario ypassword en las variables respectivas.2. Cuando presionamos el botón o text block para validar el login, se dispara el evento Start, se leen lasvariables anteriores que están en pantalla, se ejecuta el código del evento Login, donde se asigna a lavariable &CustomerId el código de cliente del usuario correspondiente. Luego ocurren Refresh y Load y lapágina se despliega en el Browser.3. Ahora, ya estando logueados, cuando presionamos la imagen o botón con el evento click asociado, sedispara el evento Start, se leen las variables que están en pantalla, se ejecuta el evento click y ahí cuandoredireccionamos al Web Panel CustomerData, la variable &CustomerId no tiene valor alguno, ya que la mismase perdió luego de haber finalizado la ejecución del Web Panel en el punto 2.

Es por esta razón que si queremos disponer del valor de la misma, deberíamos agregar la variable&CustomerId en el form y la ocultaríamos usando la propiedad Visible (por ejemplo en el evento Start).

Event Start&CustomerId.Visible = 0

Endevent

Entonces en este caso, cuando el Web Panel ejecute por segunda vez, se dispararán los eventos:1. Start2. Se leen las variables del form (en este momento se obtiene el valor de & CustomerId)3. Se ejecuta el evento click, y por consiguiente se llama al Web Panel con el código de cliente correcto.

Esto es porque no existe un concepto de “memoria local” para los web objects, por lo cual, si en un evento seusa una variable que se carga en otro evento, entonces esa variable debe estar presente en el form, demanera que, aprovechando el orden de disparo de los eventos en el POST, se obtenga el valor de la variable.



Definición de columnas ocultasen el grid de un web panel

• Al hacer botón derecho sobre el grid y seleccionar Columns:

•Editar las propiedades de la columnaque se quiere ocultar:

Hay veces que por motivos de presentación, no se desea incluir ciertos atributos o variables como columnasvisibles de un grid, pero se necesita tener sus valores cargados en columnas ocultas.

¿Por qué motivo se puede necesitar def inir una columna oculta en el gr id de un web panel?

Un grid siempre tiene un archivo temporal asociado.

Cuando en un Web Panel se ejecuta el evento Refresh, se comienza a ejecutar la consulta a la base de datos; acontinuación por cada registro leído que cumpla con las condiciones de filtro definidas, se ejecuta el evento Loady se cargan los datos de dicho registro, en el archivo temporal asociado al grid.

¿Qué datos de los registros se cargan en el archivo temporal? Es decir, ¿qué columnas contendrá el archivotemporal? Una columna por cada atributo o variable mostrado en el grid, más una columna por cada atributo ovariable declarado en el grid como columna oculta.

A modo de ejemplo, si en un grid hay 2 columnas visibles con los atributos CustomerName y CustomerBalance yninguna columna oculta, el archivo temporal asociado al grid contendrá 2 columnas correspondientes a losatributos CustomerName y CustomerBalance, respectivamente. Si además de esas 2 columnas visibles, sedeclara el atributo CustomerId como columna no visible en el grid, el archivo temporal asociado contendrá 3columnas correspondientes a los atributos CustomerName, CustomerBalance y CustomerId, respectivamente.

Si en el grid sólo incluimos 2 columnas visibles con los atributos CustomerName y CustomerBalance, en el casoen que necesitemos en un evento de usuario conocer el valor del atributo CustomerId correspondiente al clientede cierta línea seleccionada (para escribir alguna sentencia utilizándolo), no lo tendremos. Para conocer en unevento de usuario el valor del atributo CustomerId correspondiente a cierta línea seleccionada, tendremos queincluirlo en el grid ya sea visible o no visible, pero debe estar presente.

Como ejemplo, pensemos en nuestro Web Panel “Work With Customers”: necesitábamos una vez que el usuarioseleccionaba una línea, y presionaba el botón “Update” llamar a la transacción “Customer” enviándole comoparámetro el CustomerId seleccionado. En este caso necesitamos tener el CustomerId en el archivo temporal, yasea que esté visible en el grid o no lo esté.

¿Cómo ocultar una columna en un grid?Para ocultar una columna en un grid, debemos configurar la propiedad Visible del atributo o variable que sedesea ocultar con valor ‘False’ . Para ello, debemos hacer clic con el botón derecho del mouse sobre el grid yseleccionar las columnas (Columns) de la grilla; se abrirá el diálogo mostrado. Luego, habrá que posicionarse enel atributo o variable que se desee definir como columna oculta, y editar sus propiedades (Properties). Porúltimo, se debe configurar la propiedad Visible de la columna con valor False.



De modo que el motivo por el cual podemos necesitar incluir un atributo o variable como columnaoculta de un grid, es porque necesitemos conocer el valor de ese atributo o variable en un eventode usuario, pero no deseemos mostrarlo.

Así como los eventos de usuario trabajan con los datos cargados en el archivo temporal asociado algrid, las condiciones de filtro en cambio, trabajan sobre la tabla física consultada y su tablaextendida; por lo tanto, al definir condiciones de filtro, se podrán referenciar atributos quepertenezcan a la tabla física que se consulta y su tabla extendida, sin la necesidad de que dichos

atributos deban estar incluidos en el grid (ni visibles ni ocultos) ni en ninguna otra sección del webpanel.

Por ejemplo, piénsese en el ejemplo que ya presentamos antes:

Event Load

if CustomerBalance > 10000

&type = 'DEBTOR'

else

&type = ''

endif

endevent

Aquí surge la pregunta: como en este evento utilizamos el atributo CustomerBalance para podercargar adecuadamente la variable, ¿es necesario colocarlo oculto en el grid? La respuesta es no . Enel evento Load estamos posicionados en un registro de la tabla base. Tenemos a disposición todoslos atributos de esta tabla base y de la extendida, sin necesidad de cargarlos luego en el grid.



Comando FOR EACH LINE

GeneXus nos provee el comando For each l ine para recorrer laslíneas de un grid en un web panel:

in NombreGrid: solamente es necesario explicitarlo cuando hay másde un grid en el form del web panel.

Sentencia 1, …, Sentencia N: sentencias a ejecutarse para cadalínea recorrida del grid.

for each l ine [in gridName]Sentencia 1

……

Sentencia N

endfor



Event ‘Delete’ for each line

if &dlt = ‘Y’ PDelCustomers.call(CustumerId)

endif endfor

Endevent

Comando FOR EACH LINEEjemplo

A continuación, implementaremos un caso de selección múltiple, una operativa diferente a la presentada en elcaso del web panel Work With Customer, que permitía seleccionar una única línea por vez (selección simple).

La operativa que pretendemos ofrecer en el web panel DelCustomers presentado arriba es la siguiente: luego deque el usuario haya ingresado un substring para filtrar los clientes y se haya cargado el grid con los clientes quecumplan dicho filtro, el usuario podrá marcar (con un clic del mouse) qué líneas (clientes) desea eliminar.

En el ejemplo, hemos incluido en el grid del web panel “DelCustomers", una variable de nombre & dlt (definidacomo check box), además de los atributos CustomerId, CustomerName, CountryId, CountryName yCustomerAddress. De esta forma, el usuario seleccionará el check box en los clientes que desea eliminar. A suvez, tendríamos que tener un botón "Delete" y en el código del evento asociado a dicho botón deberíamos

recorrer el grid y para cada línea seleccionada invocar a un procedimiento que haga la eliminación física de dichocliente.

A continuación incluimos el código del procedimiento DelCustomers que recibe en la regla parm el código delcliente a eliminar (CustomerId).

Reglas:

Parm(CustomerId);

Source:

for each

defined by CustomerName

Delete //se elimina el cliente recibido como parámetro

Endfor



Variables en un grid

• Por defecto todas las variables de un grid sonRead-Only

• For each line [in grid], evento click, OnClickEvent:modifica valor por defecto y todas las variablesdel grid pasan a ser de entrada.

• Propiedad: Read Only para que alguna sea desalida.

Cómo des p lega r da t os en u n g r i d

Por defecto todo atributo y variable que está dentro de un grid se despliega en ejecución como texto, es decir quees únicamente de lectura y por consiguiente no puede ser modificado.

Cómo ac ep t a r da t os en un g r i d

Es posible aceptar datos en las variables de un grid dependiendo de la programación de los eventos existentes enel objeto:

1. Si dentro de un evento del web panel se está utilizando el comando For each line, todas las variables queestán dentro del grid pasan a ser de entrada. Es posible indicar en este caso cuáles son las variables que no

van a poder ser modificadas (Ver más abajo).2. Si dentro de la fila hay algún control con un evento click asociado (ó evento de usuario especificado en la

propiedad OnClickEvent).

Cómo ind i c a r que una v a r i ab le no puede s e r m od i f i c ada

1. Para indicar que el valor de una variable en un grid no puede ser modificado, debemos configurar la propiedadRead On ly de la variable con valor ‘True’ . Para ello, debemos hacer clic con el botón derecho del mousesobre el grid y seleccionar las columnas (Columns) de la grilla. Luego, habrá que posicionarse en la variableque se desee definir como de sólo lectura, y editar sus propiedades (Properties). Por último, se debeconfigurar la propiedad Read Only de la columna con valor True.

2. Utilizando la regla Noaccept()



Diferentes tipos de grilla/grid

• Grid estándar: datos repetitivos en formato fijo (línea,columna)

• Grid Freestyle: datos repetitivos en formato libre

Se dispone de dos tipos de grilla:

• Grilla estándar: la que vimos hasta ahora, en Transacciones y Web Panels

• Grilla Freestyle

Estas grillas, agregan potencia al diseño de aplicaciones web, permitiendo al desarrollador mayor libertad a lahora del diseño.



Grid estándarPropiedades:

Establece si el grid secargará o no porpáginas (paginado).

Indica cantidad defilas por página.

0 todas (no habrápaginado) Permite

selección delínea del grid

Los grids permiten trabajar con datos repetitivos en web panels y transacciones con form HTML. Las columnas dlos grids pueden ser atributos, variables (incluyendo las de tipo bitmap), y siempre tendrán una primera fila qucorresponderá a los títulos de las columnas.

En ejecución, el grid será una tabla HTML.Para interiorizarse de cada una de las propiedades configurables de un grid, sugerimos acceder al Help dGeneXus. Aquí solo mencionaremos algunas como ejemplo:

ControlName: Permite indicar el nombre del control. Siempre se le asigna un nombre por defecto.

Class: Clase (del tema asociado al objeto) asociada al control. La propiedad Class solo se encuentra disponible si econtrol está en el form de un objeto que tiene un Tema asociado.

BackColorStyle: Permite asignar un estilo al grid. Los estilos disponibles son:1. None: el grid no tendrá un estilo particular, sino que tendrá el diseño del form o del control que lo contenga.2. Header: permite especificar un color para el fondo de los títulos del grid y otro para las líneas del mismo. Lapropiedades son LinesBackColor y TitleBackColor.3. Report: permite especificar un color para el fondo de los títulos y alternar colores para las líneas pares e imparedel grid. Las propiedades son LinesBackColor, LinesBackColorEven y TitleBackColor.4. Uniform : permite especificar un único color para el fondo del grid(tanto el título como las líneas).

Dependiendo del valor de la propiedad “BackColorStyle”, estarán disponibles otras propiedades adicionalerelacionadas con la configuración de las líneas del grid.

Rows: Esta propiedad permite al usuario indicar la cantidad de registros que va a cargar en el grid. Aplic

únicamente a los grids que tienen tabla base. Si el valor de esta propiedad es 0, se despliegan tantas líneas comregistros resulten de la consulta asociada. El valor por defecto de esta propiedad es 0.

Collapsing:• AllowCollapsing :True: Permite colapsar el grid en ejecución• Collapsed :True: Arranca el grid colapsado.Selection:• AllowSelection : True: Especifica que es posible seleccionar una línea en la grilla.• SelectionColor: Seleccionar el color deseado al marcar la fila• AllowHovering: True: Marca la fila cuando el mouse se posiciona sobre la misma.• HoveringColor: Seleccionar el color deseado



Grid Freestyle

• Permite “formato libre” de losregistros

• Tabla con registros repetitivos

• No posee títulos para lascolumnas

• Permite tener más de un tipo decontrol en una misma celda

• Propiedades de diseño de tablas

• Propiedades del Grid

grid

El grid Freestyle permite al usuario definir el formato de los datos a desplegar de una forma menosestructurada que el grid estándar.

El grid Freestyle es básicamente una tabla a la que se le pueden insertar los atributos/variables, text blocks,imágenes, botones, web components, embedded pages, grids freestyle y/o grids que se van a mostrarposteriormente en la pantalla. Este tipo de grid no posee títulos para las columnas y además permite tener másde un tipo de control, atributo/variable en una misma celda, proporcionando de esta forma mayor libertad dediseño. Cabe destacar que el grid Freestyle posee las mismas propiedades mencionadas anteriormente para elgrid estándar.En este caso para poder visualizar las propiedades hay que seleccionar la tabla donde se encuentran losatributos/variables.

En el ejemplo presentado arriba queremos mostrar alguna información de los clientes. El atributo CustomerPhotose ha incluido en la transacción “Customer” para almacenar la foto de cada cliente (es un atributo de tipo Blob).Pero no queremos mostrar la información como lo haríamos en un grid estándar, con cada elemento deinformación en una columna distinta del grid. Aquí queremos mostrar la foto y debajo el nombre del cliente.

El comportamiento de las variables dentro de un grid Freestyle es análogo al que presentan dentro de un gridestándar, por lo tanto también quedan de ingreso si existe un For each line o For each line in <grid> dentro dealgún evento, o si se asocia un evento a cualquier control de la fila. Nuevamente este comportamiento puedemodificarse, agregando la regla noaccept o cambiando la propiedad Read Only.



Grid FreestylePropiedades

Para visualizar las propiedades de un grid Freestyle, hay que seleccionar la tabla del grid, presionar el botónderecho del mouse y seleccionar la opción ‘Properties’.

Nuevamente, para interiorizarse de cada una de las propiedades configurables de un grid freestyle, sugerimosacceder al Help de GeneXus. Aquí solo mencionaremos algunas como ejemplo:

Class: Permite modificar la clase de un control, ya sea en tiempo de diseño como en ejecución.La clase debe pertenecer al tema asociado al objeto que contiene el control. La propiedad Class solo se encuentradisponible si el control está en el form de un objeto que tiene un Tema asociado.

BackColorStyle: Permite asignar un estilo al grid. Los estilos disponibles son los mismos que para un gridestándar (ver grid estándar)

Rows: Esta propiedad permite al usuario indicar la cantidad de registros que va a cargar en el grid. Ídem a gridestándar.

Columns: Esta propiedad permite al usuario indicar cuántas columnas va a tener el Freestyle grid en ejecución.Si se ingresa un valor distinto de 1, el Freestyle grid va a mostrar los registros en tantas columnas como se hayaespecificado en la propiedad. Si el valor de esta propiedad es 0, se despliegan tantas columnas como registrosresulten de la consulta asociada. El valor por defecto de esta propiedad es 1. Esta es propia de este tipo de grids.

Propiedades modificables en ejecución: En tiempo de ejecución se pueden modificar algunas propiedades,como: visible, backcolor, backColorEven, BackColorOdd, Columns, Rows y

RecordCount: La propiedad RecordCount aplica únicamente a grids que tienen tabla base y retorna un númeromayor o igual a cero representando la cantidad de registros de la tabla base del grid que cumplen las condicionesde selección. Puede retornar -1 si no existe navegación para la tabla base del grid.

PageCount: La propiedad PageCount devuelve la cantidad de páginas del grid en base a las propiedades Rows yColumns del mismo. Al igual que la propiedad RecordCount, devuelve –1 si el grid no tiene tabla base. Para elcaso de un grid estándar, también existe esta propiedad dinámica, pero toma en cuenta solo la propiedad Rows.



Paginado de grids en Web panels

• Asignarle valor a propiedad Rows para indicarcantidad de registros a cargar por página.

• Métodos:• Firstpage• Nextpage• Previouspage• Lastpage (tabla base)• Gotopage (tabla base)

• Propiedades:• RecordCount (tabla base)• PageCount (tabla base)

DescripciónEl paginado del grid aplica a grids comunes y freestyle cuya propiedad ‘Rows’ tenga un valor diferente de cero.Existen algunas diferencias relacionadas con la paginación cuando un grid tiene tabla base o no.Podemos agregar al web panel “Work With Customer” botones de navegación para el grid (se muestran arriba) yeventos para realizar el paginado.

Mét odos

A continuación se describen los métodos disponibles:

Fi rs tPage:

El método FirstPage lleva al usuario al primer conjunto de registros devueltos.Los valores devueltos por este método son los siguientes:0: Operación exitosa1: No está habilitado el paginado en el grid

NextPage

El método NextPage lleva al usuario al siguiente conjunto de registros.Los valores devueltos por este método son los siguientes:0: Operación exitosa1: No está habilitado el paginado en el grid2: Ya se encuentra en la última página

Prev iousPage

El método PreviousPage lleva al usuario al conjunto anterior de registros.Los valores devueltos por este método son los siguientes:0: Operación exitosa1: No está habilitado el paginado en el grid2: Ya se encuentra en la primera página

Las tpage

El método LastPage lleva al usuario al último conjunto de registros. Puede ser utilizado únicamente si el gridtiene tabla base.Los valores devueltos por este método son los siguientes:0: Operación exitosa1: No está habilitado el paginado en el grid3: El grid no tiene tabla base



GoToPage

El método GotoPage(PageNumber) permite acceder en forma directa a un determinado conjunto de registros.Puede ser utilizado únicamente si el grid tiene tabla base.

Los valores devueltos por este método son los siguientes:

0: Operación exitosa

1: No está habilitado el paginado en el grid

Propiedades

Cada grid dispone de las siguientes propiedades que son utilizadas en la paginación:

RecordCount

La propiedad RecordCount aplica únicamente a grids que tienen tabla base y retorna un número mayor o iguala cero representando la cantidad de registros de la tabla base del grid que cumplen las condiciones deselección. Puede retornar -1 si no existe navegación para la tabla base del grid.

PageCount

La propiedad PageCount devuelve la cantidad de páginas del grid en base a las propiedades Rows y Columnsdel mismo. Al igual que la propiedad RecordCount, devuelve –1 si el grid no tiene tabla base.

Recomendamos estudiar las consideraciones de eficiencia relacionadas con el uso de estos métodos. Seaconseja realizar un buen filtrado de datos del grid.



Reglas más utilizadas en Web Panels

A diferencia del objeto transacción, en el cual se programa su comportamiento mediante la definición de reglas,en el objeto web panel la programación es dirigida por eventos.

Son pocas las reglas para web panels, y las mismas permiten definir comportamientos puntuales (hay algunasreglas más además de las mencionadas, que se pueden consultar en el Help de GeneXus).

Noaccept( & v a r i a b l e ) ;

En los web panels las variables que están en el form fuera de un control grid, ó que están dentro de un grid perohay algún evento donde se utiliza el comando For each line, o se le ha asociado evento de usuario o click a algúnatributo o variable del grid, son de entrada por defecto; es decir, el comportamiento por omisión es que en lasmismas pueden ingresarse valores.

Para definir que una variable se presente deshabilitada en un web panel, es decir, no permitiendo ingresos en lamisma, una opción es definir la regla:

noaccept(&variable);

siendo &variable una variable definida en el objeto.

La otra opción que tenemos en GeneXus para que una variable se presente deshabilitada en un web panel esconfigurando la propiedad Read Only de la variable con valor ‘True’.

Ver sección Propiedades de la grilla.

Default(& v ar iab le , v a lo r );

Asigna un valor por defecto a una variable.

&variable: es una variable definida en el objeto.valor: puede ser un literal entre comillas, un número o una de las funciones Today(), Date() o SysDate(),debiendo coincidir el tipo de datos del valor con el tipo de datos de la variable.

El valor por defecto se asignará a la variable al principio de la ejecución del programa.



• Web panel con a lo sumo un grid:• Con tabla base

• Sin tabla base

• Web panel con N grids:• Grids paralelos• Grids anidados

Conceptos fundamentales



Web panel es “con tabla base” cuando a lo sumo tiene un grid yGeneXus puede determinar un for each implícito asociado a él.

Para determinar si un web panel tiene tabla base y en casoafirmativo cuál será, al momento de especificarlo GeneXus analizalos atributos incluidos en:

1. form: en la parte fija

2. form: en el grid (visibles o no visibles)

3. el order del grid

4. las condiciones del grid (no en las condiciones globales)

5. los eventos fuera de comandos for each

Web Panel “con tabla base”

GeneXus busca la mínima tabla extendida que contenga a todos estos atributos, y la tabla base de dicha mínimatabla extendida, será la tabla base del for each implícito (es decir, la tabla que navegará el for each), se llamarátabla base del web panel.

Observar que GeneXus no toma en cuenta para determinar la tabla base de un web panel:

1) los atributos recibidos por parámetro

2) los atributos mencionados en las condiciones globales del web panel

Éstos actúan como filtros una vez determinada la tabla base.



• Un web panel “sin tabla base” es aquel que no

tiene atributos en ninguno de los 5 lugarespuntuados antes.

• Por lo tanto GeneXus no determina un for eachimplícito asociado a él.

Web panel “sin tabla base”

Los web panels de entrada generalmente son web panels “sin tabla base” por el hecho de que suelen contenersolamente variables; entonces, por no contener atributos en ninguno de los 5 lugares tenidos en cuenta porGeneXus para determinar la tabla base, son web panels “sin tabla base” .

Además del caso de los web panels de entrada, existen otros casos que ameritan la definición de web panels “sintabla base” .

En la próxima página vemos la resolución de una consulta con un web panel sin tabla base.



Web panel “sin tabla base” Ejemplo

• Mostrar para cada cliente el total facturado, pero sólo de losclientes que tienen facturas.

Event LoadFor Each CustomerIddefined by InvoiceDate

&Customer = CustomerName&Total =0for Each

&Total +=InvoiceTotalendforLoad

endforEndEvent

Dado que no mencionamos atributos en ninguno de los 5 lugares tenidos en cuenta por GeneXus para determinarla tabla base, se trata de un web panel “sin tabla base”.

Por tratarse de un web panel “sin tabla base”, el evento Load se ejecuta una sóla vez; y en el mismo codificamosexplícitamente los accesos con comando for each: cargamos valores en variables y para cargar líneas en el gridutilizamos el comando LOAD.

Nota: Observar en este caso que todas las columnas definidas en el grid (variables: &Customer y &Total) sonexclusivamente de salida, manteniendo el comportamiento por defecto definido para las variables en un grid. Esto

se debe a que no se está utilizando el comando For each line en ninguno de los eventos del web panel, nitampoco hay definido un evento click asociado a un control del grid (ni OnClickEvent).



Comando LOAD

• El objetivo del comando LOAD es incluir efectivamente una líneaen un grid.

• Una vez que se haya asignado valores a todas las variables quesean necesarias, y se desee agregar la línea al grid, deberáejecutarse el comando LOAD.

• Solamente se puede especificar el comando LOAD dentro delevento Load del grid de un web panel.

Si en la codificación del evento Load definimos comandos For each y asignamos valores a las variables en lasiteraciones pero no incluimos el comando LOAD, en tiempo de ejecución estaremos asignando una y otra vezvalores a las variables, pero no se estarán agregado líneas en el grid (solamente quedará una línea en el grid conlos últimos valores cargados en las variables).



• Mostrar para cada cliente el total facturado, pero sólo de losclientes que tengan facturas.

Event Load&Total =0For Each

&Total +=InvoiceTotalendfor

EndEvent

Atributo Oculto: InvoiceDateAtributo Order: CustomerId

Web panel “con tabla base” Ejemplo

¡Corte de control!

Atributo en el form del web panel: CustomerName

Atributo oculto (no visible) en el grid: InvoiceDate

Atributo order en el grid: CustomerId

Al especificarse este web panel, GeneXus determinará que la tabla base del mismo es INVOICE, significando estoque el web panel tiene un for each implícito asociado, con tabla base INVOICE.

Recordemos que en los web panels con tabla base, el evento Load se ejecuta N veces y es muy importante elsiguiente concepto:

Si en un web panel con tabla base, se incluye un comando for each en el evento Load, dicho for eachse anidará al for each implícito asociado al web panel. Es decir, el for each definido en el evento Loadno será un for each independiente.

En el web panel del ejemplo, codificamos lo siguiente en su evento Load:

- Inicialización de la variable &Total con valor cero

- For each cuya tabla base será INVOICE (porque el único atributo que contiene es InvoiceTotal) y dentro delmismo incrementamos la variable &Total con el total de cada factura (InvoiceTotal) recorrida.

De modo que como el web panel tiene tabla base INVOICE, en su evento Load definimos un for each con tablabase INVOICE también, y definimos un order indicando un criterio de agrupación, hemos implementado en elweb panel con tabla base, un corte de control.

En cambio, si no hubiésemos puesto el atributo InvoiceDate en el grid, el web panel seguiría teniendo tabla base,pero esta vez sería CUSTOMER. En el evento Load se definió un for each con tabla base INVOICE (ya que dentrodel comando for each solamente se encuentra el atributo InvoiceTotal). El for each del evento Load no seráun for each independiente, s ino que se anidará al for each impl íc ito asociado al web panel yestaremos implementando un join.

GeneXus analizará: ¿existe algún atributo relación entre las tablas “CUSTOMER” e “INVOICE”? Sí, CustomerId.Por lo tanto, GeneXus definirá el siguiente filtro automático en el for each con tabla base “INVOICE”:INVOICE.CustomerId = CUSTOMER.CustomerId.

tabla base del web panel: INVOICE



En resumen, cuando se ejecute el evento Refresh del web panel, comenzará a ejecutarse el for each implícitoasociado al web panel. Y por cada cliente recorrido, justo antes de cargarse una línea en el grid con el mismo,se ejecutará el evento Load. Entonces, para ese cliente que se venía recorriendo, se ejecutará el códigodefinido en el evento Load (es decir, se recorrerán sus facturas, sumando el total facturado del cliente). Alfinalizar la ejecución del evento Load, se cargará la línea en el grid. Obsérvese que aquí no es necesarioespecificar comando Load para realizar la carga: se hace automáticamente por el hecho de tener una tablaasociada a este grid.

En los eventos de usuario sucede algo parecido: cuando se incluye un for each en un evento de usuario, elmismo no es un for each independiente tampoco, sino que también se anidará al for each implícito asociado alweb panel. GeneXus considerará qué línea del grid está seleccionada al momento de ejecutar el evento deusuario (recordar Allowselection = True), y para los datos de la misma ejecutará el evento. De modo que siestando seleccionada determinada línea con un cliente, se ejecuta un evento de usuario, y el mismo tiene unfor each con tabla base “INVOICE”, se recorrerán las facturas del cliente de la línea seleccionada .

Teniendo los conceptos relacionados al objeto web panel bien claros, el analista GeneXus podrá optar si definirun web panel “con tabla base” o “sin tabla base”.



• Cuando un web panel contiene más de un grid en su form,GeneXus no determina una única tabla baseasociada al web panel, sino una tabla base asociadaa cada grid.

• Atributos que participan en la determinaciónde la tabla base de cada grid:

• Los incluidos en el grid (se tienen en cuenta tanto losatributos visibles como los no visibles)

• Los referenciados en Order y Conditions locales al grid

Web panels “con N grids” Grids paralelos

A diferencia de lo que sucedía para un web panel con un solo grid, en el caso de múltiples grids los atributos dela parte fija del web panel no participan en la determinación de la tabla base de ninguno de ellos, pero deberánpertenecer a la tabla extendida de alguno (para que sea posible inferir sus valores).

De no respetarse esto, al especificar al web panel, se mostrará en el listado de navegación resultante, unwarning advirtiendo de esta situación.

Los atributos utilizados en los eventos del web panel tampoco participan en la determinación de la tabla base deninguno de los grids. Los atributos que se incluyan en los eventos fuera de comandos for each, deberán

pertenecer a la tabla extendida de alguno de los grids (al igual que los de la parte fija).



Web panels “con N grids” Grids paralelos - Ejemplos

Una tabla base por grid No busca ni establece relaciones entre ellas

Ejemplo:

Dado que el web panel “View Suppliers And Customers” tiene más de un grid en su form, GeneXus nodeterminará una tabla base asociada al web panel, sino que determinará una tabla base para cada grid.

En este ejemplo, no hay definidos ni Order ni Conditions para ninguno de los grids, por lo tanto GeneXus sólotendrá en cuenta los atributos incluidos en cada grid para determinar sus tablas bases. La tabla base del grid quese encuentra arriba en el form será: SUPPLIER y la tabla base del grid que se encuentra abajo en el form será:CUSTOMER.

Es importante resaltar que GeneXus determina la tabla base de cada grid pero no busca ni establecerelaciones entre las mismas.

Al igual que en el web panel “View Suppliers And Customers”, en el web panel “View Customers And Invoices”,GeneXus determinará la tabla base del primer grid (que será CUSTOMER) y la tabla base del segundo grid (queserá INVOICE), pero no analizará si hay atributos en común entre ellas, y por ende no definirá filtros automáticos.Es decir que los grids tendrán asociadas navegaciones independientes o paralelas.

Si bien GeneXus no establece relaciones entre las tablas bases de los grids, el analista podrá definirlasexplícitamente. Primero estudiaremos los eventos en web panels con más de un grid, y a continuación veremoscómo definir cargas relacionadas.



• Un Refresh global• No se relacionan las cargas

• Refresh independiente de grids.• Evento Load de cada grid• Secuencia de Carga:

Refresh<Grid Control Name1>.Refresh

<Grid Control Name1>.Load<Grid Control Name1>.Load<Grid Control Name1>.Load

<Grid Control Name2>.Refresh<Grid Control Name2>.Load<Grid Control Name2>.Load<Grid Control Name2>.Load

Web panels “con N grids” Grids paralelos – Eventos y carga

N veces si GridControlName1 tiene

tabla base. Sino 1.

N veces si GridControlName2 tiene

tabla base. Sino 1.

En web panels con más de un grid, existe un evento Refresh global y un evento Refresh particular paracada grid. El evento Load, no existe global sino sól o a nivel de cada grid .Los eventos Refresh y Load a nivel de grids, deben referenciar al grid usando la siguiente nomenclatura:

Event <Grid Control Name>.<Refresh | Load>....EndEvent

Por ejemplo, si en el web panel “View Suppliers And Customers”, los nombres de los grids son SuppliersGrd yCustomersGrd respectivamente, para codificar los eventos Refresh y Load a nivel de los grids, la sintaxis deberáser:

Event SuppliersGrd.Refresh Event SuppliersGrd.Load.... ....EndEvent EndEvent

Event CustomersGrd.Refresh Event CustomersGrd.Load.... ....EndEvent EndEvent

Además de estos eventos a nivel de los grids, estará el evento Refresh global:

Event Refresh

....EndEvent

La carga de los grids en un web panel se realiza para cada grid de forma independiente. Es decir, aún si los datosque se muestran en ambos grids están relacionados, el especificador no relaciona las cargas.

La carga asociada a los grids de un web panel incluye el evento Refresh, o sea que la secuencia de carga de unobjeto con 2 grids es como se muestra arriba. La ejecución del método Refresh de cualquier grid solo se disparapar refrescar dicho grid.

El orden en que se cargan los grids es como aparecen en el form: de arriba hacia abajo y de izquierda a derecha.De esa manera, cada uno de los grids se cargará con los datos correspondientes.



• Load: La sintaxis sigue siendo Load, pero debe estar incluidodentro del evento load asociado al grid que se está queriendocargar. Su uso es análogo al caso de un grid (sin tabla base).

– Event Grid1.Load....Load

Endevent

• For each l ine: Debe incluir una referencia al grid de la siguienteforma:

– For each line IN <Grid Control Name>

Web panels “con N grids” Grids paralelos - Comandos

El comando LOAD mantiene la misma sintaxis en Web Panels con más de un grid. Se debe incluir al mismo parahacer cargas de grids sin tabla base, dentro del evento Load de un grid.



• Se requiere la implementación de un WebPanel que muestre en un grid todos los países(GrdCountries), y cada vez que el usuarioseleccione un país, que se carguen sus clientesen un segundo grid (GrdCustomers).

Web panels “con N grids” Grids paralelos - Cargas Relacionadas

SOLUCIÓN



AMBOS GRIDS CON TABLA BASE

Web panels “con N grids” Múltiples grids - Cargas Relacionadas

Event Enter&CountryId = CountryId

EndEvent // Enter

AllowSelection = True

En la solución que se presenta, ambos grids han sido definidos “con tabla base”, así que cada uno de ellos tieneun for each ímplicito asociado:

• GrdCountries tiene un for each implícito asociado que navega la tabla COUNTRY.

• GrdCustomers tiene un for each implícito asociado que navega la tabla CUSTOMER.

Debemos habilitar la selección de línea por parte del usuario para el grid de países (propiedad AllowSelection degrid GrdCountries). Cuando el usuario la seleccione, presionará el botón “View customers” para que sedesplieguen en el grid inferior todos los clientes del país seleccionado.

Para ello necesitamos guardar en una variable el país seleccionado, para que luego, cuando se haga la carga degrid de los clientes, puedan éstos filtrarse mostrando solo los que correspondan al valor almacenado en esavariable.

Es decir, en el evento asociado al botón, asignaremos a la variable &CountryId el valor del país actual, es decirdel de la línea seleccionada por el usuario.

Recordemos que cuando se presione este botón, se disparará el evento Start, luego se leerán las variables deform (en este caso no hay), luego se disparará el evento asociado al botón (allí se le dará valor a la variable) yluego se dispararán el evento refresh general y a continuación los eventos refresh y load para cargar nuevamenteel grid de países, e inmediatamente el refresh y load para cargar los clientes (y aquí se aplicará el filtro asociado).

Observar que no necesitamos colocar la variable &CustomerId en el form, puesto que es cargada y utilizada en la

misma ejecución en el servidor, por lo que no pierde su valor.

Existen otras soluciones posibles para implementar la carga relacionada en web panels con múltiples grids queveremos a continuación.



Solución Nro. 2: Grid Grdcountries “con tabla base” y GrdCustomers “sin tabla base”

En esta segunda solución, el grid GrdCountries ha sido definido “con tabla base”, así que tiene un for eachímplicito asociado al mismo, que navega la tabla COUNTRY.

Debemos habilitar la selección de línea por parte del usuario sobre este grid, a través de la propiedad

AllowSelection.Una vez que el usuario se posiciona en una línea y presiona el botón “View customers” se debe refrescar elgrid GrdCustomers con los clientes que pertenezcan a ese país.

Al igual que antes, en el evento asociado al botón (en nuestro caso es el enter), debemos darle valor a lavariable para que luego pueda ser utilizada para filtrar.

Event Enter&CountryId = CountryId

endevent

El grid GrdCustomers fue definido “sin tabla base” asociada, por lo cual debemos programar a mano la cargadel grid en el Evento Load.

Event GrdCustomers.LoadFor each

where CountryId=&CountryId&CustomerId=CustomerId&CustomerName = CustomerNameLoad

endforEndevent

Como el grid de clientes (GrdCustomers) es “sin tabla base”; cada vez que se ejecute Refresh para el gridGrdCustomers, a continuación se ejecutará su evento Load una sola vez. Por lo tanto, programamos en elevento GrdCustomers.Load un for each con tabla base CUSTOMER, filtrando los clientes del país quehabíamos cargado en una variable, y agregamos explícitamente los clientes en el grid (asignando a lasvariables &CustomerId y & CustomerName los valores de los atributos CustomerId y & CustomerNamerespectivamente y ejecutando el comando Load a continuación para efectuar la carga de cada línea).

Recordemos que cuando el usuario habiendo seleccionado un país en el grid correspondiente, presione elbotón “View customers” se realizará un post al servidor, donde se ejecutará el evento Start, luego se leerán

las variables de pantalla, se ejecutará el código asociado al botón (evento Enter), donde la variable parafiltrar es cargada, y a continuación se dispara el evento Refresh general, y luego el Refresh seguido de Nocurrencias del evento Load del grid de países (1 por cada país a ser cargado) y finalmente el evento Refreshdel grid de clientes, seguido de un evento Load para ese grid (dentro del cuál se cargan las líneas con elcomando Load).



Solución Nro. 3: Ambos grids “sin tabla base”

En esta tercera solución ambos grids han sido definidos “sin tabla base”, por lo cual el evento Load de cadagrid se ejecutará una sóla vez.

Event GrdCountries.LoadFor each

& CountryId=CountryId& CountryName=CountryNameLoad

EndforEndevent

Event GrdCustomers.LoadFor each

where CountryId=& CurrentCountryId&CustomerId=CustomerId&CustomerName = CustomerNameLoad

endforEndevent

En el evento Load correspondiente al grid GrdCountries, programamos explícitamente con comando for eachy comando Load, que se carguen todos los países de la tabla COUNTRY.

Luego codificamos el evento Enter asociado al botón “View customers”:

Event Enter&currentCountryId = &CountryId

Endevent

En tiempo de ejecución, estas 3 soluciones vistas se comportarán igual. Como se ha mencionadoanteriormente, si se incorporan bien los conceptos teóricos vistos, el analista GeneXus podrá optar al definir

un web panel, si trabajar “con tabla base”, “sin tabla base” o combinando ambas cosas.



• Acerca de condiciones de filtro

• Es posible especificar condiciones de filtro tanto a nivel global comoa nivel de cada grid.

• Para cada grid se tendrán en cuenta las condiciones globales y lascondiciones locales (es decir: condiciones globales and condicioneslocales).

• Las globales nunca participan de la determinación de la tabla base

• No es posible nombrar a un atributo o variable de un grid• Ejemplo: GrdCountries.CountryId / GrdCustomers.CountryId

• Sí es posible referirse a CountryId, codificar sus propiedades,eventos y métodos

• Igualmente no se recomienda tener el mismo atributo / variable enmás de un grid, ya que las codificaciones afectarían a todos

Web panels “con N grids” Grids paralelos - Consideraciones

Si por ejemplo el atributo CountryId se agregara en más de un grid y se codificara: CountryId.Visible=0, elatributo CountryId quedaría invisible en todos los grids.



• Varios niveles de anidación

• Anidaciones paralelas• Ej: Countries y Customers

• Para profundizar en este tema dirigirseal curso de Desarrollo de aplicacionespara Internet con GeneXus

Web panels “con N grids” Grids Anidados

ejecución

Es posible definir grids “anidados” en un web panel.

Los grids anidados consisten en un grid Freestyle al que se puede insertar dentro de una celda otro grid estándaru otro Freestyle.

Por ejemplo, se quiere tener un web panel que muestre los clientes, pero indentados por país, como se muestraen la imagen en ejecución arriba a la derecha.

Para ello se define un grid freestyle con el país y dentro de éste se inserta otro grid, en este caso estándar, conlos clientes.

Puede haber grids anidados de varios niveles y puede haber también paralelos. Puede decirse que se estádefiniendo un árbol en donde cada nodo es un grid.

Cada grid puede ser un freestyle o un grid estándar, aunque si es estándar no puede tener ninguno anidado. Losgrids estándar sólo pueden ser hojas del árbol de anidación.

No se ahondará en el tema en el presente curso. Podrá hacerlo en el curso de Desarrollo de aplicaciones paraInternet con GeneXus.



Web panels

• Tipos de Web panels• Component• Master Page• Web Page

• Propiedad Type

Los objetos web pueden ser definidos con tres tipos diferentes, configurable en la propiedad Type del objeto.Para un web panel podrá tomar uno de los valores:

•Component: (transacción ó web panel, que a partir de aquí podrá ser incluido en otro web object)

•Master Page

•Web Page (es decir, el objeto será una transacción ó web panel tal como hemos trabajado hasta el momento)

El tipo de web panel ‘Component’ se analiza en detalle en el curso Desarrollo de Aplicaciones para Internet conGeneXus.

A continuación introduciremos el Web Panel tipo “Master Page” y su utilización.



Master Pages

HEADER

CONTENT

M E N U

Tener un look&feel consistente es hoy en día un deber de toda aplicación Web.

Crear y mantener cada página de una aplicación Web asegurando la consistencia con el resto del sitio tomagran tiempo de programación.

En el ejemplo presentado arriba, hemos capturado una pantalla del sitio de Sony. Navegando entre las distintaspantallas, nos hemos encontrado que todas ellas tienen un header común, así como un menú a la izquierda decada página. Ambas cosas pueden ser visualizadas en la pantalla capturada arriba. Lo que va variando a medidaque uno va navegando por las distintas páginas es lo que aparece a la derecha, y que es el contenido específicode cada página.

¿Cómo implementar un sitio de estas características? Con el conocimiento que tenemos hasta el momento,tendríamos que repetir la parte del Layout común a todas las páginas del sitio, así como el comportamientocomún, en cada web panel que implementa cada una de esas páginas. Eso introduce dos problemasfundamentales: si hubiera que realizar alguna modificación a esas partes comunes a todas las páginas, habráque ir página por página a realizarlo. Y relacionado con esto, la posibilidad de olvidarnos de hacerlo en algunapágina, o introducir alguna variación en la misma, degradará la consistencia del sitio.

Las Master Pages proveen una forma de centralizar el layout y el comportamiento común en un solo objetoy reutilizarlo en todo otro objeto sin tener que programar. Esto significa que la modificación de alguna parte dellayout o del comportamiento común es tan fácil como modificarla en un único objeto y ¡listo!.

Se creará un web panel categorizado como “Master Page” con todo lo que sea el Layout y comportamientocomún a todas las páginas del sitio, y en el mismo se dejará un espacio para cargar en cada oportunidad lapágina que corresponda (el contenido variable del sitio). Las páginas web que implementan el contenido

variable, se implementan como Web Panels o Web Transactions comunes y corrientes (es decir de tipo “WebPage”, ver página anterior), y se asocian a la Master Page, de manera que cada vez que se ejecuten, se carguencon ese “contexto”.



• Propiedad Type = ‘Master Page’

• Permiten definir en un único lugar el layout y

comportamiento común a todas las páginas del sitio(especifican el marco o contexto de toda página)

Master Pages

Marco, contexto detodas las páginasdel sitio

Lugar donde laspáginas individualesserán cargadas.

Header

Menú

Master Pages

Se crea entonces un objeto Web Panel y se le configura la propiedad Type con el valor ‘Master Page’ . En unamisma base de conocimiento se pueden definir tantas Master Pages como se desee.

Una vez que exista al menos una Master Page en la base de conocimiento, puede ser referenciada desdecualquier web panel o web transaction, en la propiedad MasterPage de estos objetos (que por defecto tiene elvalor “(none)”). El efecto de hacer esto será que al ejecutar estos objetos, se ejecutarán con la master pageasociada, es decir, se cargará la master page, y en el “hueco” es donde se cargará la página individual.

Se profundiza en Master Pages, Web Components, Embedded Pages, en el curso Desarrollo de Aplicaciones paraInternet con GeneXus.



PATTERNS



Patterns

• Es una herramienta que:• es parte de GeneXus 9.0 (Tools / Patterns)• puede ejecutarse también como aplicación independiente

• Básicamente permite aplicar a una Base de Conocimientocierto patrón (pattern), y que se generen todos los objetosGeneXus necesarios para implementar el patrón, para aquellasinstancias que se hayan seleccionado.

• Existe un conjunto de patrones muy útiles ya definidos (alinstalar la herramienta se instalan) para que el desarrolladorpueda aplicarlos a sus Bases de Conocimiento rápidamente,obteniendo por resultado funcionalidades útiles generadasautomáticamente.

• A su vez la herramienta permite crear patrones nuevos, siendoesta una tarea un poco más compleja.

Puede obtener los requerimientos de software para instalar la herramienta Patterns de lasiguiente página del Wiki:

http://wiki.gxtechnical.com/wiki/tiki-index.php?page=PatternsInstallation



Patterns

Algunos patrones (patterns) existentes:

• WorkWith

• Bill Of Materials

• OAV

Catálogo:

http://wiki.gxtechnical.com/wiki/tiki-index.php?page=Business+Patterns+Catalog

Work With: Genera a partir de una transacción (o para todas aquellas transacciones que sedeseen), todos los objetos necesarios para tener una aplicación web.

Por ejemplo, si se aplica el pattern “Work With” a la transacción “Customer”, se generará unobjeto GeneXus Web Panel que permitirá al usuario final consultar interactivamente los clientes dela base de datos (se presentará una página web vistosa conteniendo una lista con los clientes de latabla CUSTOMER). Este Web Panel se llamará “Work With Customers” y ofrecerá entre tantascosas, un link asociado a cada cliente mostrado en la lista, para que mediante su selección seacceda a otro objeto Web Panel (de nombre “View Customer” ) que mostrará todos los datos delcliente (y su información relacionada como podrí an ser facturas, recibos, etc.). El Web Panel “WorkWith Customers” además ofrecerá para cada cliente mostrado, la posibilidad de modificar sus datos(habiéndose agregado automáticamente para ello una invocación a la transacción “Customer” ) así como la posibilidad de eliminar un registro de cliente, o de insertar un cliente nuevo (invocando ala transacción “Customer” para ello también).

Se podrán configurar variadas propiedades para agregar opciones de filtrado en el Web Panel “Work With Customers” (por ejemplo para que el usuario final pueda consultar solamente losclientes de cierto paí s, o aquellos cuyos nombres se encuentren incluidos en determinado rango);y también configurando una simple propiedad se podrá incluir en el Web Panel “Work WithCustomers” un combo box que ofrezca distintos órdenes posibles, para que el usuario final elija sidesea el resultado de la consulta ordenado por nombre de cliente, por código u otro atributo.

Si el patrón Work With se aplicara también a la transacción “Product” obtendrí amos todas estasfuncionalidades para dicha instancia también, así como para cada una de las transacciones que sedeseen.

Bil l of materials: Este patrón permite generar a partir de una transacción, otra que representa larelación compuesto – componente.

OAV: Objeto-Atributo-Valor; Este patrón genera a partir de una transacción otras dostransacciones que permiten extender la original, con el objetivo de permitir definir atributos enruntime.

Además, seguimos trabajando en la definición de nuevos patterns. Sugerimos ver catálogo conlista de patterns, algunos de los cuales ya están implementados y otros sugeridos para una futuraimplementación.



Patterns

Objetivos y beneficios de la herramienta Patterns:

Gran incremento de productividad y calidad en las aplicaciones

Ejemplo de uso:

Aplicar el pattern Work With a una KB para generar la mayoría delos web objects necesarios para obtener una aplicación web atractivay amigable.



Patterns

Utilización de la herramienta(mostramos ejemplo aplicando pattern WorkWith)

Paso 1

- Contamos con una KB con algunas transacciones (se recomienda tenerprototipo web creado)

- Ejecutamos la herramienta Patterns

- Desde GeneXus (Tools / Patterns, en el modelo de Diseño) la KBse cerrará automáticamente, y se reabrirá cuando se cierre laherramienta Patterns

- En forma independiente (GeneXusPatterns.exe) será necesario

cerrar la KB desde GeneXus, ya que para utilizar una KB desde laherramienta Patterns debe haberse cerrado previamente desde GeneXusy viceversa

Si se ejecuta la herramienta Patterns en forma independiente de GeneXus, será necesarioseleccionar la KB con la cual se trabajará (para ello la herramienta Patterns ofrece el ítem:File / Open Knowledge Base).

Cuando se trabaja con la herramienta Patterns con una KB por primera vez, se presenta undiálogo cuyo título es “Workspace Configuration”. Este diálogo permite configurar algunas

opciones relacionadas a la KB, otras opciones relacionadas al pattern a ser aplicado, y otrasopciones relacionadas a operaciones de GeneXus (impactar, especificar, etc.) que puedenejecutarse utilizando la herramienta Patterns. En este punto inicial puede cerrarse estediálogo si se desea, y posteriormente es posible ingresar al mismo, mediante el ítem Build

/ Configure GX Integration (ver paso 8).



Patterns

Paso 2

- Se despliega información de la KB- Dado que muchos patterns usan TRNs, se muestra una lista de lasTRNs disponibles en el tab KB Explorer:



Patterns

Paso 3

- Seleccionar en el combo box mostrado en la toolbar, elpattern que se desea aplicar:

Se ofrece por defecto la lista de patterns predefinidos.



Patterns

Paso 4

- Debemos obtener un ‘instance file’ por cada caso al cual queramosaplicar el pattern.

- ‘Instance file’ = archivo XML con los datos propios de la instancia

- Si bien es posible crear cada ‘instance file’ de cero, los patternssuelen proveer una funcionalidad para crear ‘instance files’ pordefecto, y luego poder modificarlos fácilmente.

- En el caso del pattern WorkWith, en el tab KB Explorer:

- Teniendo una TRN (o varias) seleccionada(s) botónderecho / Generate Instance File

- Doble clic en una TRN

Llamamos proceso de instanciación de un patrón al proceso de aplicar un patrón a una ovarias situaciones (instancias).

En el proceso de instanciación de un patrón las entradas son:

• Instance f iles: por cada situación o instancia a la cual se quiera aplicar el patrón, habrá

que crear un instance fi le con la información propia de esa instancia en particular (atributosa mostrar, etc.). Cada instance fi le es en definitiva un archivo XML con los datos propios dela instancia, y tal como se explica en la transparencia, los patterns suelen proveer unafuncionalidad para crear ‘instance files’ por defecto (que luego, de considerarse necesario, sepueden modificar fácilmente).

• Template fi les: contienen la implementación del patrón y de su aplicación a las instancias.

El resultado que se obtiene del proceso de instanciación de un patrón (procesando losinstance fi les y template fi les) es: un conjunto de objetos GeneXus para ser consolidadosen la KB.



Patterns

[Paso 5]

- Los ‘instance files’ pueden editarse en el panel derecho- Dos opciones para hacerlo: Tree View / XML View:

Cada ‘instance file’ es un archivo XML con estructura jerárquica, conteniendo cada uno de susnodos un conjunto de propiedades.

La herramienta patterns ofrece 2 editores para editar cada ‘instance file’ en el panel derecho:el editor XML View y el editor Tree View.

El editor XML View permite editar los instance file directamente en su formato XML. Por suparte el editor Tree V iew es mucho más amigable, sencillo de usar, y con interfaz en altonivel que provee mayor funcionalidad para ayudar en el proceso de edición. Por todo esto eleditor Tree View es el más usado y es el recomendado para usuarios no avanzados.



Patterns

Paso 6

- Los ‘instance files’ se deben grabar. Para ello, bajo el ítemInstance se ofrecen las opciones Save y Save Al l.

- Los ‘instance files’ que no se han salvado aún se visualizancon nombre: <TRN Name.Pattern>*.

- Una vez salvados se visualizan con el nombre:

TRN Name.Pattern (ej: Country.WorkWith).

Save – salva el ‘instance file’ con el que se esté trabajando.

Los ‘instance files’ que no se han salvado aún se visualizan con nombre: <TRNName.Pattern>*. Y una vez salvados se visualizan con el nombre: TRN Name.Pattern(porejemplo: Country.WorkWith).

¿Dónde se almacenan físicamente los ‘instance files’? En el subdirectorio Templates bajo el

directorio de la KB.

Seleccionando el tab Folder Explorer se pueden visualizar estos archivos:

Save A ll – Salva todos los ‘instance files’ (si ya existen, pregunta si reemplazar).

Es importante tener en cuenta que si se generan los ‘instance files’ por defecto nuevamente apartir de las transacciones, serán sobrescritos.



Patterns

Paso 7

- Una vez creados y editados los ‘instance files’, el siguiente pasoes que la herramienta genere los objetos GeneXus queimplementan el pattern para las instancias.

- Opciones:

- Build / Apply Pattern

- Build / Apply and Consolidate

- Posibilidad de que se consoliden automáticamente acontinuación o que lo haga después (desde la KB) eldesarrollador GeneXus.

Se genera enKBPath\Templates\Import, unarchivo <TRNName>.xpz.xmlpor cada ‘instance file’

Mediante botón derecho también es posible ejecutar estas acciones: es decir, estando posicionado enel tab Folder Explorer, luego de haber seleccionado los instance files (.workwith files), se puedenejecutar las opciones Apply Pattern o Apply and Consolidate.

Nota: También es posible seleccionar una TRN o grupo de TRNs estando posicionado en el tab KB

Explorer, y mediante botón derecho ejecutar la opción Generate, Apply and Consolidate. Pero esimportante entender que seleccionando esta opción, se generarán los instance files por defectonuevamente para las TRNs seleccionadas, y luego de ello, se generarán los archivos<TRNName>.xpz.xml correspondientes y se consolidarán en la KB. Si se está seguro que los instancefiles por defecto no necesitan ser editados, es posible seleccionar esta opción directamente.

A su vez es importante saber que si se selecciona la opción Apply and Consolidate se efectuarántambién las siguientes acciones:

• Se configurará como default theme de la aplicación al theme Fantastic.• El directorio Images será copiado automáticamente bajo el directorio KBPath\Templates.• La model property "Base image path" del modelo de diseño se configurará con el valor anterior.



Patterns

Paso 8

- Desde la herramienta Patterns, es posible ejecutar las acciones

que se realizan también desde GeneXus: Impactar el modelo,Especificar, Generar, Compilar y Ejecutar.

- Diálogo donde se configura:

Para hacer más fácil todo el proceso, desde la herramienta Patterns , es posible ejecutar las acciones quese realizan con GeneXus: Impactar el modelo, Especificar, Generar, Compilar y Ejecutar.

Estas acciones se configuran en el diálogo “Workspace Configuration” que se abre en el momento deabrir la KB con la herramienta Patterns, o seleccionando luego la opción Build / Configure GXIntegration.

Opciones disponibles en el diálogo

Model – Muestra los modelos definidos en la KB, y permite seleccionar uno de ellos (se requiere tenerlos modelos creados y la creación de sus tablas hechas).

Apply and Consol idate – Al seleccionar la opción Apply and Consolidate, es posible ejecutar másacciones además de la generación de objetos y consolidación. Este combo ofrece las siguientesposibilidades:

• Consolidate Only (Apply and Consolidate)

• Impact Model (Apply and Consolidate + Impact Model)

• Impact, Specify (Apply and Consolidate + Impact + Specify)

• Impact, Specify, Compile (Apply and Consolidate + Impact + Specify + Compile)

• Impact, Specify, Compile, Run (Apply and Consolidate + Impact + Specify + Compile + Run)

GeneXus Version - La versión de GeneXus correspondiente a la KB se detecta automáticamente (puedeser 8.0 o 9.0). El modelo se especificará / generará con dicha versión.



Bui ld Actions- Permite seleccionar qué objetos deben especificarse y generarse al seleccionar Specifyand Generate. Las opciones disponibles son:

- Build All

- Build Pending (updated since last specification)

− Specify Consolidated Objects

Specification – Permite seleccionar el tipo de especificación / generación a ser ejecutado al seleccionarSpecify and Generate. Las opciones disponibles son:

− Full Specification

− Check Specification

− Force Generation

Run Command – En esta opción se debe indicar la URL que se ejecutará si se seleccionó la opciónImpact, Specify, Compile, Run.

Se debe configurar:

para aplicaciones .NET Run Command = http://localhost/services/hhome.aspx

para aplicaciones Java o http://localhost:8080/servlet/hhome

Nota: Vale aclarar que “home” es el nombre de un web panel generado por el patrón WorkWith; elmismo ofrece links a todos los web panels WorkWith generados (y la letra h que antecede a su nombreen la invocación, corresponde al prefijo que se agrega a todo objeto web panel main o ejecutable que seinvoca).



Patterns

Resultado en ejecución



Patterns

¿Cómo modificar los objetos generados?

• Mediante la herramienta P atterns

1. Modificando las propiedades de las instancias (en lamedida que ofrezcan lo que se desea)

2. Modificando el pattern, personalizándolo para que ofrezcaconfigurar propiedades que implementen las necesidades

• Mediante GeneXus

Modificando los objetos GeneXus generados (Desventaja:en caso de querer volver a generarlos con Patterns, se

regeneran los objetos, perdiendo los cambios hechos alos mismos)



Patterns

¿Cómo modificar las propiedades de las instancias?

Archivo de instancia

Editor Tree View

Propiedades configurables

Son muchas las propiedades que se ofrecen en los archivos de instancia correspondientes al patternWorkWith para personalizar el comportamiento de los objetos que se generarán. A continuacióndescribimos algunas de ellas.

El nodo Selection ofrece las propiedades relacionadas al web panel WorkWith que se generará parala instancia. Sus sub-nodos son:

Modes

Este nodo permite definir en cuáles modos se ofrecerá invocar a la transacción. Las posibilidades ysus valores por defecto son:

Insert: True

Update: True

Delete: True

Display: False

Export: True (exportación a planilla excel)

Para casa modo podrá especificarse una condición. Se proveen las siguientes propiedades para esepropósito:

Insert Condition

Update Condition

Delete Condition

Display Condition

Si se define una condición asociada a un modo, la invocación para ese modo solo se habilitará si laevaluación de la condición es verdadera (Ejemplo: CountryId=10).



Attributes

Este nodo permite definir cuáles atributos se desean mostrar en el grid (y para cada atributo, sepueden personalizar varias propiedades).

Orders

Es posible ofrecer al usuario final varios órdenes posibles para ver el resultado de la consulta (esdecir, las líneas mostrando los datos en el grid). Utilizando el botón derecho del mouse se puededefinir un nuevo orden (su nombre y composición). Cada orden puede estar compuesto por variosatributos (pudiendo indicar para cada un de ellos si se desea orden ascendente o descendente). Sepresentará un combobox en el web panel WorkWith ofreciendo todos los órdenes posibles deseleccionar, para que el usuario final elija uno y los datos se presenten en el grid ordenados por elmismo.

Filters

Permiten definir condiciones de filtro para que se muestren en el grid solo los registros que cumplancon las mismas.

El nodo View por su parte, ofrece las propiedades relacionadas al web panel View que se generarápara la instancia. El web panel View muestra toda la información de un registro, que fueseleccionado en el grid del web panel WorkWith (la información del registro es mostrada en unasolapa de un tab control, y además hay una solapa con un grid por cada tabla directamentesubordinada, para mostrar la información relacionada).



Observaciones

Al crear cada ‘instance file’ por default, podemos observar que las distintas propiedades del ‘instance file’ se inicializan con valores por default. Dichos valores por default para las propiedades, se especifican enun archivo denominado NombrePattern.config (en nuestro caso WorkWith.config).

El archivo NombrePattern.config se encuentra donde está instalada la herramienta Patterns, bajo elsubdirectorio del Pattern particular que se esté utilizando. Para el caso del pattern WorkWith estará bajo:

Patterns\WorkWith (recordar que bajo el directorio de la herramienta Patterns, existe un subdirectoriopor cada patrón predefinido (WorkWith, Bill of Materials, OAV) así como deberá haber un subdirectoriopor cada patrón definido por el usuario.

Si deseamos tener un archivo de configuración NombrePattern.config por cada KB, debemos copiar estearchivo al directorio Templates que se crea bajo la KB al usar la herramienta Patterns; así la herramientaPatterns utilizará dicho archivo ubicado en la KB para inicializar las propiedades de los ‘instance files’ quese creen. Si la herramienta Patterns no encuentra el directorio Templates con este archivo bajo la KB,utilizará el archivo NombrePattern.Config (en nuestro ejemplo WorkWith.config) ubicado en el directorioPatterns\WorkWith.

El WorkWith.Config permite configurar algunos aspectos generales que aplicarán a todos los objetos. Porejemplo, las master pages a ser utilizadas por los objetos web, los web components utilizados comoheader y footer, etc..

Para editar este archivo de configuración, la herramienta Patterns ofrece el ítem: Tools/ChangePattern Configuration.

Ejemplo:

Propiedad UpdateTransaction, ofrece los siguientes valores:

• Do not update: La trn no será modificada (web form, reglas y eventos serán mantenidos)• Only rules and events (defaul t value): Solo las reglas y eventos son modificados, pero no el webform.• Apply WW Style: la primera vez que el pattern sea aplicado, el comportamiento será el mismo que sise hubiese seleccionado el valor Create Default. A partir de la segunda vez, el header, footer y botonesdel form web serán modificados, pero no la Data Area. Los eventos y reglas también serán modificados.• Create default: el web form, reglas y eventos serán modificados.

El pattern WorkWith ademásgenerar objetos nuevos, hace algmodificaciones a las trn’s existe(regla parm para recibir parámedel WorkWithcorrespondiente, etc.).En el archivo WorkWith.configvalor configurado por defaultesta propiedad es “Only rules events”.



Ejemplo: Work With desde GeneXus

En el capítulo donde estudiamos el objeto web panel, implementamos manualmente un web panel “WorkWith Customer” donde agregamos variables al grid para dar un mensaje de cliente moroso si su saldosuperaba los $10.000 y para contar la cantidad de facturas que se le realizaron, respectivamente. Habíamosasimismo programado el evento Load para lograr lo anterior.

Todo esto puede ser codificado automáticamente por el Pattern “Work With”, si ud. agrega en la lista deatributos del archivo de instancia correspondiente, las dos variables anteriores, y asociadas a las mismas en

el “LoadCode” el código asociado, como puede ver en la siguiente página.



…desde Patterns

Se definen las variables &type y &quantity haciendo botón derecho sobre el nodo Attributes y luego,posicionándose en &type, en la ventana de la derecha, en la opción LoadCode, se ingresa el código que sequiere ejecutar para esa variable, cuando se cargue la línea.



Ejemplo: Work With desde Genexus

Acciones sobre

el cliente

seleccionado

Asimismo, en el web panel Work With Customer que habíamos implementado manualmente antes, agregamosbotones para poder realizar las acciones típicas de un Work With (alta, baja, modificación, y vista de registro).

Asimismo, tuvimos que modificar la transacción “Customer” para recibir como parámetro el modo y clave, comose puede recordar en la siguiente página.



Ejemplo: “Work With Customer” desde GeneXus

Event ‘Insert’

Tcustomer.call(‘INS’, 0)Endevent

Event ‘Update’

Tcustomer.call(‘UPD’, CustomerId )Endevent

Event ‘Delete’

Tcustomer.call(‘DLT’, CustomerId )Endevent

Event ‘View ’

Tcustomer.call(‘DSP’, CustomerId )Endevent

En las reglas de la

transacción “Customer”:

Pattern crea el enumerado:

Parm(&Mode , &CustomerId );

CustomerId = &CustomerId if not&CustomerId.IsEmpty();

El Pattern Work With no implementa estas acciones de la misma manera. Esta herramienta crea un dominioenumerado para los valores que puede tomar la variable &Mode y la implementación de las acciones en el webpanel Work With Customer que realiza es como se muestra en las páginas siguientes.

Pattern modificará la transacción “Customer” para agregar exactamente las mismas reglas que nosotrosescribimos en forma manual.



…desde Patterns

Event Start

NewControl.Link = Link(TCustomer, TrnMode.Insert, CustomerId.SetEmpty())

&Update = LoadBitmap(!"images/edit.gif")

Endevent Event Load

&Update.Link = Link(TCustomer, TrnMode.Update, CustomerId)

Endevent ‘UPD’

Aquí podemos ver otra forma de selección de una línea del grid. En el caso anterior utilizamos la propiedadAllowSelection del grid para habilitar la selección de una línea en ejecución por parte del usuario.

Otra opción es la que implementa el Pattern “Work With” mediante la utilización de variables (en este caso detipo bitmap, &update y &delete, cargadas con la imagen correspondiente en el evento Start) a las que en elevento Load del grid se les asigna la propiedad Link para determinar el identificador de cliente que se leenvía a la transacción Customer en cada línea cargada (en el cuadro de arriba solo se incluyó el código para

cargar la variable &update, pues para la variable &delete es análogo).

Nota: Obsérvese que delante del path relativo a la imagen aparece el símbolo “!”. No le dé importancia. Seutiliza para la herramienta de Traducción (Application Localization), para evitar que el literal que le siga seatraducido.

Como ya mencionamos la herramienta Patterns define el tipo enumerado TrnMode y es por ello que noaparece ‘UPD’ directamente sino su descripción TrnMode.Update.



USO Y RECOMENDACIONES EN ELUSO DE SUBTIPOS



Definición de subtipos

• Las relaciones entre atributos GeneXus se establecen a través de susnombres.

• Mediante subtipos se puede establecer que dos atributos que sellaman diferente corresponden al mismo concepto.

• Se dice que el atributo A es subtipo del atributo B si se cumple unadependencia funcional, o sea para cada valor de A existe un solovalor de B y el valor de A es igual al valor de B.



Casos de uso de subtipos

• Algunos casos:• Múltiples referencias• Especialización de un nivel (relación 1-1)• Subtipos recursivos• Evitar controles de integridad referencial



• Atributos conceptualmente iguales que cumplenroles diferentes (ej.: reservas de pasajes).

A. Múltiples referencias

Transacción “City” R e se r v a t i o n I d * Cit yI d Cit yI d

Transacción “Reservation”

Ci t y I d * Ci t y N a m e origen

destino

PROBLEMAAtributos

conel mismonombre

SOLUCION

Transacción “City”

R es e r v a t i o n I d * R e s e r v a t i o n Ci t y F r o m I d R es e r v a t i o n C i t y T o I d

Ci t y I d * Ci t y N a m e

Transacción “Reservation”

Desapareceel problema

s u b t i p o s u b t i p o

Realidad a representar/diseñar:

en cada reserva hay dos ciudades involucradas, las cuales cumplen roles diferentes.

El rol de una de las ciudades es el de ser la “ciudad de partida” (ciudad origen) y el rol de la otra esel de “ciudad de arribo” (ciudad destino).

El dominio de ambas ciudades es el mismo, el de la tabla CITY.

La forma de representar que tanto el “origen” como el “destino” son ciudades de la tabla CITY, esdiseñando la transacción “Reservation” en la forma mencionada inicialmente en la transparencia.Sin embargo, no es posible que en la estructura de una transacción figure el mismo atributo más deuna vez, pues no habría manera de identificarlos.

SOLUCIÓN: llamar a las dos ciudades de la reserva con diferentes nombres de atributos.Cualquiera de las siguientes opciones es válida. Elegimos la 3era por mayor claridad.

Opción 1) ReservationCityFromId ciudad origen

CityId ciudad destino (mismo nombre que la PK de CITY)

Opción 2) CityId ciudad origen (mismo nombre que la PK de CITY)

ReservationCityToId ciudad destino

Opción 3) ReservationCityFromId ciudad origen

ReservationCityToId ciudad destino

El problema es que al poner por ejemplo ReservationCityFromId en lugar de CityId, GeneXus deja

de inferir que ReservationCityFromId corresponde al código de una ciudad de la tabla de CITY.¿Cómo hacemos para relacionarlos, siendo que tienen diferente nombre de atributo? verrespuesta en próxima hoja …



Para estos casos GeneXus provee los SUBTIPOS, que permiten definir que dos atributos que sellaman diferente corresponden al mismo concepto.

En nuestro ejemplo, si definimos al atributo ReservationCityFromId como subtipo de CityId,estamos especificando que si bien ReservationCityFromId y CityId son diferentes atributos (de

nombres diferentes), corresponden, no obstante, al mismo concepto (una ciudad de la tabla CITY).

Al establecer que un atributo es subtipo de otro, estamos estableciendo una dependencia funcionalentre ellos.

Si ReservationCityFromId es subtipo de CityId, entonces decimos que CityId es el supertipo deReservationCityFromId.

Los atributos que se encuentran en una relación subtipo-supertipo comparten la misma definición(tipo de datos).

Se realizan los controles de integridad referencial automáticamente.

La tabla extendida que se obtiene con la definición del subtipo, es la misma que se obtendría si seutilizara directamente el supertipo.



• Con la definición de subtipos:• se establece la siguiente relación:

• Se hacen además automáticamente los controles de Integridad Referencial(IR) entre ambas tablas cuando se utilizan sus correspondientestransacciones.

• Los atributos secundarios de CITY:pertenecen a la tabla extendida de RESERVATION, pero al existir doblereferencia no se pueden utilizar directamente desde RESERVATION(ambigüedad de caminos y con valores de ciudades diferentes).

Solución definir también subtipos para los atributos secundarios deCITY, e incluirlos en c/u de los grupos de subtipos.

RESERVATION CITY


ReservationCityFromId

ReservationCityToId

IMPORTANTE:

Notar que este caso de múltiples referencias puede darse tanto:

• en la tabla base (*)

• como en la tabla extendida

(*) es el caso del ejemplo, en el que en la propia tabla (RESERVATION) hay más de una

referencia a otra tabla (CITY) y con valores diferentes.

RESUMIENDO:

siempre que desde una tabla se accede a otra que está en su tabla extendida por “más de uncamino” y con “valores diferentes” , es necesario definir SUBTIPOS, para poder llamarlediferente a los atributos y haciéndose automáticamente todos los controles de integridadreferencial.

Una vez definidos los grupos de subtipos que sean necesarios, la forma de indicarle a GeneXus cuálde los caminos debe tomar para acceder a la tabla destino, es mencionando los nombres deatributos que correspondan. Ej.: mencionar ReservationCityFromName si lo que se necesita en esemomento es el nombre de la ciudad origen, o mencionar ReservationCityToName si lo que senecesita es el nombre de la ciudad destino.




R e se r v a t i o n I d * R e se r va t i o n Ci t y F r o m I d

ReservationCityFromNameR e se r v a t i o n C it y T o I d ReservationCityToName

Transacción “Reservation” Tabla “Reservation”

R e se r v a t i o n I d * R e se r va t i o n Ci t yF r o m I d

R e se r v a t i o n C i t y T o I d FK

FK

Nombre de c/grupode subtipos.

Inferido

Inferido

Con el grupo estamos indicando que los atributos pertenecientes al mismo grupo de subtipos, estánrelacionados. Por ej., en nuestro ejemplo, GeneXus sabrá que el atributo ReservationCityToNameserá inferido a través del atributo ReservationCityToId (y no a través del ReservationCityFromId).Esto es por pertenecer ambos al mismo grupo (al de nombre ReservationCityTo).

Cuando el usuario digite un valor sobre ReservationCityToId, no solo se va a hacerautomáticamente el control de integridad referencial (que exista un ciudad con ese código en latabla CITY), sino que se va a inferir en ReservationCityToName el nombre correspondiente a ese

código de ciudad.

IMPORTANTE: Todo grupo de subtipos, debe contener un atributo o conjunto de atributos, cuyossupertipos, juntos, correspondan a la clave primaria de una tabla del modelo. Estos atributosaparecen en la ventana de edición del grupo con la categoría “class: Primary”.

Los demás atributos del grupo deberán ser de tipo “Inferred”, es decir, deberán poder inferirse através de esa clave.

En caso contrario estará mal definido el grupo.

En nuestro caso, por ej. en el grupo ReservationCityTo:

- el atributo ReservationCityToId es el único que aparece como “Primary” y podemos

comprobar que existe una tabla (CITY) cuya clave primaria es el supertipo deReservationCityToId (CityId).

- además, el resto de los atributos de ese grupo (ReservationCityToName) aparece como “Inferred”.

con lo cual, comprobamos que este grupo está bien definido.



A. Múltiples referencias en la tabla extendida

SALE COUNTRY

CUSTOMER

SELLER

un camino desde SALE a COUNTRY: a través del País del cliente (CountryId)

Otro camino desde SALE a COUNTRY: a través del País del vendedor (CountryId)

• COUNTRY pertenece a la tabla extendida de SALE por caminos diferentes ycon códigos de país diferentes.

¿qué país imprime?¿cuál de los caminos toma?Hay una ambigüedad en el modelo de datos!Layout

Si quisiéramos por ejemplo listar las ventas (SALE), y de c/u de ellas mostrar los datos del cliente(nombre, país, etc.) y del vendedor (nombre, país, etc.):

• necesitamos un for each con tabla base SALE y acceder a través de su extendida a lastablas CUSTOMER, SELLER y COUNTRY para listar los atributos secundarios del cliente,vendedor y país respectivamente.

Problema:

Los atributos de nombreCountryId

,CountryName

ytodos los de la tabla

extendida de COUNTRY pertenecen a la tabla extendida de SALE por dos caminosdiferentes: 1) a través del país del cliente y 2) a través del país del vendedor.

Solución:

Debemos diferenciarlos, llamarlos con diferente nombre de atributo peroqueriendo que se sigan representando todas las relaciones y haciéndoseautomáticamente todos los controles de integridad referencial.



A. Múltiples referencias en la tabla extendida- Solución -

SALE COUNTRY

CUSTOMER

SELLER

Cuando queremos el país del cliente de la venta: SaleCustomerCountryName

Cuando queremos el país del vendedor de la venta: SaleSellerCustomerName

S a l e C u

s t o m e

r I d

S a l e S e l l e r I d

Una vez definidos los dos grupos de subtipos que se muestran en la figura, y haciendo el cambiocorrespondiente en la estructura de la transacción Sale, queda resuelta la ambigüedad en el modelode datos!

Atributos inferidos

Atributos almacenadosen la tabla SALE



SaleCustomerCountryId SaleSellerCountryId

A. Múltiples referencias en la tabla extendida- Solución -

Problema resuelto!

Una vez definidos los subtipos, tenemos que recordar usar el nombre de atributo que corresponda alo que queremos acceder. Por ejemplo, en todos aquellos objetos GeneXus en los cuales queramosacceder al código o al nombre del país del cliente de la venta debemos usar los atributosSaleCustomerCountryId y SaleCustomerCountryName respectivamente.



B. Especialización de atributos

PERSON

TEACHER STUDENT

Ej.: Sistema para una Universidad …

SistemaStudents

SistemaTeachers

datos comunes a profesoresy estudiantes

datos propios delos estudiantes

datos propiosde los profesores

Caso de subtipos “Especialización de atributos” :

Cuando se esta modelando una categorización.

Generalmente es utilizada, cuando un objeto del negocio comparte todas las características de otroobjeto, pero agrega algunas más. La diferencia puede estar tanto en las propiedades, como en elcomportamiento que tendrá.

Ejemplo “Sistema para una Universidad”:

En este ejemplo, el profesor y el alumno tienen roles y comportamientos claramentediferenciados . Por ejemplo, el profesor tendrá cursos asignados, sueldo, etc. El alumno estaráinscripto a un curso, tendrá asignados pagos, asistencia, escolaridad, etc.

Estamos frente a un caso en el que los roles y el tratamiento de las entidades de la categorizaciónestán claramente diferenciados.

Tanto los estudiantes como los docentes comparten información común (ambos tienen un nombre,una dirección, etc) pero también tienen información que difiere, que es propia de c/u de ellos.

Para representar esta realidad, se crean las tres transacciones: “Person”, “Teacher” y “Student”.

En la transacción “Person” figura la información común. Para representar que tanto los estudiantescomo los docentes son personas, se utilizan los subtipos.

Al definir que el identificador de “Teacher” es subtipo del identificador de “Person” estamosestableciendo esta relación.

Cada vez que se inserte un registro en la tabla TEACHER a través de su transacción, se realizará elchequeo de integridad referencial contra “Person”. Asimismo, cada vez que se intente eliminar unregistro de “Person”, se verificará primeramente que no exista ningún registro en la tabla TEACHER(ni en STUDENT) con el mismo valor en la clave primaria.



B. Especialización de atributos

“Person” “Teacher”

“Student” PersonId*PersonNamePersonAddress

TeacherId*TeacherNameTeacherAddressTeacherSalary

StudentId*StudentNameStudentAddressStudentAverage

• Se crean 3 tablas físicas.• Se realizan chequeos de IR contra la tabla PERSON.

Transacciones:

La transacción “Teacher” tiene asociada una tabla que contendrá físicamente sólo dos atributos:TeacherId y TeacherSalary.

Al ser TeacherId identificador de la transacción, será la clave primaria de la tabla asociada. Además,al ser un subtipo de PersonId, será una clave foránea a la tabla PERSON. Por lo tanto, se harán loschequeos de integridad referencial correspondientes.

Los atributos TeacherName y TeacherAddress son subtipos de PersonName y de PersonAddressrespectivamente y están agrupados con TeacherId, por lo que serán inferidos de la tabla PERSON, através de la clave foránea TeacherId (no están almacenados en la tabla TEACHER).



C. Subtipos recursivos

• Ejemplo: Employee-Manager

Error(‘Debe ingresar un gerente para el empleado’)if EmployeeIsManagerFlag=‘N’ and EmployeeManagerId.isnull();

Tabla EMPLOYEEEm p l o ye e I d *

Em pl oy eeNa m e E m p l o y e e I sM a n a g e r Fl a g

Em p l o y e e M a n a g e r I d

FK

Es posible tener una tabla subordinada a sí misma definiendo subtipos.

Este tipo de subtipos se utiliza para modelar las relaciones recursivas. Por ejemplo, la relación entreEmpleado y Gerente:

- cada empleado tiene un gerente. Un gerente, a su vez, es un empleado (aquí está la recursión).

- un gerente puede tener varios empleados a su cargo

Si además la realidad a representar es que “sólo los empleados que no son gerentes tienen ungerente”, entonces, cuando se ingresan los datos hay que realizar los siguientes controles:

-cuando se ingresan los gerentes, hay que permitir dejar en nulo el atributo EmployeeManagerId.Para esto, cambiamos a ‘Yes’ la columna Nulls del atributo EmployeeManagerId, el cual es FK en latabla EMPLOYEE.

que todo empleado que no es gerente, tenga un gerente. Este control lo hacemos con la regla errorque se muestra en la figura.

El atributo EmployeeManagerName no queda almacenado en la tabla EMPLOYEE, se infiere luego deingresar un valor en EmployeeManagerId.

Por ser EmployeeManagerId subtipo de EmployeeId, se realizan automáticamente los controles deintegridad referencial de la tabla consigo misma. Esto se puede ver en la navegación de latransacción, como se muestra en la siguiente página.



• Listado de navegación detallado:

C. Subtipos recursivos



D. Evitar controles de integridad referencial

Su p p l i e r I d *Su p p l i e r N a m e P r o d u c t I d * P r o d u c t D e s c r i p t i o n P u r c h a s e O r d e r H i s t o r y Q u a n t i t y

Su p p l i e r I d * Su p p l i e r N a m e …

P u r c h a s e O r d e r I d * Su p p l i e r I d

P r o d u c t I d P u r c h a s e O r d e r Q u a n t i t y

P r o d u c t I d * P r o d u c t D e s c r i p t i o n

…

Purchase Order History Supplier

Purchase Order Product

En la figura indicamos con flechas los controles que queremos que GeneXus realiceautomáticamente.




Su p p l i e r I d *Su p p l i e r N a m e P r o d u c t I d * P r o d u c t D e s c r i p t i o n P u r c h a s e O r d e r H i s t o r y Q u a n t i t y





…



Pero los controles que en realidad realiza GeneXus en forma automática son los que se muestran enesta figura.

En este ejemplo, no queremos que se realice el chequeo que va de la tablaPURCHASEORDER sobre la tabla PURCHASEORDERHISTORY , porque la orden de compra serealiza antes de que efectivamente se realice la compra, por lo cuál, si es la primera compra que serealiza para ese proveedor de ese producto, lógicamente los datos de esa compra no estarán aún

dados de alta en el histórico.

Observar además que en la transacción “Purchase Order” no se está haciendo automáticamenteun control que sí queremos que se haga: el control de proveedor contra la tabla SUPPLIER y deproducto contra PRODUCT. Estos controles no se están haciendo porque al efectuarse el chequeocontra PURCHASEORDERHISTORY, se supone que ya en esa transacción se chequeó que el productofuera válido y que el proveedor fuera válido.



Su p p l i e r I d *Su p p l i e r N a m e P u r c h a se Or d e r H i s t o r y P r o d u c t I d * P u r c h a s e O r d e r H i s t o r y P r o d u c t D e s c r i p t i o n P u r c h a s e O r d e r H i s t o r y Q u a n t i t y

Purchase Order History

Solución


¿Cómo evitar que GeneXus controle que el proveedor y producto de una orden de compraexistan en la tabla de histórico de compras?

Alcanza con cambiarle el nombre de atributo al código de producto (o al código de proveedor) en elhistórico de compras, pero conservando el concepto al que corresponde (es decir, definiéndolo comosubtipo de producto o de proveedor según corresponda).

La solución elegida fue la de cambiarle el nombre al atributo que corresponde al producto en elhistórico de compras, le cambiamos a PurchaseOrderHistoryProductId. Además, definimos a dichoatributo como subtipo de ProductId, para seguir manteniendo la relación que hay entre “PurchaseOrder History” y “Product”.








…



Su p p l i e r I d *Su p p l i e r N a m e Pu r c h a s e Or d e r H i s t o r y P r o d u c t I d * P u r c h a s e O r d e r H i s t o r y P r o d u c t D e s c r i p t i o n P u r c h a s e O r d e r H i s t o r y Q u a n t i t y

Luego de haber definido el grupo de subtipos mencionado, y en él a PurchaseOrderHistoryProductIdcomo subtipo de ProductId y a PurchaseOrderHistoryProductDescription como subtipo deProductDescription y usarlos en la transacción “Purchase Order History”, los controles que realizaGeneXus son los que se muestran en la figura (los controles deseados).

Como ya no existe una tabla de clave primaria compuesta por los nombres de atributos “SupplierId,ProductId”, los controles de que el SupplierId y el ProductId digitados en la transacción “Purchase

Order” existan se hacen sobre las tablas SUPPLIER y PRODUCT respectivamente.



Consideraciones

• El subtipo y supertipo serán definidos del mismo tipo,GeneXus lo determina así y cuando se define un subtipoéste "hereda" la definición del supertipo.

• Al menos uno de los supertipos del grupo (o conjunto desupertipos del grupo) debe(n) corresponder a la PK de unatabla del modelo.

• Si al definir el grupo, algún atributo queda como “Secondary” (en lugar de “Primary” o “Inferred”), significaque hubo un error en la definición del grupo.



• Es posible actualizar los “subtipos inferidos”.Ejemplo:

Consideraciones

Rules:

Primary

Inferred

Es posible actualizar subtipos inferidos, tanto en las reglas de las transacciones como enprocedimientos.

Al ejecutar la regla de la transacción Invoice que se muestra en la figura, el atributo que seactualiza físicamente es el supertipo CompanyPurchases de la tabla COMPANY. Vale aclarar queCustomerPurchases (al igual que CustomerName) es subtipo inferido y por lo tanto no estáalmacenado en ninguna tabla.

Tabla extendida de INVOICE: INVOICE, CUSTOMER, COMPANY.Tabla extendida de CUSTOMER: CUSTOMER, COMPANY.Tabla extendida de COMPANY: COMPANY.

Tabla INVOICE Tabla CUSTOMER Tabla COMPANY

InvoiceId* CustomerId* CompanyId*InvoiceDate CompanyNameCustomerId CompanyPurchasesInvoiceTotal



• En ambientes que generan SQL es posible ordenar porsubtipos inferidos.

• Siguiendo con el ejemplo anterior: es posible recorrer lasfacturas ordenadas por nombre de cliente, CustomerName,subtipo inferido a través de CustomerId:

For each order CustomerName

print Invoice…

endfor

Consideraciones

Esta posibilidad no está disponible para los generadores que no usan SQL.

Por ejemplo: Cobol, RPG y VFP.



• Fórmulas verticales pueden involucrar subtipos.

Ejemplo:

Consideraciones

En el ejemplo, se desea modelar la relación entre personas (Parejas) y sus Hijos. Para cada pareja sedesea mantener la cantidad de hijos que tiene.

Para esto se define la transacción “Person” y luego “Couple”, siendo el esposo, esposa e hijos subtiposde personas.

Los 3 grupos de subtipos definidos son:



La cantidad de hijos se calcula con el atributo CoupleChildrenQuantity definido en el primer nivel de latransacción “Couple”, como fórmula COUNT que involucra en su definición a un subtipo inferido(CouplePersonChildAge).



Consideraciones

• Los subtipos inferidos no se pueden definir comoredundantes.• Ejemplo:

No se pueden definir como redundantes enla tabla COUPLE.



TIPOS DE DATOS ESTRUCTURADOS



Tipos de datos estructuradosIntroducción

• Los lenguajes de programación manejan tipos de datos simples y tipos

de datos complejos• Los tipos de datos complejos se construyen sobre la base de los tipos

de datos simples

• Los tipos de datos complejos conocidos como registros o tipos dedatos estructurados, permiten representar conjuntos de datos que

juntos realizan una definición

• Ejemplo:

Luego se definen variables de este tipo,listas de elementos de este tipo, etc.

Type Customer = Record

Id: Numeric(4)

Name: Character(30)

Country: Character(20)

City: Character(20)

Address: Record

CompanyAddress: Character(30)

HomeAddress: Character(30)

end;

end;



Tipos de datos estructuradosGeneXus

• ¿Cómo definir un tipo de datos estructurado?

1. Object / New Object2. En el árbol del ambiente de desarrollo: Structured Data Types... y en

la ventana de al lado: botón derecho

• Editor similar al de transacciones y ofrece las mismas teclas de función:

• Generadores que soportan este tipo de definición: JAVA, .NET, VB

El editor de tipos de datos estructurados es sumamente similar al editor de transacciones yofrece las mismas teclas de acceso rápido.

Para cada ítem de un tipo de datos estructurado, se debe especificar:

La propiedad Name, con el nombre que identifica al ítem.

La propiedad Data type, en la cual se debe seleccionar un tipo de dato simple, o un dominio, oun tipo de datos estructurado que ya se haya definido.

La propiedad Collection, para indicar si el ítem tiene o no múltiples instancias (en breveveremos ejemplos que permitirán comprender su uso en detalle).

En particular los ítems que definen un nuevo nivel, se anteceden con el ícono , no se leshabilita la propiedad Data Type y se produce la indentación correspondiente para los ítemscorrespondientes a dicho nivel.

Una funcionalidad interesante a tener en cuenta, es que además de definir ítem a ítem en un tipode datos estructurado, también está la posibilidad de definir rápidamente en la estructura de untipo de datos estructurado, la misma definición de cierta transacción. Para realizar esto, una vezcreado un nuevo tipo de datos estructurado y al estar editando el mismo, se debe pulsar el botónderecho del mouse sobre su raíz, y seleccionar la opción Copy structure from… :



Tipos de datos estructuradosUtilización

• Se definen variables (en cualquier objeto GeneXus) cuyo tipo de datos = tipo

de datos estructurado:

• No es posible utilizar tipos de datos estructurados en la definición deatributos



Tipos de datos estructuradosEjemplos de utilización

Ejemplo # 1

• En un proc. se define una variable (&Customer) cuyo tipo de datos es del tipode datos estructurado: Customer• El proc. recibe por parámetro un código de cliente, accede con comando ForEach a los datos del cliente recibido y carga los datos del cliente en la variable&Customer:

Rule:Parm(CustomerId);

Source:For each&Customer.Id=CustomerId&Customer.Name=CustomerName&Customer.Country=CountryName&Customer.City=CityName

&Customer.Address.CompanyAddress=…&Customer.Address.HomeAddress=…

Endfor

Como se está cargando una variableescalar y no una lista o colección, no haynecesidad de solicitar espacio dememoria, ya que el espacio de memoria

está creado para la variable como paraser utilizada una vez.

Dado que en este ejemplo se está cargando una variable escalar y no una lista o colección,no hay necesidad de solicitar espacio de memoria, ya que el espacio de memoria está creadopara la variable como para ser utilizada una vez; así que simplemente se deben asignar losvalores que corresponda a los ítems de la variable.

Para cargar una colección, en cambio, sí habrá que solicitar espacio de memoria para lavariable para cada instancia a ser agregada en la lista; luego de solicitado el espacio dememoria, habrá que asignar los valores que corresponda a los ítems de la variable, y porúltimo agregarla a la lista o colección, como veremos.




Ejemplo # 2:

• Partiendo del tipo de datos estructurado: Customer, utilizamos la opciónObject / Save Structured Data Type As para crear un nuevo tipo de datosestructurado de nombre: Customers

• Hacemos una modificación al tipo de datos estructurado: Customers propiedad collection de la raíz = True:




Ejemplo # 2:

• Configurar la propiedad collection=True para un ítem, define que se trata deuna colección de esos ítems y no de uno solo.

• Notar que al configurar la propiedad collection de un ítem con valor True,automáticamente se define un nombre por defecto para la propiedad I tem namede ese ítem:

Esto permite que podamos definirvariables del tipo de datosestructurado Customers, y a suvez variables del tipo de datosCustomers.CustomersItem

Por ejemplo, de haber configurado para el ítem CompanyAddress la propiedad collection convalor True, habríamos indicado que se trata de una colección o lista (de largo variable) deAddresses de empresa, y no de una sola. Análogamente, dado que lo que hemos implementadoes que el ítem: Customers (es decir, la raíz del tipo de datos estructurado) tenga valor True en lapropiedad collection, lo que hemos definido es que se trata de una colección de Customers y node un Customer solo.

Es importante notar que al configurar la propiedad collection de un ítem con valor True,automáticamente se define para la propiedad I tem name de ese ítem un nombre por defecto(en este caso: CustomersItem). Esto permite que podamos definir variables del tipo de datosestructurado Customers, y a su vez variables del tipo de datos Customers.CustomersItem.

Es sencillo de comprender que definir una variable del tipo Customers significará que estaremosdefiniendo una colección o lista de Customers, mientras que definir una variable del tipoCustomers.CustomersItem, significará que estaremos definiendo un solo Customer (o un ítem dela colección de Customers, que veremos enseguida cómo hacer para agregarlo a la colección).




Ejemplo # 2:

• Implementamos proc. que carga una lista de clientes

• El proc. recibe por parámetro un rango de códigos de clientes, con comando ForEach accedemos a los clientes que se encuentren en dicho rango, y los vamosagregando a la colección.

Rule:Parm(&CustomerIdStart, & CustomerIdEnd);

Se definen 2 variables:&Customers (Data Type: Customers)&CustomersItem (Data Type: Customers.CustomersItem)

Source:




Ejemplo # 2:

Source:

For eachwhere CustomerId>=&CustomerIdStart and CustomerId<=&CustomerIdEnd

&CustomersItem.Id=CustomerId&CustomersItem.Name=CustomerName&CustomersItem.Country=CountryName&CustomersItem.City=CityName&CustomersItem.Address.CompanyAddress=…&CustomersItem.Address.HomeAddress=…&Customers.add(&CustomersItem) /*s e agrega el ítem a la lista*/

&CustomersItem = new Customers.CustomersItem() /*s e solicita nuevoespacio de memoria

para próximo ítem*/Endfor

Como ya hemos mencionado, para una variable hay creado espacio de memoria como para ser utilizadauna vez. Si se necesita crear otra instancia para la variable, habrá que solicitar espacio de memoria para lamisma, para lo cual contamos con el operador new.




Ejemplo # 2:

• ¿Qué pasaría si no solicitamos nuevo espacio de memoria en cada iteración delfor each? ... es decir, si omitimos el new en el código anterior ...

• En cada iteración estaríamos sobreescribiendo el mismo espacio de memoria... yagregando a la lista siempre punteros al mismo espacio de memoria.




Ejemplo # 2:

• Sin embargo lo que necesitamos implementar se esquematiza de la siguienteforma:

• Por lo tanto, es necesario ir solicitando un nuevo espacio de memoria para cadareferencia a ser agregada en la lista



Ejemplo # 3:

• Hacemos lo mismo que en el ejemplo #2 (proc. que carga una colección declientes), mostrando otra solución

•En este caso:

• utilizamos la definición del tipo de datos estructurado: Customer

• y definimos otro tipo de datos estructurado: CustomerList

• &CustomerList (Data Type: CustomerList)&Customer (Data Type: CustomerList. CustomerListItem)


Se definen2 variables



Ejemplo # 3:

Source:

For eachwhere CustomerId>=&CustomerIdStart and CustomerId<=&CustomerIdEnd

&Customer.OneCustomer.Id=CustomerId&Customer.OneCustomer.Name=CustomerName&Customer.OneCustomer.Country=CountryName&Customer.OneCustomer.City=CityName&Customer.OneCustomer.Address.CompanyAddress=…&Customer.OneCustomer.Address.HomeAddress=…&CustomerList.add(&Customer) //se agrega el ítem a la lista

&Customer = new CustomerList. CustomerListItem() /* se solicita nuevo

espacio de memoria

Endfor para próximo ítem */


En este caso la variable &customersitem es del tipo de datosListaCustomers.ListaCustomersItem, el cual contiene un único ítem que es: OneCustomer;y dado que el ítem OneCustomer es del tipo de datos Customer, este contiene los ítems Id,Name, Country, City, etc.

De modo que si bien el ejemplo #3 implementa exactamente lo mismo que el ejemplo #2,como en este último hemos optado por otra alternativa de definición de tipos de datosestructurados, la sintaxis en este caso queda un poquito más extensa.



Tipos de datos estructuradosOperadores, métodos y propiedades

N e w

Es un operador que retorna una nueva instancia inicializada, o sea una nueva referencia o puntero altipo de datos que se especifica.

Sintaxis: &VbleDeTipoDeDatosEstructurado = new TipoDeDatosEstructurado()

A d d

Es un método para aplicar a variable de tipo colección. Agrega un ítem a una colección, en la posiciónrelativa especificada.

Sintaxis: &VbleDeTipoColeccion.Add(&VbleItem [, Position])

Nota: Si se omite Position o se especifica 0, se agrega el Item al final de la colección. Position comienzaen 1.

I t e m Es un método para aplicar a variable de tipo colección.

Sintaxis: &VbleDeTipoColeccion.Item(Position)

Retorna una referencia al elemento que se encuentra en la colección en la posición relativa Position.

En caso de especificar posición mayor a la última, el programa cancela.

No es válido asignar un valor con esta propiedad, por lo tanto no es correcto el código&VbleDeTipoColeccion.item(&i) = Att. Para cambiar un valor se debe remover (método remove) yagregar (método add).



Rem ov e

Es un método para aplicar a variable de tipo colección. Elimina el elemento que se encuentre en lacolección en la posición relativa que se especifique, y corre un lugar todas las posiciones.

Sintaxis: &VbleDeTipoColeccion.Remove(Position)

Clear

Es un método para aplicar a variable de tipo colección. Elimina todos los elementos de la colección.

Sintaxis: &VbleDeTipoColeccion.Clear()

So r t

Es un método que permite ordenar los elementos de una colección.

El campo por el cual se quiere ordenar debe ir entre comillas.

Sintaxis: &VbleDeTipoColeccion.Sort(“NombreCampoPorElCualOrdenar")

Es posible ordenar en forma descendente, poniendo dentro de las comillas al nombre del campo entrecorchetes rectos.

Es posible ordenar por más de un campo, poniendo dentro de las comillas los nombres de los camposseparados por coma.

C o u n t

Es una propiedad de variable de tipo colección. Retorna la cantidad de elementos de la colección. Es readonly.



For & V a r in & A r r a y ...

Endfor

&Var: debe ser del tipo de datos de un ítem de la colección&Array: debe ser del tipo de datos que es colección

La variable &Var va tomando los valores de cada posición de la lista

Consideraciones:• No es posible obtener la posición del vector durante la recorrida, para esto esnecesario definir un variable que actúe como contador.• No es posible modificar los ítems de la lista en la recorrida. Esto significa quecambios en el valor de &Var, en el alcance de la estructura, no afectan alcorrespondiente valor del &Array(X) o viceversa.

• Es posible incluir comandos de “corte” de la recorrida, al igual que en for eacho do while, como exit o return.

Tipos de datos estructuradosComando para recorrer colecciones



Ejemplo: Inserción de variable &Invoice de tipo de datos estructurado Invoice:

en form de Transacción, Work panel o Web panel

Tipos de datos estructuradosCómo mostrarlos en form

Es posible insertar en el form de Transacciones, Web y Work Panels variables de tipo de datosestructurados. También es posible hacerlo en print blocks de reportes, siempre y cuando no seancollection.

Desplegar una collection en un form se puede hacer de forma muy sencilla: solamente es necesarioinsertar la variable en el form, y quedará asociada a un grid que será cargado automáticamente, sin

necesidad de código alguno.



2 posibilidades:

Notar que es una sola variable definida (NO una variable por c/ atributo)

2) Insert/Variablepermite selección múltiple

1) Pallete Toolbar shortcut

Hay que repetir este paso para c/atributo del 1er nivel que sedesee mostrar en el form




En cuanto al grid:

Carga automática:

¡No se requiere código!


Como hemos visto, hay 2 posibilidades para insertar una variable de tipo SDT con sus respectivos atributos en unform / layout:

•mediante el shortcut : cada &variable.atributo uno a uno

•mediante insert/variable: múltiple selección de atributos de variable de tipo SDT

Si utilizando la opción insert/variable se selecciona algún (o algunos) atributo(s) correspondientes a una collection,

dicho(s) atributo(s) se agregarán automáticamente en un grid (y en las “Grid Properties” del grid, se podrá observarque automáticamente se habrá asignado en el combo “Collection”, el nombre del nivel al cual pertenecen losatributos).

Si en cambio se utiliza el shortcut para ir agregando atributos del primer nivel del SDT en el form, y se utiliza elshortcut para agregar un grid en el form con el fin de mostrar una collection, el analista

tendrá que seleccionar explícitamente en el combo “Collection” de las “Grid Properties”, el nivel del SDT, para luegopoder seleccionar cuáles atributos de dicho nivel desea incluir en el grid.

En tiempo de ejecución, la carga del grid se realizará en forma completamente automática, con el contenido de lacollection. Esto podrá verse en el listado de navegación:

Nota: Un detalle a tener en cuenta es que independientemente de la forma en que se seleccionen los atributos de unacollection para ser mostrados en un grid, los mismos estarán en columnas visibles del grid, y los restantes atributosdel nivel (los no seleccionados) se agregarán hidden.



• Propiedad CurrentItem:

• Para collections

• Permite desplegar información de los atributos del ítemactual en el grid

• Ejemplo:

Event ‘DisplayProductDescription'msg(&invoice.line.CurrentItem.ProductDescription)

EndEvent


Si por ejemplo en el work panel visto (Invoice) deseamos agregar un botón con un evento asociado y mostrar unmensaje para la línea del grid seleccionada, con información de ese ítem de la colección, contamos a partir de laversión 9.0 con la propiedad CurrentItem.



BUSINESS COMPONENTS



Business Components

Objetivo

Reutilizar la lógica del negocio definida en las transacciones. Usar el poderde las transacciones (sin sus forms) desde otros objetos GeneXus:

- Work panels, Web panels, Procedimientos, Reportes…… y desde otra Transacción!- Java, .Net- Win, Web

Beneficios

- Actualización a la BD garantizando la integridad de los datos.- Reutilización de código.- Todos los objetos GX pueden actualizar la BD.



• Work Panels / Web Panels / Transacciones:

Definir interfaces sofisticadas permitiendo insertar los datos correspondientes a 2 o mástransacciones por medio de una (o por medio de un Work Panel o Web P anel)!

• Personalizar UTL entre 2 o más transacciones Web!• Utilizar un único form para insertar en una Especialización u otro caso

• Procedimientos:

Utilizar concepto de BC en vez de For Each, New, Delete cuando se deseen ejecutar las reglasdefinidas en la Transacción, controles IR, mantenimiento de redundancia, sin duplicar código

• Web Services:

Es posible permitir que desde fuera de la K B se consuma un BC como w eb service

Business ComponentsAlgunos ejemplos de uso

Consumir un BC como web service

Un Web Service es un programa que puede ser invocado a través de Internet “para brindar

un servicio”, y utiliza el estándard XML para el formato de los datos recibidos/devueltos.

La versión 9.0 de GeneXus ofrece que desde fuera de la KB sea posible consumir un BC comoweb service.

Para esto hay que:

Marcar a la transacción como BC:

Propiedad Business Component = True

Marcar a la transacción como Web Service:

Propiedad Expose as Web Service = True



1. Configurar la propiedad Business Component de la Transacción convalor True (default=False).

2. Una vez que la propiedad Business Component de cierta Transacción =True

En cualquier objeto GeneXus se podrá definir una variable del tipo dedatos BC asociado a la transacción, y configurar sus propiedades ymétodos.

Veamos un ejemplo …

Business Components¿Cómo definir un Business Component?



Business ComponentsEjemplo: Inserción de una invoice con 2 líneas mediante proc.

Business Component = True

Dos nuevos tipos de datos creados por GeneXus:• Invoice nombre de la transacción• Invoice.LineType nombre de la transacción.valor de la columna “Type” del nivel

En cualquier objeto será posible definir variables de estos tipos de datos… y las mismas tendrán:• un conjunto de propiedades asociadas (los atributos de la TRN definida como BC)

• un conjunto de métodos asociados (para insertar, eliminar, recuperar, etc.)

variable del tipo dedatos BC Invoice

métodos

propiedades

Las transacciones tienen la propiedad Business Component. El valor predeterminado de estapropiedad es False. Si se cambia al valor True, la transacción puede ser invocada desdecualquier objeto GeneXus como Business Component, sin ejecutar su form.

Una vez definida una transacción como Business Component, GeneXus creará automáticamenteun nuevo tipo de datos Business Component cuyo nombre será el de la transacción; y creará

también tantos tipos de datos como niveles posea la transacción, siendo sus nombres elresultado de la concatenación del nombre de la transacción con el nombre dado a cada nivel(valor de la columna “Type” del nivel).



• Source del procedimiento: //invoice&Inv.InvoiceId = 1

&Inv.CustomerId = 50 //invoiceline&Invline.ProductId = 1&Invline.InvoiceLineQuantity = 10&Inv.Line.Add(&Invline)

&Invline = new Invoice. LineType()

&Invline.ProductId = 2&Invline.InvoiceLineQuantity = 20&Inv.Line.Add(&Invline)

&Inv.Save() //

&Messages= &Inv.GetMessages()for &Message in &Messages

msg( &Message.Id)msg( &Message.Description)

endfor

Commit

Se ejecutan los controles de IR, mantenimiento de redundancias, fórmulas, eventos Start yAfter Trn y las reglas de la transacción Invoice. El form de la trn NO se ejecuta.

&Inv tipo de datos BC Invoice

&InvLine tipo de datos BC Invoice.LineType

Recomendación: después de los métodos Save, Delete Loady Check, manejar siempre los errores.

Los BC ignoran la property del objeto “Commit on exit” Nunca hacen commit/rollback automáticamente. Recordar ponerlos explícitamente

Business ComponentsEjemplo: Inserción de una invoice con 2 líneas mediante proc.

a partir del 2do registro a dar de altaen una lista es necesario el new

hay que hacer sólo &Inv.Save(), NO hay que hacer&InvLine.Save()



• Reglas: Todas las reglas son ejecutadas excepto (son ignoradas por elespecificador):

• las que incluyen user interface (Ej: call(Wxxx)).• las que no aplican: Parm, Prompt, NoPrompt, Default_mode, etc.

• Eventos: Todos los eventos de la transacción son ignorados, exceptolos eventos Start y After TRN (y si éstos incluyen referencias a objetoscon user interface, se ignoran).

ACLARACIÓN: lo explicado que se ignora, aplica solamente a cuando latrn es invocada como BC desde cualquier objeto GX.

Business ComponentsReglas y eventos que se ejecutan



• Existe un tipo de datos estructurado (SDT) predefinido por GeneXus de nombreMessages:

• Hay que definir una variable del tipo de datos Messages y asignarle el resultadode aplicar el método GetMessages a la variable de tipo BC :

&Messages= &Inv.GetMessages()

• Se obtendrán:• Los mensajes generados automáticamente por GeneXus que se hayan

disparado (Ej.: Record already exist)• Las reglas Error y Msg definidas en la transacción que se hayan disparado

• Hay que recorrer la lista de errores y trabajarlos

Business ComponentsManejo de errores

Cuando se ejecutan los métodos: Save, Check, Load, Delete se disparan y cargan los mensajesgenerados automáticamente por GeneXus así como las reglas Msg y Error definidos en latransacción. Se recomienda que siempre se recupere la lista de estos mensajes y se haga un

“manejo de errores”.

Los mensajes más comunes generados automáticamente por GeneXus son:

Las reglas Msg y Error a partir de la versión 9.0 de GeneXus, aceptan en su definición además delparámetro con el mensaje a desplegar, un segundo parámetro que define el Identificador delmensaje. El objetivo de esto, es que cuando se ejecute a la transacción como BussinessComponent, y se obtenga la lista de mensajes ocurridos luego de ejecutar una acción sobre la basede datos, se tenga de cada mensaje, además del mensaje en sí, su identificador, siendo posible así evaluar el identificador del mensaje para codificar el comportamiento en consecuencia:

Msg|Error(<mensaje>, <Id del mensaje>)

Ejemplos de <Id del mensaje>: "1", "2", "Error1", "Error2" o una descripción como ser"CustomerNameCannotBeEmpty", etc.

De no especificar un identificador para el mensaje, habrá que preguntar por el texto del mensaje.

Nota: Para los mensajes generados automáticamente por GeneXus, el Id es siempre en Inglés(independientemente del idioma seleccionado en el modelo).



Load(P KAttri1, ..., PKAt triN)• Carga en variable de tipo BC toda su estructura• Ej: &Empleado.Load(&EmployeeId)

Check()• Valida los datos pero no actualiza la base de datos• Usado para diálogos en los que se quiere validar los datos (dándole un feedback al usuario) antes

de actualizar la BD

Save()• Valida los datos y actualiza la base de datos• Sólo válido para aplicar a variables de tipo BC del primer nivel de la transacción• Ej: &Inv.Save()

commit

Delete()• Elimina en la base de datos el registro cargado en la variable de tipo BC

• Ej:

Business ComponentsMétodos asociados a las variables de tipo de datos BC

&Empleado.Load(&EmployeeId)&Empleado.Delete()commit

PK del primer nivel de la transacción



GetMessages()• Devuelve la lista de errores que ocurrieron luego de efectuar una operación a la BD• Ej: &Messages= &Inv.GetMessages()

Fail()• Devuelve True si luego de haber efectuado una operación a la BD dio algún error• Ej: &Inv.Save()

If &Bc.Fail()&Messages = &Inv.GetMessages()for &Message in &Messages

.....

Success()• Devuelve True si luego de haber efectuado una operación a la BD, la operación fue exitosa

Add(&BCLine)

• Permite agregar un ítem a una colección (en este caso, a la colección de líneas correspondiente aun nivel subordinado de la variable BC)

• Ej.: &Inv.Line.Add(&Invline)

Business ComponentsMétodos asociados a las variables de tipo de datos BC

Los métodos GetMessages() , Fail() y Success() se han explicado recientemente al mostrar elmanejo de errores.



Ejemplo para un web p anel, con variable de tipo de datos BC Invoice…

1. Crear en web panel variable &Invoice del tipo de datos BC Invoice2. Insertar la variable &Invoice en el form (vale lo mismo explicado para insertar variables de tipo SDT... ya

que un BC es un SDT con la estructura de su transacción).3. Programar los eventos:

Event 'Get'&Invoice.Load(&Invoice.InvoiceId)do "error handling"EndEvent // 'Get‘

Event 'Save'&Invoice.Save()do "error handling"if &Invoice.Fail()

rollbackelse

commitendif EndEvent // 'Save'

Business Components¿Cómo programar un BC en un

work panel, web panel o reporte?

Event 'Delete'&Invoice.Delete()do "error handling"if &Invoice.Fail()

rollbackelse

commitendif

EndEvent // 'Delete'

Sub "error handling"&Messages=&Invoice.GetMessages()for &Message in &Messages

msg(&Message.Id)msg(&Message.Description)

endforEndSub

Desventajas con respecto a la Trn Invoice:- Hay que poner noaccept para aquellas variables que no se deseen aceptar- No se cuenta con la property Client Side Validation- En la Trn no hay que hacer la codificación de estos eventos



Business Components¿Qué es mejor: actualización “directa” o “usando BC”?

Directa:

NewCustomerId = &CustomeriIdCustomerName = &CustomerName

Endnew

Usando BC:

&Customer.CustomerId = &CustomerId&Customer.CustomerName = &CustomerName&Customer.Save()

¿Cuál de los métodos es el mejor?

Depende.

- Desde el punto de vista de la performance , la “directa” es la mejor ya que no se hacen controles.

-Desde el punto de vista de la consistencia, es mejor usar BC ya que siempre(independientemente de si los datos vienen desde un form o de un procedimiento) se hacen todoslos controles.

Por lo tanto, una buena regla podría ser: “Usar Business Components a menos que la performancesea crítica”.

De modo que para elegir una opción u otra, el analista deberá evaluar en cada caso qué necesitaefectuar, si la transacción implicada tiene muchas reglas definidas o no, fórmulas, chequeos de IRrelacionados, redundancias... y tener en cuenta los factores consistencia y performance .



KNOWLEDGEMANAGER



Se generará elarchivo

MyObjects.xpzen la raíz de la

KB

Distribución

Una vez seleccionados los objetos a distribuir (exportar) e indicado el nombre del archivo dedistribución (en el ejemplo: MyObjects), se crea automáticamente un archivo comprimido deextensión XPZ. Este archivo comprimido contiene dentro un archivo XML que contiene la informaciónde los objetos y/o atributos distribuidos.

En Distribution Name podemos poner un path donde guardar el archivo de distribución. Si no se ponepath, como en el caso de arriba, entonces quedará almacenado en el directorio raíz de la Base deConocimiento.

En el ejemplo, si abrimos el archivo MyObjects.xpz con una herramienta tipo WinZip, veremos quecontiene un archivo de nombre MyObjects_1.xml

Distribute Options

Append to Fi le: Si en el Distribution Name del diálogo de distribución se ingresa de nombre unarchivo que ya existe, al salir del campo se habilita esta opción para poder agregar la nuevadistribución al archivo existente.

Si se marca la opción Append to File, se crea un nuevo archivo XML dentro del mismo XPZ. Siguiendocon el ejemplo anterior, se crearía un archivo MyObjects_2.xml en el archivo MyObjects.xpz. Si yaexiste un archivo con ese nombre, se incrementa el sufijo en uno y se vuelve a intentar.

Si no se marca la opción Append to File, el archivo se reemplaza con la nueva distribución.

Version 7.0 (And prior): Mediante esta opción es posible que el archivo de exportación resultantesea creado con el formato utilizado hasta la versión 7.0 de GeneXus inclusive (extensión XPW).



Pide el path del archivo

a ser consolidado

Consolidación

La forma de importar objetos, atributos y dominios GeneXus dentro de una base de conocimiento esmediante la opción Consol idate del Knowledge Manager. Lo que se importa son objetospreviamente distribuidos, en un archivo que puede tener tres formatos: XPZ, XML o XPW.

XPZ: Cuando se selecciona un archivo con este formato, el Knowledge Manager (KMW) recorre elcontenido del archivo XPZ y consolida cada uno de los archivos internos, siempre y cuando tenganel formato XML apropiado.

XML: En algunos casos puede ser necesario consolidar algún XML en particular de todos los quecontiene el XPZ. Para este caso se puede descomprimir y consolidar directamente el XML.

XPW: Para poder tener compatibilidad con las versiones anteriores de GeneXus, existe uncomponente encargado de realizar la conversión de un archivo XPW a un archivo XML.

La consolidación solo puede ser realizada en el modelo de Diseño. Procesos de verificación yconsolidación son ejecutados simultáneamente una vez que hemos seleccionado el archivo dedistribución y presionado Ok. Una vez que esos procesos terminan se despliega una ventana con losresultados para que el usuario pueda observarlos.



GX OPEN



GX Open

• GX Open es un sitio que ofrece compartir proyectosentre los miembros de la comunidad GeneXus.

• Cada proyecto puede tener varias versiones. Para cadaversión, se pueden almacenar todos los archivosrelacionados al mismo: XPZs, imágenes, propiedadessalvadas, docs, etc.

• Cada proyecto y versión tiene un foro, así los usuariospueden discutir acerca del mismo, y proponer cambios.

• Para bajar o subir proyectos es necesario registrarsecomo miembro (sin cargo).

www.gxopen.com



PUESTA EN PRODUCCIÓN



• Una vez que el prototipo ha sidocompletamente testeado y aprobado, llegael momento de poner en producción laaplicación…

Puesta en Producción



Creación de modelo de Producción

Primera vez:

1. Una vez que el prototipo ha sido aprobado, es momento de “pasar a producción”, creando un modelo deProducción. Este modelo tendrá como plataforma la del cliente, dado que los programas que se llevarán al clienteson los que se obtengan de aquí. Al crear este modelo, como con todo modelo de Prototipo o de Producción, secrearán las tablas en la base de datos asociada. Para ello ocurre exactamente lo mismo que vimos para Prototipo:GeneXus genera un programa de creación de tablas en el lenguaje de programación asociado al modelo, (cuyonombre depende del generador: por ejemplo, para visual basic, es RMenu , para .Net es Reor), éste programa secompila, creándose un ejecutable que luego es corrido y obteniendo la creación de las tablas.

Ejemplo: Creamos el modelo de Producción: “Sistema Facturación y Compras”, y elegimos la misma plataforma(recordar que esto no tiene por qué ser así: la plataforma de prototipo y producción pueden diferir). GeneXus creael programa Reor en .Net. Luego, si el usuario da el ok a la reorganización, este archivo Reor se compila, y elarchivo resultante Reor.exe se coloca bajo el folder bin del modelo (DATA002) y a continuación se ejecuta. Esteprograma contendrá la lógica correspondiente a la creación de las tablas INVOICE, CUSTOMER, PRODUCT yCOUNTRY, con sus respectivas restricciones referenciales e índices.

2. Como sucede en el pasaje de Diseño a cualquier modelo de Prototipo, al pasar a este modelo de Producción,todos los objetos GeneXus son copiados del modelo de Diseño al nuevo modelo. Aquí se especifican y generan,obteniéndose por tanto los programas ejecutables bajo el directorio del modelo. Con esto tenemos todo lonecesario para llevar la aplicación pronta al cliente.

Ejemplo: Especificamos y generamos las transacciones “Invoice”, “Customer”, “Product” y “Country” y todos los

demás objetos que hayamos creado (reportes, procedimientos, work panels, etc.).

3. Debemos llevar la aplicación a lo del cliente. De modo que debemos llevar el programa que crea la base de datos(Rmenu.exe o Reor.exe) y ejecutarlo en la máquina del cliente, obteniendo como resultado la creación de la basede datos. También debemos llevar los programas de la aplicación. Dependiendo de la plataforma, será necesarioregistrar dlls en la máquina destino. Para algunas plataformas que requieren modificar el registry de Windows, oque requieren seguir algunos pasos un poco más complejos de configuración, GeneXus brinda utilitarios de maneratal de poder obtener un setup de la aplicación para ser ejecutado en el cliente y despreocuparse de hacer talesregistraciones en forma manual. Para plataformas visuales, tales como Visual Basic y Visual FoxPro GeneXuscuenta con el Setup Wizard. Este utilitario es un wizard que va pidiendo, al pasar por sus distintas pantallas, lainformación necesaria –cuál es el modelo de Producción, etc.- para poder armar el setup que incluya las dlls parahacer tanto las registraciones necesarias en el cliente, como incluya la aplicación completa para que quedeinstalada y pronta para trabajar. El análogo del Setup Wizard para plataforma Java es el Deployment Wizard.



La plataforma .Net por el momento no cuenta con un utilitario como estos, debido fundamentalmente a que las dllsnecesarias no tienen que ser registradas, dado que corren bajo el Framework de .Net, por lo que simplementedeben copiarse los archivos del folder /bin que están bajo el modelo de Producción correspondiente, al cliente yejecutar luego el Reor.exe para crear la base de datos.

Llegado este punto, tenemos nuestro modelo de Producción como un espejo de lo que tiene el clienteinstalado.

4. Luego de la puesta en producción, surgirán cambios a realizar en la aplicación (el usuario nos pedirá cambios,nos brindará nuevo conocimiento, etc.), que nos llevarán nuevamente a la fase de diseño, volviendo a iterar en elciclo Diseño-Prototipo, hasta que los cambios implementados hayan sido suficientemente testeados y aprobados.

En este punto, volveremos a pasar a Producción, lo que conducirá, otra vez, a que GeneXus realice un análisis deimpacto, comparando la base de datos de Producción, con el diseño de la misma correspondiente al modelo deDiseño. Si encuentra cambios, entonces generará nuevamente el programa de reorganización (Reor.exe oRMenu.exe) de la base de datos, cuya lógica implementará la modificación de la base de datos actual deProducción, para llevarla al nuevo diseño. Este programa deberá ser llevado y ejecutado en el cliente paratransformar la base de datos que tenía (era un espejo de la de Producción) a la nueva. También deberemosespecificar y generar en el modelo de Producción los programas que hayan cambiado y llevarlos al cliente (seutilizará el utilitario que corresponda: Setup Wizard, Deployment Wizard o se l levará el directorio /bin parainstalar la 2da versión de la aplicación al cliente).

Terminado este punto, volveremos a tener un espejo en el modelo de Producción de lo que hay en el

cliente. Tendremos que dejar congelado el modelo de Producción y volver a iterar en el ciclo Diseño-Prototipo. Esto es fundamental porque la versión de Producción es la versión fiel de lo que tiene elcliente.

Nota: En el caso de hacerse dos pasajes de Diseño a Producción consecutivos sin haber ido a lo del cliente, esimprescindible guardar cada uno de los programas de reorganización ejecutados en orden. ¿Por qué? Porque sihacemos dos o más pasajes de Diseño a Producción sin guardar cada uno de los programas de reorganización quese ejecutaron (Reor.exe o RMenu.exe), no tendremos cada adaptación hecha la base de datos en formaconsecutiva y ¡no podremos reorganizar la base de datos del cliente!

De acuerdo a la plataforma del cliente de su aplicación, diríjase al manual de GeneXus para dicha plataforma, a laGXDL, o a las Release Notes –en la “sección específica para la plataforma xxx”- para estudiar los detallesparticulares de la puesta en producción de una aplicación en esa plataforma.



INTRODUCCIÓN A LAMETODOLOGÍA GENEXUS

Presentaremos una introducción a la Metodología GeneXus.

De estar interesado en profundizar más en este tema, el alumno podrá inscribirse al cursoGestión de Proyectos GeneXus si así lo desea, y/o recurrir a la documentación existente.



Filosofía de GeneXus

Integrar los sistemas en un gransistema corporativo

Sistema de Compras

Sistema de Ventas

Sistema de Sueldos

La filosofía de GeneXus tiende a la integración de los sistemas en un gran sistema corporativo.

Es decir, el objetivo es implementar para una empresa dada, un gran sistema integrado conbase de datos corporativa, de la cual se pueda obtener información de gestión y gerencial parala toma de decisiones.



Con herramientas tradicionales...

• Suele resultar muy complejo lograr el desarrollode sistemas corporativos...

• Generalmente se desarrollan solucionesindependientes para cada área operativa de laempresa:

Sistema deVentas

Sistema deSueldos

Sistema deCompras

PROBLEMA: no se cuenta en la

empresa con informacióncorporativa, resultando serinformación no confiable

Implementar un sistema corporativo suele resultar una tarea muy compleja cuando se utilizanherramientas tradicionales, por lo que generalmente no se lleva a cabo.

Esto trae como resultado que se tengan aplicaciones independientes, cada una resolviendo unproblema operativo particular, sin la posibilidad de obtener información corporativa.

Así encontramos por ejemplo en una empresa comercial: una aplicación de Ventas, otra deCompras, otra Contable, etc.

En consecuencia no se cuenta en la empresa con información corporativa, resultando por lo tantoser información no confiable (por la aparición de información redundante).



APLI CACIONES PARA EL AREA OPERATIVA

APLI CACIONES PARAEL ÁREA DE GESTION

INFORMACIONGERENCIAL

La integración de las Aplicaciones operativas de la

Organización es la base para poder construir los sistemas parael área de Gestión y Gerencial:

Sistemas Corporativos



¿Cómo lograr Sistemas Corporativos?

1. Dividir el problema (modularizar)

2. Crear varios frentes de desarrollo

3. Asegurar la integrabilidad

4. Obtener una sola Base de Datos Corporativa



1. Dividir el problema (Modularizar)

¿Por qué modularizar?

Para:

• Dividir el problema en partes más pequeñas• Habilitar frentes de desarrollo en paralelo• Reducir los tiempos de desarrollo• Incrementar la calidad de cada solución

Como resultado de la modularización, se obtiene un conjunto demódulos a ser desarrollados

La razón principal para modularizar es entonces, dividir el problema en partes más pequeñas yhabilitar varios frentes de desarrollo con el fin de hacer más eficiente la labor.

Realizar esta división (modularización) puede que no sea una tarea sencilla y dependerá de lascaracterísticas de cada aplicación, sin embargo debemos hacerlo cuando el problema adquiere undeterminado tamaño tal que deba ser desarrollado por más de una persona.

No existen procedimientos exactos para esta tarea, pero cuando la realicemos no debemos olvidarque el principal objetivo es obtener ambientes de desarrollo lo más independientes posibles,reconociendo que seguramente los módulos no serán disjuntos y compartirán ciertoconocimiento. Debemos sin embargo, intentar que el conjunto de los objetos que compartan sealo más pequeño posible para poderlo administrarlo mejor, y realizar posteriormente una más fácilintegración en un único modelo corporativo.



2. Crear varios frentes de desarrollo

Luego de asignado cada módulo a cada persona o equipo dedesarrollo, surge la pregunta ¿es conveniente realizar el desarrolloen una sola KB o en KB’s independientes ?

KB Compras

KB Ventas

KB SueldosKB Corporativa

• Desarrollo: KBs independientes

• Producción: Todas las KBs sonconsolidadas en KB Corporativa

El desarrollo de un módulo tiene asociados ciclos de prototipación y puesta en producciónpropios. Estos ciclos tienen asociados reorganizaciones de la Base de Datos (considerar quelas reorganizaciones son tareas monousuario), así como especificaciones y generaciones deobjetos.

No es recomendable que los ciclos de un módulo en particular, afecten el desarrollo de losdemás módulos que estén siendo desarrollados en forma simultánea, como ocurre en el

caso que compartan la Base de Datos. Por esta razón, es conveniente que los módulos seimplementen en Bases de Conocimiento independientes, para posteriormente integrarlos(consolidarlos) todos, en otra Base de Conocimiento.



3. Desarrollar asegurando la

Integrabilidad de las KBs

• Las KBs no son disjuntas, sino que comparten ciertoconocimiento.

• La siguiente pregunta que surge es ¿Cómo administrarel conocimiento en común, para que al momento deconsolidar todas las KBs el impacto sea mínimo?

• Plantearemos el tema suponiendo por un momento, que enuna empresa se realiza la división del sistema a desarrollaren 2 módulos y 2 equipos comienzan con el desarrollo deKBs diferentes sin coordinar nada de antemano...



KB 1 COMPRAS

Objetos:

Proveedores ClientesFacturasCompra FacturasVtaProductos - - - - - - - - - - - - - - - - - - - -ProductosB a n c o s - - - - - - - - - - - - - - - - - - - - - - B a n c o sAgencias - - - - - - - - - - - - - - - - - - - - -AgenciasCompras VentasOrdenesCompra NotasCredito

DATOS PROGRAMAS DATOS PROGRAMAS

KB 2 VENTAS

Objetos:

Ejemplo

En el ejemplo tenemos dos módulos correspondientes a un sistema: el módulo de compras y elmódulo de ventas.

Serán desarrollados en forma independiente por dos equipos de desarrollo distintos, queprobarán sus prototipos con sus propios datos, hasta que esté todo listo para ponerlo enproducción.

Ahora bien, observemos que estos dos módulos no son disjuntos, sino que comparteninformación común; entre otras cosas, ambos trabajan con productos, con bancos y conagencias.

Observemos que pasará a la hora de integrar ambos módulos en la KB Corporativa (a la cualsolemos llamarla también KB “Consolidado”).

Supongamos que primeramente consolidamos el módulo de Compras…



COMPRAS

COMPRAS

KB “CONSOLIDADO”

PROGRAMASBasede Datos

EjemploConsolidación de KB1 (COMPRAS)

Ha quedado en la KB “Consolidado” el conocimiento que aportó el módulo de Compras.



Análisis deImpacto

VENTAS

VENTAS

EjemploConsolidación de KB2 (VENTAS)

COMPRAS

COMPRAS

KB “CONSOLIDADO”

PROGRAMASBasede Datos

Proceso deconsolidación

Ahora hemos consolidado en la KB “Consolidado” el módulo de Ventas.

Como los módulos no son disjuntos, surgirán alteraciones a lo consolidado anteriormente, y loscambios a ser efectuados se mostrarán en el reporte de análisis de impacto.

Con este ejemplo pretendemos despertar la atención sobre los problemas inherentes a la

integración de KBs, sin haber coordinado previamente el factor Integrabilidad .



• Objetos diferentes se llaman igual• Objetos iguales se llaman diferente• Atributos diferentes tienen el mismo nombre• Atributos iguales tienen diferente nombre

KB2 VENTAS

Objeto: Invoi ceDescripción: Customer Invoice

CustomerInvoiceId*CustomerIdCustomerNameInvoiceDate

(ProductNum*.......)

EjemploProblemas que surgen en la consolidación del conocimiento

KB1 COMPRAS

Objeto: Invoi ceDescripción: Supplier Invoice

SupplierInvoiceId*SupplierId*SupplierNameInvoiceDate

(ProductId*......)

¿Qué problemas encontramos en el ejemplo que venimos viendo?

1. Objetos diferentes que se llaman igual

Las Transacciones Supplier Invoice y Customer Invoice se llaman igual: Invoice

Al integrar ambos modelos solo quedará la última consolidada.

2. Atributos diferentes tienen el mismo nombre

En este caso tenemos dos atributos que son conceptualmente diferentes y tienen el mismo nombre:I n v o i c e D a t e

Al momento de efectuar la segunda consolidación, GeneXus asumirá que se refieren al mismoconcepto y tratará de normalizar encontrando un problema: "Existe un atributo secundario en dostablas", por lo que informará el error y la Base de Datos no podrá ser creada ni reorganizada.

3. Atributos iguales tienen diferente nombre

También encontramos el caso de que el atributo que identifica al Producto, debería llamarse igualen ambos objetos por tratarse del mismo concepto, pero fue llamado diferente : P r o d u c t I d yP r o d u c t N u m .

Así GeneXus no puede reconocer que se está haciendo referencia al mismo elemento y no estableceninguna relación para el concepto de Producto.



• Visiones diferentes de las relaciones

Por ejemplo:

BankId*BankName

AgencyId*AgencyName

BankIdBankName

BankId*BankName

(AgencyId*AgencyName)

Transacción “Bank”

Transacción “Bancos”

Transacción “Agency”

KB 1 KB 2

EjemploProblemas que surgen en la consolidación del conocimiento

Otro problema que puede ocurrir es que los desarrolladores definan visiones diferentes de larelación entre los objetos.

Supongamos que tenemos 2 equipos desarrollando aplicaciones en un ambiente bancario.

Ambas aplicaciones, hacen referencia a las entidades Banco y Agencia.

Los 2 equipos de desarrollo tienen clara que la relación que existe entre Bancos y Agencias esuna relación de 1 a N : BANCO ---->> AGENCIAS

Sin embargo definen visiones diferentes, como se muestra arriba en la KB1 y KB2.

En la KB1 el atributo AgencyId identifica unívocamente una agencia. Y en la KB2 la agenciaqueda identificada por la dupla BankId, AgencyId.

En este caso, no tenemos problema de nomenclatura, pero al integrar, solo quedará definida laprimer relación , o sea:

AgencyId*BankId

y no:

BankId*AgencyId*

Dado que los identificadores en las transacciones juegan un papel fundamental, esto puededejar inválidos objetos definidos en la segunda aplicación.

Concluimos entonces, que las relaciones entre atributos y los identificadores de las diferentesentidades, juegan también un papel fundamental en el momento de integrar diferentesaplicaciones.



¿Cómo trabajar para minimizar

los problemas de integración?

• Definir y seguir un padrón de nomenclatura• para los objetos• para los atributos (Nomenclatura GIK)

• Diseñar y seguir una Metodología para administrarel conocimiento común• a continuación...

Como hemos visto, los problemas de integración se reducen a problemas de nomenclatura y de definiciónde relaciones e identificadores. Veremos posibles soluciones para minimizar estos problemas:

1. Definir y seguir un padrón de nomencl atura

Como sabemos GeneXus establece la relación entre los objetos y define la normalización de la Base deDatos, basándose en los nombres de los atributos.

Es por eso que al momento de consolidar, la nomenclatura utilizada para los atributos juega un papelprimordial.

Sin embargo, no son menos importantes los nombres de los objetos (transacciones, procedimientos, etc.)pues el Knowledge Manager reemplaza en la consolidación, los objetos con igual nombre.

Los nombres dados a las Tablas, Índices y Data Views serán también controlados en el momento de laconsolidación y deberán ser únicos en el Modelo consolidado, por lo que debemos intentar reducirconflictos también en este sentido.

En cuanto a los nombres de las variables, a pesar de que no son relevantes para la consolidación, ya queson definiciones locales, igual se sugiere tener una nomenclatura para las mismas con el fin de teneruniformidad en el desarrollo y mejorar así la comprensión de las aplicaciones.

2. Diseñar y seguir una Metodologí a para administrar el conocimiento común

Una vez definidos los módulos y establecida la padronización para los objetos del sistema, es el momentode diseñar una metodología para administrar el conocimiento de forma tal de mantener ambientesindependientes de desarrollo y asegurar su integración en un Modelo Corporativo que tenga asociada unasola Base de Datos corporativa.

Hemos solucionado parcialmente los problemas de integración definiendo una nomenclatura standardpara objetos, pero queda aún potenciarla y asegurar la integración desde el punto de vista de

“relaciones”, es decir asegurar que los objetos compartidos por más de un módulo guarden la mismarelación con el resto de los objetos. Para ello, expondremos a continuación un esquema basado en trestipos de Modelos, que cumplen funciones diferentes en la tarea de administrar el conocimiento.



Metodología basada en 3 tiposde Bases de Conocimiento

• Base de Conocimiento NÚCLEO: Contiene los objetoscorporativos, compartidos por las diferentes aplicaciones.

• Base de Conocimiento asociada a una APLICACIÓN:Contiene el conocimiento de uno de los Módulos, resultadode la modularización.

• Base de Conocimiento CORPORATIVA: Contiene laconsolidación de todas las bases de conocimiento

asociadas a las aplicaciones y el Núcleo.



KBNUCLEO

KBNUCLEO

KBCOMPRAS

KBCOMPRAS KB

VENTAS

KBVENTAS

KBSUELDOS

KBSUELDOS

KB CORPORATIVA

PROGRAMASBASE DEDATOS




KB Núcleo

• ¿Será posible identificar los elementos comunes a variosmódulos antes de su desarrollo, e incluir éstos en una KBNúcleo?

• Sí. En poco tiempo es posible definir un conjunto detransacciones que definan cuales son las entidades y/uobjetos básicos de la organización que a priori sabemos vana ser compartidos por los módulos.




Objetivo KB Núcleo

• Administrar en forma centralizada el conocimientocompartido para tener un marco de referencia único. LaBase de Conocimiento Núcleo es el ambiente que habilita laadministración de este conocimiento.

• Darle nombre a lo que conocemos es de esencia corporativa,evitando así múltiples nominaciones para un mismo objeto ypara sus atributos.




KBNUCLEO

KBCOMPRAS

KBVENTAS

KBSUELDOS

KBCORPORATIVA


KB Núcleo = Intersección de KBs Aplicaciones




KBNUCLEO

KBNUCLEO

KBCOMPRAS

KBCOMPRAS KB

VENTAS

KBVENTAS

KBSUELDOS

KBSUELDOS

KB CORPORATIVA

PROGRAMASBASE DEDATOS

FOLDERNUCLEO

FOLDERNUCLEO

FOLDERCOMPRAS

FOLDERNUCLEO

FOLDERVENTAS

FOLDERNUCLEO

FOLDERSUELDOS

FOLDERNUCLEO

FOLDERCOMPRAS

FOLDERVENTAS

FOLDERSUELDOS

En cada KB (Núcleo y Módulos) se deberá crear un folder, y los objetos propios de dicha KB, deberánubicarse dentro de ese folder.

Es decir, en la KB Núcleo habrá que crear un folder llamado Núcleo, en la KB Compras será necesariocrear un folder llamado Compras, en la KB Ventas un folder llamado Ventas, y en la KB Sueldos un folderllamado Sueldos.

La primer KB a ser definida será la KB Núcleo. Para ello habrá que identificar los objetos comunes a todoslos módulos (por ejemplo, las transacciones Banks, Agencies, Products, Customers) y definirlos dentro delfolder Núcleo de la KB Núcleo.

Una vez definido el Núcleo, este deberá distribuirse y consolidarse en cada una de las KBs asociadas a cadaaplicación, para asegurarse el compartir todas los mismos objetos comunes, exactamente.

De modo que lo que se distribuirá será el folder Núcleo de la KB Núcleo, y se consolidará en cada una delas KBs asociadas a una aplicación (KB Compras, KB Ventas y KB Sueldos) así como en la KBCorporativa.

Recién luego de esto, cada desarrollador responsable de un módulo podrá comenzar a trabajar, debiendocrear todos los objetos propios de su módulo, en el folder correspondiente a ese módulo en particular. Así,la KB Compras tendrá 2 folders: el folder Nucleo con los objetos comunes a todos los módulos, y elfolder Compras con los objetos propios que implementen ese módulo. Análogamente, las KBs Ventas ySueldos tendrán el folder Nucleo y su folder propio.

Cada KB asociada a una aplicación tendrá un ambiente de Prototipación, y un ambiente de Test en laplataforma de Producción. Estos modelos permitirán tener un diseño completo de la aplicación, minimizandolos tiempos de desarrollo pues:

1. Se estará trabajando con KBs pequeñas, asegurando la integrabilidad con el resto de las aplicaciones2. Se estarán realizando los primeros niveles de test de funcionalidad para el módulo en formaindependiente asegurando un ciclo de prototipación dinámico3. No se afectará al resto del desarrollo

En la medida que cada desarrollador de por finalizado su módulo, distribuirá el folder propio de su KB (porejemplo el folder Sueldos de la KB Sueldos) y este se consolidará en la KB Corporativa. No distribuirá elfolder Nucleo de la KB Sueldos, ya que este folder solo se distribuye de la KB Nucleo).



Administración de las KBs correspondientes a módulos

1. Se consolida el Núcleo

2. Se crea un folder propio, es decir que identifique a la aplicación,y en el mismo se crean los objetos de la aplicación

3. Una vez finalizado el desarrollo y test del módulo, se distribuiráel folder propio para consolidarlo en la KB Corporativa.

Cambios en objetos del Núcleo se deben realizar en la KB

Núcleo y luego deben ser redistribuidos a todas las KBs. Incorporar objetos de esencia corporativa en el Núcleo


¿Cómo se procede si uno de los módulos requiere modificar un objeto del Núcleo? Es decir,supongamos que el desarrollador de un módulo se da cuenta que le resulta necesario para suaplicación, agregar un atributo en una transacción del Núcleo.

Esto tendrá un impacto en todas las KBs de aplicación, y por tanto deberá administrarse concuidado.

La forma de proceder es realizar el cambio en la KB Núcleo, y luego redistribuir el Núcleo (folderNúcleo de la KB Núcleo) a todas las KBs.



Características de la KB Corporativa

• Contiene el Núcleo y las Aplicaciones

• Ventajas:

• Integridad total de la Base de Datos• Minimiza la redundancia de Datos• Base para construir la Información Corporativa de la

Organización


apostila completa

Documents