OBJETO TRANSACCIN

El anlisis de toda aplicacin GeneXus comienza con el diseo de las transacciones. Las transacciones permiten definir los objetos de la realidad. Para identificar cules transacciones deben crearse, se recomienda prestar atencin a los sustantivos que el usuario menciona cuando describe la realidad. Adems de tener por objetivo la definicin de la realidad y la consecuente creacin de la base de datos normalizada, las transacciones, al igual que la mayora de los objetos GeneXus que estudiaremos, provocan la generacin de programas. En particular los programas correspondientes a las transacciones tienen por objeto permitir dar altas, bajas y modificaciones en forma interactiva en las tablas que tengan implicadas, controlando estos programas la integridad referencial de los datos (ya sea en ambiente Win y/o Web segn lo indique el analista GeneXus).

31

Elementos
Para una transaccin se definen:
Estructura Form GUI-Windows Form Web Reglas Eventos Subrutinas Propiedades Documentacin Ayuda

Algunos elementos de las transacciones, que iremos viendo son: Estructura: Permite definir los atributos (campos) que componen la transaccin y la relacin entre ellos. A partir de la estructura de las transacciones, GeneXus inferir el diseo de la base de datos: tablas, claves, ndices, etc. Form GUI-Windows: Cada transaccin contiene un Form (pantalla) GUI-Windows (Graphical User Interface Windows) mediante el cual se realizarn las altas, bajas y modificaciones en ambiente Windows. Form Web: Cada transaccin contiene un Form (pantalla) Web mediante el cual se realizarn las altas, 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 programacin orientada a eventos. Este tipo de programacin permite definir cdigo ocioso, que se activa en respuesta a ciertas acciones provocadas por el usuario o por el sistema. Subrutinas: Permiten definir rutinas locales a la transaccin. Propiedades: Permiten definir ciertos detalles referentes al comportamiento de la transaccin. Documentacin: Permite la inclusin de texto tcnico, para ser utilizado como documentacin del sistema. Ayuda: Permite la inclusin de texto de ayuda, para ser consultado por los usuarios en tiempo de ejecucin de la transaccin. Algunos de estos elementos tambin estn asociados a otros tipos de objetos GeneXus.

32

Estructura

Ejemplo: Se necesita registrar informacin de proveedores.

Se define transaccin Supplier, con estructura: SupplierId* SupplierName SupplierAddress SupplierPhone Identificador de proveedor Nombre de proveedor Direccin de proveedor Telfono de proveedor

La estructura de una transaccin permite definir qu atributos la integran y cmo estn relacionados. A modo de ejemplo, si en una aplicacin se necesita registrar informacin de proveedores, claramente habr que definir una transaccin, a la que podemos dar el nombre Supplier, y su estructura podra ser la siguiente: SupplierId* SupplierName SupplierAddress SupplierPhone Esta lista de nombres (uno de los cuales est sucedido del smbolo asterisco) corresponde a los atributos que interesa mantener acerca de los proveedores. Entonces, creamos una transaccin de nombre Supplier cuya estructura se compone de los atributos SupplierId, SupplierName, SupplierAddress y SupplierPhone. Esto significa que cada proveedor se identificar por un cdigo SupplierId (lo que queda determinado por el asterisco a continuacin del atributo1), tendr un nombre SupplierName, una direccin SupplierAddress y un telfono SupplierPhone. Para cada atributo definido en la estructura, deberemos indicar cosas tales como su tipo de datos, descripcin y algunos detalles ms que veremos.

-------------------------------------------------------------------------------------------------------------El asterisco corresponde a una notacin terica que utilizamos para indicar que el atributo es identificador. Como veremos, nuestro asterisco en GeneXus aparece representado por un cono de llave y el usuario podr configurarlo mediante un men contextual que le ofrecer esta posibilidad.
1

33

Estructura
Vista de la estructura en GeneXus:

Atributos Clave En la pgina anterior hemos explicado que el asterisco a continuacin del atributo SupplierId indica que se trata del identificador de la transaccin. Toda transaccin debe tener un identificador, esto es, un atributo o conjunto de atributos que definan la unicidad. En el ejemplo no podrn existir dos proveedores con el mismo valor de SupplierId. En definitiva se trata del concepto de clave primaria, en tanto, para hacer la eleccin de los atributos que la componen, se deben tener en 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 que nosotros utilizamos como notacin terica.

Atributo descriptor El cono con una lupa representa al atributo que mejor describe o representa a la transaccin. En otras palabras sera el atributo que tiene mayor carga semntica en la transaccin. Por defecto el primer atributo en la estructura de la transaccin que sea de tipo de datos character, se definir como atributo descriptor. Es posible definir a otro atributo como descriptor utilizando el men popup correspondiente, as como no definir ninguno.

34

Estructura
Ejemplo: Se necesita registrar informacin referente a facturas de venta. Se define transaccin Invoice, con estructura:
InvoiceId* Identificador de factura CustomerId Identificador de cliente CustomerName Nombre de cliente InvoiceDate Fecha de factura InvoiceTotal Importe total de factura ( ProductId* Identificador de producto ProductDescription Descripcin de producto ProductPrice Precio de producto InvoiceLineQuantity Cantidad de producto llevada en la lnea InvoiceLineAmount ) Importe de lnea de factura

Niveles de una transaccin La transaccin Invoice consta de dos niveles: el primer nivel queda implcito por lo que no necesita un juego de parntesis; el segundo nivel corresponde al conjunto de atributos que se encuentra entre parntesis1. El hecho de definir un segundo nivel significa que existen varias instancias del mismo, para cada instancia del nivel anterior. En el ejemplo, un cabezal de factura tiene varios productos. Cada nivel de una transaccin define un grupo de atributos que deben operar en conjunto, es decir, se ingresan, se eliminan o se modifican conjuntamente en la base de datos. Llamaremos transaccin plana a una transaccin de un solo nivel. As, la transaccin Supplier es una transaccin plana. En cambio, la transaccin Invoice tiene dos niveles. Es comn hablar de cabezal para referirnos al primer nivel y de lneas para referirnos al segundo. Para cada nivel de la transaccin, se debe indicar cules de sus atributos actan como identificador. El identificador de cada nivel puede estar compuesto de un solo atributo, como es el caso de las transacciones que hemos visto hasta ahora, o puede estar conformado por varios atributos. En la transaccin Invoice el atributo InvoiceId es el identificador del primer nivel, y el atributo ProductId es el identificador del segundo nivel. Esto ltimo significa que para un nmero de factura dado, InvoiceId, no puede repetirse el valor del atributo ProductId en distintas lneas. Una transaccin puede contener varios niveles paralelos, as como anidados.

-------------------------------------------------------------------------------------------------------------1 Al igual que el asterisco es una notacin terica que representa que el atributo que lo antecede es identificador en la transaccin, el juego de parntesis tambin es utilizado como notacin terica, para representar que los atributos contenidos forman parte de un nivel anidado, y que tiene una representacin visual en GeneXus distinta, pero que indica lo mismo.

35

Estructura
Vista de la estructura en GeneXus

En GeneXus queda visualmente claro el nivel correspondiente a las lneas de la factura. A cada nivel de una transaccin se le debe asignar un nombre, tipo1 y descripcin (salvo al primer nivel, que recibe como nombre el de la transaccin). Niveles paralelos y anidados Una transaccin puede tener varios niveles de anidacin, as como niveles paralelos. Por ejemplo, en el hipottico caso de que una factura pueda abonarse en varios pagos, podramos definir dos tipos de estructura, dependiendo de lo que se quiera representar: InvoiceId* CustomerId CustomerName InvoiceDate InvoiceTotal (ProductId* ProductDescription ProductPrice InvoiceLineQuantity InvoiceLineAmount) (InvoicePaymentDate* InvoicePaymentAmount) InvoiceId* CustomerId CustomerName InvoiceDate InvoiceTotal (ProductId* ProductDescription ProductPrice InvoiceLineQuantity InvoiceLineAmount (InvoicePaymentDate* InvoicePaymentAmount))

Fecha de pago Importe pagado

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

-------------------------------------------------------------------------------------------------------------Como veremos luego, el tipo que se define para un nivel de una transaccin, ser utilizado para trabajar con business components, concepto relacionado a las transacciones.
1

36

Definicin del modelo de datos a partir de las estructuras de las transacciones

Transaccin Supplier
SupplierId* SupplierName SupplierAddress SupplierPhone

Transaccin Invoice
InvoiceId* CustomerId CustomerName InvoiceDate InvoiceTotal ( ProductId* ProductDescription ProductPrice InvoiceLineQuantity InvoiceLineAmount )

Tabla INVOICE
InvoiceId* CustomerId CustomerName InvoiceDate InvoiceTotal

Tabla SUPPLIER
SupplierId* SupplierName SupplierAddress SupplierPhone

Tabla INVOICELINE
InvoiceId* ProductId* ProductDescription ProductPrice InvoiceLineQuantity InvoiceLineAmount

GeneXus utiliza la estructura de las transacciones para capturar el conocimiento necesario para definir automticamente cul es el modelo de datos que debe crear. Para poder realizar la normalizacin de la base de datos llevndola a 3era. forma normal, GeneXus debe extraer las dependencias funcionales existentes entre los atributos definidos en la base de conocimiento. En la base de conocimiento de nuestro ejemplo, hemos definido a la transaccin Proveedores y de su estructura GeneXus extrae las siguientes dependencias funcionales: SupplierId {SupplierName, SupplierAddress, SupplierPhone}

Dadas estas dependencias funcionales, GeneXus determina que debe crear una tabla que tendr por defecto el mismo nombre que la transaccin (SUPPLIER)1, y que estar conformada ni ms ni menos que por los cuatro atributos anteriores, siendo SupplierId la clave primaria de la misma:

SUPPLIER

SupplierId

SupplierName

SupplierAddress

SupplierPhone

Diremos que la transaccin Supplier tiene asociada la tabla SUPPLIER en el entendido de que cuando se ingresen, modifiquen o eliminen datos por medio de la transaccin, stos se estarn almacenando, modificando o eliminando fsicamente en la tabla asociada.

-----------------------------------------------------------------------------------------------------------En la documentacin, para distinguir el nombre de una tabla del nombre de una transaccin escribiremos el nombre de la tabla todo en mayscula.
1

37

A partir de la estructura de la transaccin Invoice, GeneXus determina que debe crear dos tablas: Tabla INVOICE, correspondiente al primer nivel de la transaccin:

INVOICE

InvoiceId

CustomerId

CustomerName

InvoiceDate

InvoiceTotal

Clave primaria: InvoiceId Tabla INVOICELINE correspondiente al segundo nivel de la transaccin:

INVOICELINE

InvoiceId

ProductId

ProductDescription InvoiceLineAmount

ProductPrice

InvoiceLineQuantity Clave primaria: {InvoiceId, ProductId} Clave fornea: InvoiceId ya que las dependencias funcionales son: InvoiceId

{CustomerId, CustomerName, InvoiceDate, InvoiceTotal} {ProductDescription, ProductPrice, InvoiceLineQuantity, InvoiceLineAmount}

{InvoiceId, ProductId}

Observemos que la clave primaria de la tabla INOVICELINE es la concatenacin del identificador del primer nivel, InvoiceId, con el identificador del segundo nivel, ProductId. El caso es general: la clave primaria de la tabla correspondiente a un nivel n de una transaccin se obtiene de concatenar los identificadores 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 de una transaccin le asigna el mismo nombre que el de la transaccin; y a las tablas de niveles subordinados les asigna la concatenacin de los nombres de los niveles. Por esto es que la tabla asociada al segundo nivel de la transaccin Invoice recibe el nombre INVOICELINE, dado que el nombre del primer nivel es el de la transaccin, INVOICE, y el del segundo nivel es LINE. Los nombres de las tablas pueden ser modificados por el analista GeneXus cuando as lo desee.

38

Al definir las nuevas transacciones:

Transaccin Customer
CustomerId* CustomerName CustomerAddress CustomerGender

Sexo del cliente

Transaccin Product
ProductId* ProductDescription ProductPrice ProductStock

Luego de haber modelado la transaccin Invoice, nos damos cuenta que hay informacin de clientes y de productos que nos interesa mantener independientemente de las facturas. Es decir, los clientes y los productos son dos objetos de la realidad independientes de las facturas, por lo tanto creamos las dos nuevas transacciones Customer y Product detalladas arriba. Dependencias funcionales Con estas nuevas transacciones definidas, aparecen nuevas dependencias funcionales: CustomerId ProductId {CustomerName, CustomerAddress, CustomerGender} {ProductDescription, ProductPrice, ProductStock}

que conducen directamente a la creacin de dos nuevas tablas:

CUSTOMER

CustomerId

CustomerName

CustomerAddress

CustomerGender

Clave primaria: CustomerId y:

PRODUCT

ProductId

ProductDescription

ProductPrice

ProductStock

Clave primaria: ProductId

39

Normalizacin: cambios en las tablas

Tabla INVOICE
InvoiceId* CustomerId CustomerName InvoiceDate InvoiceTotal

Tabla CUSTOMER
CustomerId* CustomerName CustomerAddress CustomerGender

Tabla SUPPLIER
SupplierId* SupplierName SupplierAddress SupplierPhone

Tabla INVOICELINE
InvoiceId* ProductId* ProductDescription ProductPrice InvoiceLineQuantity InvoiceLineAmount

Tabla PRODUCT
ProductId* ProductDescription ProductPrice ProductStock

El conjunto total de dependencias funcionales existentes requiere que deban realizarse algunas modificaciones en las tablas INVOICE e INVOICELINE diseadas previamente para que el diseo de la base de datos permanezca en 3era. forma normal1. Si representamos sobre las tablas CUSTOMER e INVOICE las dependencias funcionales encontradas para sus atributos:

podemos ver claramente que INVOICE viola la 3era. forma normal (existe una dependencia funcional transitiva): InvoiceId CustomerId InvoiceId CustomerId CustomerName CustomerName

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

Ahora CustomerName solo estar en la tabla CUSTOMER. ------------------------------------------------------------------------------------------------------------------1

Por ms informacin sobre las formas normales (3era. forma normal, etc.) le recomendamos la lectura del documento Fundamentos de bases de datos relacionales, el cual est incluido en el captulo de Anexos del curso GeneXus no presencial. De lo contrario, puede pedrselo al docente.

40

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 que estn dependiendo en forma parcial de la clave primaria): ProductId ProductDescription ProductDescription ProductId ProductPrice ProductPrice

{InvoiceId, ProductId}

{InvoiceId, ProductId}

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

ProductDescription y ProductPrice solo quedarn en la tabla PRODUCT.

41

GeneXus establece las relaciones por los nombres de atributos

CONCEPTOS IGUALES DEBEN TENER EL MISMO NOMBRE
Transaccin Invoice InvoiceId* CustomerId CustomerName Transaccin Invoice InvoiceId* InvoiceCustomerId Transaccin Customer CustomerId* CustomerName Transaccin Customer CustomerId*

SI NO

CONCEPTOS DIFERENTES NO DEBEN TENER EL MISMO NOMBRE

Transaccin Invoice InvoiceId* Date CustomerId CustomerName Transaccin VendorInvoice VendorInvoiceId* Date SupplierId SupplierName

NO

Conceptos iguales deben tener el mismo nombre y conceptos diferentes deben ser nombrados diferentes. GeneXus establece las relaciones a travs de los nombres de los atributos, de modo que cuando encuentra atributos de igual nombre en distintas transacciones, entiende que se trata del mismo concepto, 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 transaccin Customer como en la transaccin Invoice, analiza que: el atributo se llama igual en ambas transacciones, as que se refiere al mismo concepto. En la transaccin Customer, CustomerId est marcado como identificador, lo que significa que ser clave primaria en la tabla fsica CUSTOMER; entonces en la tabla fsica INVOICE ser clave fornea. El atributo CustomerName, por su parte, tambin se encuentra tanto en la transaccin Customer como en la transaccin Invoice, pero a diferencia de CustomerId, no est marcado como identificador en ninguna transaccin del modelo; por tanto GeneXus entiende que se trata de un atributo secundario. Las dependencias funcionales indican que a CustomerName lo determina CustomerId: InvoiceId CustomerId CustomerId CustomerName as que GeneXus incluir CustomerName en la tabla fsica CUSTOMER (y no en la tabla fsica INVOICE). Atributos primarios y secundarios Un atributo se califica como primario cuando el mismo es identificador en alguna transaccin del modelo. En el ejemplo que venimos viendo, CustomerId es un atributo primario ya que es identificador en la transaccin Customer. CustomerName, en cambio, es un atributo secundario ya que no es identificador en ninguna transaccin del modelo.

42

Atributos almacenados e inferidos Al definir las transacciones Customer y Product, hemos incluido en ellas ciertos atributos que no hemos eliminado de la transaccin 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 atributos primarios. El atributo CustomerName, por su parte, se agreg en la transaccin Customer; y los atributos ProductDescription y ProductPrice se incluyeron en la transaccin Product. Estos son atributos secundarios. Todos estos atributos han quedado en ms de una transaccin: se han dejado en la transaccin Invoice tal como se haban definido en un principio, y se han incluido en las transacciones Customer y Product respectivamente, porque nos hemos percatado de la necesidad de crear estos objetos. A continuacin presentamos las 3 estructuras de las transacciones en cuestin, para poder visualizarlas juntas:

Probablemente usted no comprenda la razn por la cual los atributos secundarios CustomerName, ProductDescription y ProductPrice se han dejado en la estructura de la transaccin Invoice. La explicacin es la siguiente: las estructuras de las transacciones no son equivalentes a estructuras de tablas fsicas. En las estructuras de las transacciones se pueden incluir ciertos atributos que no estarn en la o las tablas fsicas asociadas, ya que a la hora de reorganizar la base de datos GeneXus analizar el conjunto total de dependencias funcionales existentes en la base de conocimiento, y crear -o modificar, segn el caso- las tablas fsicas, dejndolas en 3 forma normal. Ahora, con qu finalidad hemos dejado los atributos secundarios CustomerName, ProductDescription y ProductPrice en la estructura de la transaccin Invoice? Los hemos dejado para poder incluirlos en alguno de los forms (GUI-Windows y/o Web) asociados a la transaccin Invoice y as poder visualizar los valores de dichos atributos en tiempo de ejecucin. Dichos atributos, como hemos explicado, no quedarn almacenados ni en la tabla INVOICE, ni en la tabla INVOICELINE; sin embargo, en tiempo de ejecucin cuando el usuario ingrese a travs de alguno de los forms (GUI-Windows y/o Web) un valor de CustomerId (atributo que s se almacenar en la tabla INVOICE siendo clave fornea), a continuacin se mostrar el CustomerName correspondiente. Decimos que el atributo CustomerName es un atributo inferido en la transaccin Invoice, ya que su valor no se encuentra almacenado en ninguna de las tablas asociadas a la transaccin, sino que se infiere es decir, se obtiene- de la tabla CUSTOMER, dado el valor del atributo CustomerId. Anlogamente, los atributos ProductDescription y ProductPrice tambin son inferidos en la transaccin Invoice, ya que no se encuentran almacenados en las tablas asociadas a la misma, sino que sus valores se infieren de la tabla PRODUCT, para ser mostrados en pantalla.

43

Es conveniente usar padrones para los nombres de atributos

Facilitan la tarea de nombrado Facilitan la tarea de integracin de bases de conocimiento Facilitan la lectura del cdigo generado

44

Nombrado de atributos: Nomenclatura GIK

Componente de Entidad + Categora Categor [+ Calificador + Complemento]

y en ingls:

ARTech ha definido un estndar para la nomenclatura de atributos: el GeneXus Incremental Knowledge Base (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, sealados entre parntesis rectos): Componente de Entidad + Categora [+ Calificador + Complemento] A continuacin 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 aplicacin dada, representado por una transaccin Genexus2. Un Componente de Entidad, representa a cualquier nivel subordinado o paralelo que defina la entidad. Ejemplo: la factura tiene los siguientes componentes, Invoice (cabezal), InvoiceLine (lneas de la solicitud). Se sugiere un largo de un entorno de 10 caracteres para representar el componente de la Entidad. Categora: Es la categora semntica del atributo, es decir, define el rol que el mismo asume dentro del objeto y dentro del entorno de la aplicacin. Se sugiere que no supere los 10 caracteres. Ejemplos: Id (identificador), Code (cdigo), Name (nombre), Date (fecha), Description (descripcin), Price (precio), Stock. -------------------------------------------------------------------------------------------------------------1 Para pases que utilicen lenguas en las que los adjetivos suelan colocarse despus del sustantivo. En el ingls esto es al revs, por lo que la categora (el sustantivo) va al final. 2 O un conjunto de Transacciones paralelas y/o subordinadas, de las que hablaremos ms adelante.
1

45

Calificador: Es cualquier adjetivo o adverbio, en el entorno de 10 caracteres, que agregue diferenciacin conceptual al nombre del atributo para hacerlo nico. En general refiere al texto que califica la categora: 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 maysculas permiten establecer fronteras entre los componentes que forman a los nombres de atributos. Nota 2: Para cada componente se pueden utilizar la cantidad de caracteres que se deseen, aunque se sugiere utilizar 10 y que el nombre completo del atributo no supere los 30.

46

Demo
Creacin de base de conocimiento Creacin de transacciones

Para crear una base de conocimiento, se debe seleccionar en la barra de men de GeneXus, el tem File / New Knowledge Base. A continuacin aparecer un dilogo que solicitar la ubicacin y nombre de la base de conocimiento a crear. Una vez creada la base de conocimiento, la misma quedar abierta en el modelo de Diseo, para que 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 divisin izquierda de la pantalla, ya que los objetos que vayamos creando irn quedando dentro de dicha carpeta. La creacin de objetos, se realiza mediante el tem Object / New Object de la barra de men de GeneXus. Al seleccionar el tem Object / New Object se desplegar un dilogo en el cual se deber elegir el tipo de objeto que se desea crear (en este caso el tipo de objeto: transaccin), dar un nombre al objeto que se est creando (por ejemplo: Customer), una descripcin larga, y se podrn indicar algunas cosas ms que iremos viendo. Una vez creada la transaccin, la misma quedar abierta para que se defina su estructura.

47

Definicin de atributos

Para definir un atributo, simplemente se debe digitar en el primer campo de una lnea (o rama) de la estructura, el nombre del atributo que se desea crear. Mediante la tecla de tabulacin se puede pasar a los siguientes campos para indicar el tipo de datos del atributo, as como su descripcin, si admitir valores nulos de la base de datos, y en el caso que el mismo vaya a ser una frmula (concepto que veremos en breve), cmo calcularla. Con la tecla Enter se puede pasar a la siguiente lnea, para definir otro atributo. Una vez definidos los atributos en la estructura de la transaccin, solamente restar guardar / salvar los cambios. Si se necesita modificar el nombre de un atributo, su tipo de datos, descripcin, nulabilidad, o frmula, bastar con hacer doble clic sobre el campo implicado, y el mismo se habilitar y se podr editar. Luego se debern guardar/salvar los cambios, nuevamente. Para indicar que uno o ms atributos son identificadores en la transaccin, se los debe seleccionar y presionar CTRL + K; en consecuencia aparecern con un smbolo de llave. Para definir que comienza otro nivel en la transaccin, se debe digitar CTRL + L, y automticamente se producir una indentacin y el usuario deber darle nombre a ese nivel, as como definir el nombre de su tipo de datos1 y una descripcin para el nivel. Para indicar que un atributo de uno de los niveles de la transaccin ser el atributo descriptor, se lo debe seleccionar y presionar CTRL+D. GeneXus cuenta con mens pop up2, que son mens que se abren cuando el usuario est posicionado en determinado contexto y da clic con el botn derecho del mouse. Por ejemplo, al hacer clic con el botn 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 ejemplo indicar que el atributo es clave (opcin Toggle key), quitarlo de la estructura, pasarlo a un siguiente nivel de anidacin, etc. Cada atributo tiene propiedades. Algunas de ellas (las fundamentales y obligatorias) son las que se ofrecen directamente en la estructura para su ingreso inline. Para acceder al dilogo que permite configurar todas las propiedades de un atributo, se debe seleccionar el tem Properties del men contextual. ---------------------------------------------------------------------------------------------------Veremos su utilidad cuando estudiemos los business components. 2 Tambin llamados contextuales dado que varan segn el contexto.
1

48

La posibilidad de modificar las propiedades de un atributo solo estar disponible en el modelo de Diseo, ya que es en este modelo de la base de conocimiento en el que se disean y editan las transacciones y atributos. El dilogo de configuracin de las propiedades de un atributo tiene 4 solapas: General, Control Info, Help y Documentation. 1) General: Contiene informacin general del atributo. Name: Es el nombre del atributo. Se utiliza para identificarlo. Description: La Descripcin o ms propiamente Nombre largo es una descripcin 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 conocimiento la misma descripcin, ya que ser a travs de esta descripcin que el usuario final podr seleccionar atributos para definir sus propias consultas a la base de datos, con GXquery, ejecutando reportes dinmicos (tema bastante simple, pero que no se abordar en este curso). Relacionadas a esta propiedad, estn las propiedades Title y Column Title, que por defecto toman el mismo valor que se especifica en Description, pudindose modificar. Estas propiedades se describen a continuacin: Title: La descripcin que se ingrese aqu ser colocada por defecto al lado del atributo cada vez que se utilice en salidas planas como en el primer nivel de los forms de las transacciones, o en reportes generados con el Report Wizard. El valor de esta propiedad inicialmente se hereda de la propiedad Description del atributo, pudiendo ser modificada por el programador. Column Title: La descripcin que se ingrese aqu ser colocada por defecto como ttulo del atributo cada vez que se lo incluya en la columna de un grid (grilla). El valor de esta propiedad inicialmente se hereda de la propiedad Description del atributo, pudiendo ser modificada por el programador. Domain: Permite asociarle un dominio1 al atributo. Al hacerlo, ciertas propiedades del atributo se deshabilitarn (como Data Type y Length) tomando los valores del dominio. En caso de que el atributo no pertenezca a un dominio, el programador dejar el valor [none] en esta propiedad, y las correspondientes al tipo de datos del atributo estarn habilitadas para ser ingresadas. Data Type: Permite indicar el tipo de datos del atributo. Aqu se podr elegir uno de los tipos de datos soportados por GeneXus. 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 numrico, entonces se deber tener en cuenta que el largo incluya las posiciones decimales, el punto decimal y el signo. Esta propiedad estar deshabilitada cuando el tipo de datos elegido no requiera establecer un largo (por ejemplo, si se trata del tipo de datos Date). Decimals: Si en la propiedad Data Type se indica que el atributo es numrico, se ofrecer esta propiedad, para que se 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 numrico, 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 representarn valores negativos. Value Range: Permite indicar un rango de valores vlidos para el atributo. Por ejemplo: 1:20 30: - significa que los valores vlidos son entre 1 y 20; y 30 o mayor. 1 2 3 4 - significa que los valores vlidos son 1, 2, 3 o 4. 'S' 'N' - significa que los valores vlidos son 'S' o 'N'. Picture: Permite indicar el formato de edicin para la entrada y salida del atributo. Dependiendo del tipo de datos del atributo, aparecern determinadas propiedades bajo esta categora. GeneXus provee ms propiedades para los atributos que las recin mencionadas. Dependiendo del valor que se elija para determinada propiedad, se ofrecern ciertas propiedades relacionadas, u otras. Recomendamos para la lectura de otras propiedades, acceder al Help de GeneXus.

-------------------------------------------------------------------------------------------------------------------------------1 Los dominios se abordarn ms adelante en el curso, pero a modo de resumen, el objetivo de los dominios es realizar definiciones de datos genricas. Por ejemplo: se puede definir un dominio de nombre Precio y tipo de datos Numeric(10,2) y luego asociarle este dominio a todos los atributos que almacenan precios. Esto tiene la ventaja de que si despus se desea modificarlo a por ejemplo Numeric(12,2), hay que modificar solamente la definicin del dominio y automticamente todos los atributos basados en ese dominio heredan el cambio.

49

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 asociacin 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 a cualquiera de los otros tipos. En la solapa Control Info del dilogo de edicin 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 distinta informacin complementaria. Luego, cada vez que se agregue el atributo en un form se presentar automticamente con el tipo de control que tenga asociado aqu. Nota En caso de asociar al atributo el tipo Edit, se podr especificar que disfrace sus valores, mostrando los de otro atributo (propiedad InputType), e incluso que sugiera los valores posibles al usuario, a medida que ste vaya digitando (propiedad Suggest), entre otras, como veremos luego, cuando estudiemos Descripciones en lugar de cdigos. Tambin se puede elegir el color de la fuente de letra que se desea asociar por defecto al atributo, as como el color de fondo, de modo que cada vez que se agregue el atributo en un form, se presente automticamente con los colores que se le hayan asociado. 3) Help Esta solapa permite que el programador ingrese un texto de ayuda asociado al atributo, para que el usuario final pueda consultarlo en tiempo de ejecucin. Si el usuario final solicita ayuda (presionando F1), estando posicionado en el atributo, se le desplegar el texto que se haya ingresado aqu. Ms adelante, veremos otros temas relacionados al help de una aplicacin GeneXus. 4) Documentacin Esta solapa permite que el programador ingrese documentacin tcnica del atributo, til para los desarrolladores.

50

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 combinacin de fecha y hora.

Blob
- Permite almacenar cualquier tipo de informacin: texto, imgenes, videos, planillas, etc., en la base de datos. - Win / Web ofrecen manipulacin distinta de este tipo de datos

Numeric: Permite almacenar datos numricos. Cuando se selecciona este tipo de datos se debe indicar la cantidad total de dgitos del nmero, la cantidad de posiciones decimales, y si permite signo o no. Ejemplo: Si definimos que el tipo de datos del atributo InvoiceTotal es numrico de largo 10, con decimales 2, y sin signo, estamos especificando que representar nmeros con hasta 7 dgitos en la parte entera y 2 decimales (7 dgitos en la parte entera + punto + 2 dgitos para los decimales = 10 dgitos). Character: Permite almacenar cualquier tipo de texto (caracteres y dgitos). 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 tipo Character y si sabemos que nunca un nombre tendr ms 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 este tipo de datos. El formato a utilizar para las fechas (da-mes-ao, mes-da-ao), se configura en forma genrica para todo el modelo dentro de un tipo especial de objeto, el objeto Language correspondiente al lenguaje en el que se generar el modelo. El objeto language existe para poder tener una misma aplicacin traducida en cualquier lenguaje. La eleccin de presentar el ao con 2 dgitos o 4, se configura con la propiedad Picture de cada atributo.

51

 VarChar: Permite almacenar texto de largo variable. Su funcin, en contraposicin al Character, es optimizar el almacenamiento en la base de datos. Cuando se selecciona el tipo de datos VarChar en el dilogo de definicin del atributo se agregan las 2 siguientes propiedades: Maximum Length y Average Length. La primera es para indicar el largo mximo de caracteres que se podrn almacenar, mientras que la segunda es para 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 25 caracteres, 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 que 25, se almacenan los primeros 25 caracteres en el campo, y el resto en un rea de overflow. Como contrapartida a la ventaja de la optimizacin del almacenamiento, para los casos en que se utilice el rea de overflow, 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 se almacena en la base de datos. Se le pueden aplicar todas las funciones y operadores existentes para el tipo de datos 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 textos largos, comentarios, etc. Al seleccionar este tipo de datos, se debe indicar un largo mximo. Existen dos funciones para manipular este tipo de datos: GXMLines y GXGetMLi. GXMLines retorna la cantidad de lneas que tiene un atributo Long Varchar, teniendo como parmetros el nombre del atributo, y la cantidad de caracteres que se desea considerar por lnea. Ejemplo: &cantlin = GXMLines( AtribMemo, 40 ). GXGetMLi por su parte, extrae una lnea del atributo Long Varchar (para luego imprimirla, por ejemplo); teniendo como parmetros el nombre del atributo, el nmero de lnea deseado, y la cantidad de caracteres que se desea considerar por lnea. Ejemplo: &txt = GXGetMLi( AtribMemo, 1, 40 ). Generalmente se usan estas 2 funciones en combinacin, ya que primero se suele consultar la cantidad de lneas que tiene cierto atributo Long Varchar, indicando la cantidad deseada de caracteres por lnea, y luego se prosigue extrayendo el contenido de las lneas, utilizando un bucle hasta llegar a la ltima lnea, y de esta forma se imprimen, por ejemplo. DateTime: Permite almacenar una combinacin 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 ao con 2 dgitos, o manejarla y presentar el ao con 4 dgitos. Acerca de la hora se puede elegir: manejar solo 2 dgitos para la hora (no manejando minutos ni segundos), manejar 2 dgitos para la hora y 2 dgitos para los minutos (no manejando segundos), o manejar 2 dgitos para la hora, 2 dgitos para los minutos y 2 dgitos para los segundos. Los valores anteriores no afectan la forma de almacenar el tipo de datos sino especficamente la forma de aceptar 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 el mnimo soportado por el DBMS, y ser reconocido por GeneXus como fecha vaca o nula. En lo que respecta a la hora, los valores no aceptados (minutos y/o segundos) sern almacenados con valor cero. Blob: Ante el creciente manejo de imgenes digitalizadas, videos, planillas as como documentos de todo tipo, las aplicaciones requieren cada vez ms mantener y trabajar con este tipo de informacin. El tipo de datos Blob permite almacenar esta diversidad de informacin en la propia base de datos, aprovechando as 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 aplicacin en ambiente Win o Web, ser la forma de manipulacin de un atributo de este tipo de datos. El ambiente Web ofrece ms funcionalidades para trabajar con atributos de tipo Blob de forma muy amigable. Para profundizar en el conocimiento de este tipo de datos puede dirigirse al Help de GeneXus.

52

Definicin de variables
En todo objeto GeneXus es posible definir variables. Las variables son nicamente visibles dentro del objeto; es decir, son locales.

Para definir variables en determinado objeto, estando dentro del mismo, se debe presionar el botn de la barra de herramientas Fast Access de GeneXus, y se abrir el dilogo de definicin de variables, mostrado en la transparencia. Este dilogo muestra variables definidas por defecto (como por ejemplo la variable Today que contiene la fecha del sistema) para el objeto, y permite definir variables nuevas mediante los botones Add y Add Based On.

Botn Add Al seleccionar el botn Add, se abre el siguiente dilogo para la definicin de una variable:

Este dilogo solicita el nombre de la variable, su descripcin, tipo de datos y largo, o dominio, de forma anloga a cuando se define un atributo. La propiedad Dimensions permite indicar si la variable ser escalar o si se tratar de un vector (1 dimensin) o matriz (2 dimensiones). El valor que ofrece por defecto esta propiedad es escalar.

53

Botn Add Based On El botn Add Based On ofrece una forma rpida de definir una variable. Cuando se selecciona, se despliega un dilogo que muestra todos los atributos definidos en la base de conocimiento; en dicho dilogo, simplemente se debe seleccionar un atributo, y a continuacin se definir automticamente una variable con el mismo nombre y la misma definicin que el atributo. Vale aclarar que se pueden seleccionar varios atributos, crendose en tal caso una variable por cada atributo seleccionado, con sus mismas caractersticas. Botones Edit, Remove, Copy, Paste El botn Edit permite editar una variable que se haya seleccionado previamente, mientras que el botn Remove, permite borrar una o ms variables que se hayan seleccionado a la vez. El botn Copy ofrece la posibilidad de copiar en el portapapeles la definicin completa de las variables que se hayan seleccionado previamente, para luego poder pegar dichas definiciones de variables en otro objeto de la base de conocimiento, con el botn Paste de este mismo dilogo; es decir, en el objeto destino, se deber entrar a este mismo dilogo, y presionar el botn Paste.

Por otra parte, es posible definir variables dentro del editor de cdigo de cada objeto (source, eventos, etc.), haciendo uso del men contextual (botn derecho) luego de escribir el nombre de la variable. Esto es, al escribir &nombreDeVariable (ej: &x) y presionar botn derecho del mouse, se abrir el siguiente men contextual:

Tambin 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 opcin Define se abrir el mismo dilogo que al presionar el botn Add. Anlogamente, al seleccionar la opcin Edit de este men, se abrir el mismo dilogo que al presionar el botn Edit del dilogo de definicin de variables mostrado en la transparencia.

54

Dominios
Objetivo: Realizar definiciones genricas. Cundo debemos usar dominios?
Atributos y/o variables con la misma definicin

Ejemplo: ProductPrice: Precio de producto InvoiceLineAmount: Importe total de lnea Dominio Price: Numeric(10.2)

Atributos

Es comn tener en una base de conocimiento atributos que comparten definiciones similares pero que no tienen relacin entre s. Por ejemplo, es comn definir todos los nombres como atributos de tipo character y largo 20; o todos los importes, como atributos de tipo numrico y largo 10.2. El objetivo de los dominios es permitir realizar definiciones genricas. A modo de ejemplo, el atributo InvoiceLineAmount es de tipo numrico y largo 10.2, y al mismo tiempo, el atributo ProductPrice es del mismo tipo y largo, en la misma base de conocimiento. De modo que podramos definir un dominio de nombre Price, que sea de tipo numrico con largo 10.2, y a cada uno de los atributos anteriores le asignaramos dicho dominio. La ventaja de hacerlo as es que si en el futuro surge la necesidad de cambiar la definicin de los atributos que representan importes, haramos el cambio una sola vez (en el dominio Price), propagndose ste automticamente a los atributos InvoiceLineAmount y ProductPrice por pertenecer a l. As como podemos asociarle a un atributo un dominio, tambin lo podemos hacer para una variable. Un mismo dominio puede asignarse tanto a atributos como a variables, ya que su objetivo es exactamente el mismo. Cmo definir un dominio? Existen varios caminos: 1) El tem: Advanced / Domain de la barra de men de GeneXus ofrece un dilogo para realizar el mantenimiento de los dominios de la base de conocimiento; esto es: crear dominios, modificarlos y eliminarlos (la eliminacin de un dominio solo se permitir si el mismo no est asignado a ningn atributo ni variable). 2) Dado que en la pantalla de configuracin de las propiedades de un atributo es donde se le asigna a un atributo un dominio existente, en dicha pantalla se ofrece un botn para crear un dominio nuevo. dem con el dilogo de definicin de variables. 3) En la estructura de la transaccin es posible definir un nuevo domino en el campo de definicin del tipo de datos de un atributo, simplemente escribiendo sobre esa misma lnea, el nombre del dominio, y asignndole el tipo de datos. Por ejemplo, digitando Price = Numeric(10.2) sobre la columna Type del atributo que se est definiendo, queda tambin definido el dominio de nombre Price, con el tipo de datos Numeric(10.2). Estos accesos para trabajar con dominios solo se encuentran habilitados en el modelo de Diseo de la base de conocimiento, al igual que todas las funcionalidades que puedan implicar modificaciones en la base de datos fsica.

55

Forms
Cada transaccin tiene asociado un form GUIWindows y un form Web.

Ambos forms son creados por defecto al grabar la estructura de la transaccin, pudiendo ser modificados por el programador.

Para cada transaccin, GeneXus crea un form GUI-windows y un form Web, los cuales sern la interfaz con el usuario, en ambiente windows y Web respectivamente. Ambos forms son creados por defecto por GeneXus al momento de grabar la estructura de la transaccin, y contienen todos los atributos incluidos en la misma, con sus respectivas descripciones, adems de algunos botones. Si bien son creados por defecto, es posible modificarlos para dejarlos ms vistosos, cambiar por ejemplo controles de tipo edit a otros tipos de controles, agregar y/o quitar botones, etc. Para editar el form GUI-windows de una transaccin, se debe seleccionar la solapa Form que se encuentra en la barra de edicin del objeto, mientras que para editar el form Web, se debe seleccionar la solapa Web Form en la misma barra.

56

Form GUI-Windows de la transaccin Invoice

GRID

A travs del form de la transaccin (GUI-Windows o Web segn el ambiente de trabajo) el usuario podr ingresar, modificar y eliminar registros en tiempo de ejecucin. En el ejemplo se muestra el form GUI-Windows correspondiente a la transaccin de facturas (Invoice).

57

Form Web de la transaccin Invoice

Control Error Viewer exclusivo de Web botn Get

GRID

En el ejemplo se muestra el form Web correspondiente a la transaccin Invoice. A travs de este form el usuario final podr ingresar, modificar y eliminar facturas en la aplicacin Web. Pueden verse algunas diferencias en el diseo grfico del form Web respecto al form Win, pero podemos ver que todos los controles que estn en el form Win, tambin lo estn en el Web. El recproco no se cumple: el botn 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 tambin solamente en el form Web. Y el grid correspondiente a las lneas 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 continuacin el control Error Viewer. Sobre el botn Get entenderemos el por qu de esta diferenciacin un poco ms adelante, cuando estudiemos el dilogo con validacin a nivel del cliente. Con respecto al check box tambin veremos este tema ms adelante, cuando estudiemos la ejecucin. En una aplicacin con interfaz Win, los mensajes que deban mostrarse al usuario en tiempo de ejecucin se desplegarn en una ventana de Windows independiente, que no programamos nosotros. En Web, en cambio, los mensajes2 deben mostrarse dentro de la pgina HTML que contiene el form de la transaccin. Es por este motivo que existe el control Error Viewer, para poder ubicar y programar el lugar donde queremos que los mensajes generales le sean desplegados al usuario final de una transaccin Web. Podremos especificar entre otras cosas el lugar donde queremos que este control se ubique dentro del form, su tipo de letra, color, etc. Existen algunas diferencias ms entre ambos forms, pero son menores dado que representan formas distintas de realizar lo mismo: por ejemplo, mientras que el botn para confirmar las acciones y comenzar la grabacin de los registros de la transaccin en el form Win tiene como texto Confirm, en el Web su texto es Apply Changes. Anlogamente, mientras el botn para eliminar todo (cabezal y lneas) 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 botn Check, que permite chequear que todo lo que ha ingresado el usuario hasta el momento sea correcto. Ms adelante, cuando estudiemos cmo se trabaja en ejecucin con las transacciones, arrojaremos ms luz sobre estos asuntos. ----------------------------------------------------------------------------------------------------------------------Ms adelante cuando estudiemos el dilogo con validacin a nivel del cliente, veremos que en ambiente Win se podr optar por trabajar con dicho dilogo o no, y dependiendo de ello, el botn Get estar presente en el form o no. 2 Cuando estudiemos el dilogo con validacin a nivel del cliente en Web, veremos que muchos de los mensajes se desplegarn en cajas de texto sobre la pantalla, especficamente sobre los campos que el usuario haya ingresado y en los que se deba informar de algo al usuario. Es decir, funcionarn de manera combinada el control Error Viewer junto con los mensajes interactivos en cajas de texto.
1

58

Paletas de herramientas para diseo de forms Win y Web

Insertar controles:

Cortar, copiar y pegar controles:

Alinear, distribuir y uniformizar los tamaos de los controles (solo disponible para form GUI-Windows):

Podemos definir un control como un rea de la interfaz con el usuario, que tiene una forma y un comportamiento 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. - Lnea: Con este control se dibujan lneas horizontales o verticales (form Win). - Recuadro: Permite definir recuadros de distintos tamaos y formas (form Win). - Grid: Permite definir grillas de datos. - Botn: Permite incluir botones en los forms. - Bitmap: Permite definir bitmaps estticos. La mayora de los controles anteriores (salvo lnea y recuadro) estn disponibles tanto para ser utilizados en interfaz GUI-Windows como Web. A su vez el tab control es un control que solo est disponible para ser utilizado en interfaz GUI-Windows, mientras que otros controles solo pueden utilizarse en interfaz Web (text blocks, tablas, grids freestyle, Error Viewer, etc.). Tab Control: tiene una o varias solapas, en las cuales se pueden distribuir controles. Cada solapa tiene un ttulo 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 informacin de la transaccin Customer en 2 solapas: una para ingresar los datos generales del cliente, y otra para ingresar los datos comerciales, podemos insertar en el form un Tab 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 encuentra disponible 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 haya indicado; en caso de ser necesario, se abrir el dilogo correspondiente a las propiedades del control, para que se indiquen aquellas que sean de carcter obligatorio.

59

Controles en form Web

Cada control del form Web podr tener una clase asociada, de un objeto theme (tema) determinado, asociado al objeto. Al crear una KB, se crea por defecto el tema Default y todos los objetos que se creen tendrn este tema. Esto permitir independizar el diseo de la interfaz, de la programacin.
Existe el Editor de temas, un utilitario que usarn los diseadores grficos 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 diseo de los mismos.

El control hereda el diseo 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 GUIWindows, refiere a los aspectos de diseo. Las aplicaciones Web, programadas en HTML, pueden llegar a ser verdaderamente vistosas. Para lograr separar los aspectos de diseo grfico de un sitio web, de los aspectos de programacin propiamente dichos, existe un tipo de objeto llamado Theme (Tema, en espaol), y un utilitario independiente para editar objetos de este tipo, el Editor de Temas. Este utilitario puede tambin invocarse desde GeneXus mediante el tem Tools/Theme Editor estando en el modelo de diseo. El objetivo de esta separacin es poder paralelizar el desarrollo de un sitio Web, permitindole al programador abocarse a las tareas de programacin, y apoyarse en un diseador grfico para que defina las cuestiones de diseo. De esta manera el diseador grfico configurar el tema elegido por el programador, utilizando este utilitario independiente, y el programador slo deber aplicarlo a los objetos de su base de conocimiento (para esto existe una propiedad de nombre Theme a nivel de modelo y otra propiedad 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 aparecer en el form Web de un objeto GeneXus. Por ejemplo, tendr varias clases para el control botn, algunas para el control atributo, una clase para el control Error Viewer, etc. Cuando se crea una base de conocimiento, automticamente aparecer dentro de la carpeta Objects (que contendr todos los objetos GeneXus que se vayan creando) un objeto de tipo Theme cuyo nombre es Default. Este tema contiene un conjunto de clases asociadas a los distintos controles existentes2. Los objetos con form Web que se vayan creando tendrn por defecto asociado este Theme, y cada control que aparezca en sus forms tendr asociado una clase de ese tema, para este control.

------------------------------------------------------------------------------------------------------------Al final de este captulo se mencionar que al igual que cada atributo tiene un conjunto de propiedades configurables por el programador, as cada modelo y cada objeto. Por ejemplo, la propiedad Theme se encontrar para configurar en los dilogos de propiedades asociados a cada modelo Web y a cada objeto que 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.
1

60

Controles en form Web

Ejemplo: transaccin Customer con tema Default

De este modo, cuando el analista crea la transaccin Customer e ingresa su estructura, al grabar podr apreciar que el form Web tendr automticamente el aspecto que se muestra en la pantalla de arriba a la izquierda. Quin dio formato a todos los controles si no lo hizo el analista explcitamente? Pues bien, todas las transacciones tendrn asociado por defecto el theme Default y todos los controles que se coloquen en el form, tendrn clases de este tema asociadas. Si sobre el botn Apply Changes, con el botn derecho del mouse se editan sus propiedades, se abrir un dilogo (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 botn. Esta propiedad puede ser cambiada por el analista (podemos ver que se trata de un combo box). All cliquear el combo box podremos ver una lista de clases posibles para ese botn (son las que figuran en el tema asociado), pero tambin aparece la opcin (none) para no asociarle clase alguna. Esto es lo que hemos seleccionado en la pantalla de la derecha (el valor none para la propiedad Class del botn) y podemos ver su repercusin inmediata en el botn en el form. Si se comparan los dos dilogos de propiedades del control Apply Changes, donde lo nico que ha sido modificado explcitamente por el analista ha sido la clase, podemos ver que implcitamente se han modificado algunas propiedades (el BackColor, ForeColor, BorderWith, etc.). Esto se debe a que estas propiedades se heredan de la clase una vez definida, pero si el analista as lo desea, puede modificarlas para ese control botn, independizndolo 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.

61

Demo
Cmo crear un modelo dentro de la base de conocimiento?
WIZARD MANUAL

Para definir un nuevo modelo -a excepcin del de Diseo, que se crea automticamente-, debe seleccionarse la opcin File / New Model. GeneXus provee de un wizard para guiar al usuario en los pasos de creacin del nuevo modelo. Si el usuario prefiere no utilizar el wizard e ingresar los distintos datos sin esta gua, deber presionar el botn Manual Creation de la primera pantalla del wizard, y ste se cerrar y se abrir el dilogo Model Properties. A continuacin se detalla parte de la informacin que se deber ingresar: Information Name: Nombre del modelo que se est definiendo. Type: Tipo de modelo (Prototipo o Produccin). Language: Idioma en el que saldrn impresos los textos de los botones, mensajes, etc., que son generados automticamente por GeneXus en los programas de la aplicacin. Los lenguajes soportados son: Espaol, Ingls, Italiano, Portugus y Chino. El valor del lenguaje solo puede modificarse en el modelo de Diseo de la base de conocimiento; los dems modelos heredarn este valor y no podrn modificarlo. Se debe suministrar informacin del ambiente o plataforma para el modelo que se est definiendo: Environment Language: Este es el lenguaje en el cul sern generados los programas usados para la creacin y reorganizacin de la base de datos, y tambin es el lenguaje predeterminado en el que sern generados todos los objetos. Pueden definirse ambientes secundarios en la solapa Environments del dilogo, que permitirn generar algunos de los objetos en otros lenguajes. Los lenguajes soportados por GeneXus son: .NET, .NET Mobile, Cobol para iSeries, Java, RPG para iSeries, Visual Basic, Visual FoxPro.

62

User Interface: Una vez que el lenguaje ha sido elegido, se puede seleccionar el tipo de interfaz que se quiere usar para 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 cul operarn los programas en ejecucin. La lista solo incluir aquellos soportados por el lenguaje e interfaz previamente seleccionados. Target Path: Directorio donde estarn ubicados los programas generados. Este directorio ser creado bajo el directorio de la base de conocimiento. El valor predeterminado es DATAnnn, donde nnn representa el nmero de modelo (GeneXus numera secuencialmente los modelos a medida que se van creando). A continuacin se muestra una tabla con los valores de DBMSs posibles para cada lenguaje:

Properties Haciendo clic en el botn Properties se pueden configurar las propiedades para el lenguaje seleccionado. Solemos llamar a estas propiedades: propiedades a nivel del modelo o ms reducido: propiedades del modelo. DBMS Options Haciendo clic en el botn DBMS Options se puede configurar la informacin requerida para el acceso a la Base de Datos (Data Source, etc.) para el lenguaje y DBMS seleccionados. Execution Haciendo clic en este botn, se pueden especificar configuraciones de ejecucin para el lenguaje seleccionado. Save/Load Estos botones permiten almacenar la informacin de las propiedades del modelo en un archivo (y luego recuperarlo). La extensin predeterminada de este archivo es GMP (GeneXus Model Properties). From Model Permite copiar la informacin en forma directa, desde otro modelo de Prototipo / Produccin dentro de la base de conocimiento. Una vez creado un modelo, es posible modificar sus propiedades. Para ello, se debe seleccionar la opcin File / Edit Model, y se presentar el dilogo Model Properties. Suele ser usual acceder al dilogo Model Properties, en especial para utilizar los botones Properties, DBMS Options y Execution para configurar sus propiedades con los valores particulares que se requiera para el modelo. Sin embargo no es usual cambiar en el dilogo Model Properties lo configurado en la seccin Enviroment (ya que si se desea probar la aplicacin para otra plataforma / ambiente, la forma correcta de proceder es crear otro modelo para la plataforma deseada).

63

Qu son los conceptos...?

Anlisis de Impacto Reorganizar Especificar Generar

Cuando se pasa a un modelo de Prototipo o Produccin en una base de conocimiento, GeneXus compara las definiciones realizadas en el modelo de Diseo, con respecto a las definiciones que existan en el modelo al cual se est ingresando. Por ejemplo, si se est ingresando a un modelo de Prototipo o Produccin recientemente definido (y por ende vaco), todos los objetos definidos en el modelo de Diseo sern nuevos para dicho modelo. Y las transacciones definidas, tal como es su objetivo, provocarn la creacin de las tablas que corresponda en la base de datos asociada al modelo de Prototipo o Produccin. Esta comparacin que hace GeneXus entre las definiciones del modelo de Diseo de una base de conocimiento y las definiciones de cierto modelo de Prototipo o Produccin al cual el programador pasa, se llama anlisis de impacto. Este nombre es autodescriptivo: GeneXus analiza el impacto causado por las definiciones del modelo de Diseo sobre un modelo de Prototipo o Produccin. El resultado del anlisis de impacto es un reporte de anlisis de impacto (IAR: Impact Analisis Report) que informa al programador qu cambios fsicos o estructurales habra que realizar en la base de datos asociada al modelo de Prototipo o Produccin en cuestin. Si el programador est de acuerdo con los cambios estructurales informados en el reporte de anlisis de impacto, podr proseguir, pasando a reorganizar la base de datos. El trmino reorganizar refiere a efectuar cambios fsicos en la base de datos. Si en cambio el programador encuentra que algo de lo informado en el reporte de anlisis de impacto no era lo que pretenda lograr, podr no efectuar la reorganizacin, y volver al modelo de Diseo para realizar las redefiniciones que crea convenientes. Cuando se decide efectuar una reorganizacin GeneXus genera programas (en el lenguaje elegido en la definicin de la plataforma del modelo) que implementan las modificaciones a realizar en la base de datos. La ejecucin de estos programas tiene por resultado la obtencin de una nueva versin de la base de datos con los cambios efectuados.

64

Inmediatamente despus de reorganizar la base de datos, se copiarn automticamente las nuevas definiciones del modelo de Diseo al modelo de Prototipo o Produccin en el cual se est trabajando (destino); esto se llama Copy Model y significa que el modelo de Prototipo o Produccin quedar con exactamente las mismas definiciones que el modelo de Diseo. El siguiente paso ser obtener los programas de aplicacin asociados a los objetos GeneXus. Para ello el programador GeneXus deber especificar y generar los programas de aplicacin. Especificar un objeto componen: estructura, definiciones, la validez navegacin, en el cual significa que GeneXus analizar todo lo definido en cada uno de los elementos que lo forms, u otros elementos segn corresponda. GeneXus verificar la sintaxis de las de lo definido, y como resultado de la especificacin mostrar al usuario un listado de informar la lgica que ha interpretado, y si hay alguna advertencia o error.

Luego de especificar un objeto (o conjunto de objetos) y verificar el listado de navegacin resultante, el programador podr indicar a GeneXus que prosiga con la generacin de los programas de aplicacin. Generar un objeto, significa que GeneXus escribir lneas de cdigo que implementen la programacin del mismo, en el lenguaje elegido. Otro ejemplo Como hemos explicado, cuando se pasa a un modelo de Prototipo o Produccin GeneXus realiza una comparacin de las definiciones del modelo de Diseo con respecto a las definiciones que existan en el modelo al cual se est pasando. Esto es, un anlisis de impacto. Si se pasa a un modelo de Prototipo o Produccin al cual ya se haba pasado anteriormente alguna vez, seguramente dicho modelo ya tenga algunas definiciones1 , a diferencia del ejemplo anterior en el cual se trataba de un modelo nuevo y vaco. Si por ejemplo el modelo de Prototipo o Produccin al cual se est pasando tiene definida una transaccin Customer con la estructura: Customer CustomerId* CustomerName CustomerAddress CustomerGender

Numeric(6) Character(20) Character(30) Character(1)

y en el modelo de Diseo se encuentran definidas las transacciones Customer y Product con las siguientes estructuras: Customer CustomerId* CustomerName CustomerAddress CustomerGender CustomerEMail Product ProducId* ProductDescription ProductPrice ProductStock

Numeric(4.0) Character(30) Character(30) Character(1) Character(30)

- Numeric(4.0) - Character(20) - Numeric(10.2) - Numeric(4.0)

el anlisis 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 informarn en un reporte de anlisis de impacto (IAR: Impact Analisis Report), y el programador deber estudiarlo para decidir si efectuar la reorganizacin o no.

------------------------------------------------------------------------------------------------------------------------1 Cabe la posibilidad de que en una base de conocimiento haya algn modelo de Prototipo o Produccin sin objetos. Esto puede ocurrir por el simple motivo de que se haya creado un modelo, pero luego no se haya ejecutado una reorganizacin en el mismo, ni se hayan copiado las definiciones del modelo de Diseo (Copy Model) tampoco. Sin embargo, el ejemplo trata de un modelo Prototipo en el cual ya se ha ejecutado una reorganizacin y seguidamente se han copiado las definiciones del modelo de Diseo (Copy Model) al mismo.

65

En el caso de decidir reorganizar la base de datos, seguidamente se copiarn automticamente las nuevas definiciones del modelo de Diseo al modelo de Prototipo, quedando ste con exactamente las mismas definiciones que el modelo de Diseo. (Copy Model). Por ltimo slo restar que el programador GeneXus especifique y genere los programas correspondientes a los objetos que hayan sufrido cambios. Concluyendo, hemos explicado varios conceptos que son muy importantes, viendo una primera aplicacin de ellos, y luego una segunda aplicacin de los mismos, con el objetivo de entender qu realiza cada una de estas operaciones y en qu orden se ejecutan.

66

tem Build de la barra de men de GeneXus

Opciones del tem Build para especificar y generar El tem Specify se habilitar cuando se est en un objeto abierto; el objetivo de este tem es especificar el objeto activo. El tem Specify..., abrir un dilogo de seleccin de objetos para seleccionar cules objetos se desean especificar. 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 del modelo para ser especificados, que seleccionar directamente el tem Build All.... Cmo 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 navegacin por cada objeto especificado; cada listado de navegacin informar cul fue la lgica interpretada para el objeto, y si ser necesario generar el programa de aplicacin asociado al mismo, o no1. La ventana que contiene los listados de navegacin incluir un botn de nombre Generate, que podr ser seleccionado por el programador para continuar con la generacin de los programas de aplicacin que sean necesarios. Adems del botn Generate, se ofrecer tambin un botn Cancel. Es importante tener claro que en caso de seleccionarlo, quedar pendiente la generacin de los programas de aplicacin asociados a los objetos que fueron especificados; esto significa que en la siguiente oportunidad que el programador seleccione el botn Generate as haya especificado en ese momento un solo objeto o varios- se generarn adems de los programas que correspondan ser generados en esa ocasin, todos los programas pendientes de generacin, por haberse especificado anteriormente sin continuar con la generacin2.

-------------------------------------------------------------------------------------------------------------------El motivo por el cual un listado de navegacin podr informar que no ser necesario generar el programa asociado a un objeto, es que el objeto no haya sufrido cambios con respecto a la ltima vez que se gener, y por ende el programa generado antes seguir estando vigente ahora.
1 2

Por esto solemos decir que podemos elegir qu objetos especificar, pero no cules generar.

67

En qu modelos se especifican y generan los objetos? Diseo? Prototipo? Produccin? En los tres tipos de modelos es posible especificar los objetos, pero solamente en los modelos de Prototipo y Produccin se podrn generar los programas de aplicacin asociados a ellos. Recordemos que todo modelo de Prototipo o Produccin tiene asociada una plataforma (base de datos, lenguaje de programacin, interfaz GUI-Windows / Web). En cambio, el modelo de Diseo no tiene asociada una plataforma y por tanto no se generar para el mismo base de datos ni programas. Es por esto que en el modelo de Diseo el programador podr especificar objetos con el nico objetivo de estudiar los listados de navegacin resultantes y con ello poder analizar la lgica interpretada por GeneXus para los mismos. Sin embargo, luego de estudiar listados de navegacin en el modelo de Diseo, no ser posible generar (no se ofrecer el botn Generate). Es en los modelos de Prototipo y Produccin en los que a continuacin de la especificacin de los objetos se ofrecer el botn Generate en la ventana que contiene los listados de navegacin, para que el programador pueda continuar con la generacin de los programas de aplicacin, 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 se hayan 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 base de conocimiento se deben realizar las distintas definiciones y/o modificaciones de objetos. nicamente en el modelo de Diseo de una base de conocimiento se podrn definir o editar transacciones, definir o editar atributos, y realizar modificaciones en las estructuras de las transacciones en general (incluyendo definiciones de dominios, ndices y subtipos1). Para ser ms exactos diremos que todas las operaciones que puedan provocar cambios estructurales en las tablas de la base de datos podrn realizarse solamente en el modelo de Diseo. En modelos de Prototipo y Produccin estarn deshabilitadas las operaciones de este tipo, y para realizarlas el programador deber pasar al modelo de Diseo de la base de conocimiento. En modelos de Prototipo / Produccin se podrn realizar definiciones que no provoquen cambios estructurales en las tablas de la base de datos (por ejemplo, crear o modificar objetos reportes, procedimientos, work panels, etc.; modificar reglas o forms de las transacciones, etc.1) y automtica e instantneamente se estarn realizando las mismas definiciones en el modelo de Diseo. Cul es la forma de trabajo entonces? Inicialmente se comienza a trabajar en el modelo de Diseo de una base de conocimiento. Se definen las primeras transacciones y dems objetos y definiciones que se consideren oportunas. Luego el analista deber crear un modelo de Prototipo para probar la ejecucin de las definiciones realizadas; habr un anlisis de impacto, reorganizacin, actualizacin del modelo de Prototipo (Copy Model), y el analista especificar y generar los programas de aplicacin. Se podr ejecutar la aplicacin definida hasta el momento, y luego de ello se continuar trabajando en el modelo de Prototipo. Todas las definiciones y/o modificaciones de objetos que se efecten en el modelo de Prototipo, se efectuarn automticamente en el modelo de Diseo tambin; de modo que ambos modelos irn quedando instantneamente con exactamente las mismas definiciones (sincronizados). Por este motivo es que aconsejamos trabajar en el modelo de Prototipo. Cuando surja la necesidad de realizar definiciones que puedan afectar el diseo de la base de datos (por ejemplo, crear una nueva transaccin, modificar la estructura de una transaccin existente, modificar un dominio, etc.), habr que pasar necesariamente al modelo de Diseo; pero si no, recomendamos trabajar en el modelo de Prototipo, ya que automticamente el modelo de Diseo se estar actualizando tambin.

-------------------------------------------------------------------------------------------------------------------1 Ms adelante en el curso se irn introduciendo estos temas.

68

Qu pasa si trabajamos en el modelo de Diseo? Si en el modelo de Diseo realizamos al menos una definicin que implique modificar el diseo de la base de datos, cuando el programador pase al modelo de Prototipo, GeneXus detectar que habr cambios fsicos para hacer. Habr un anlisis de impacto, reorganizacin y actualizacin del modelo de Prototipo (Copy Model), y lo nico que le restar hacer al analista ser especificar y generar los objetos nuevos (que nunca hayan sido especificados y generados), y los objetos existentes que hayan sido modificados luego de su ltima especificacin. Sin embargo si se trabaja en el modelo de Diseo solamente definiendo objetos que no implicarn modificar estructuralmente la base de datos, cuando el programador pase al modelo de Prototipo, GeneXus no detectar cambios fsicos para hacer, y no efectuar ninguna operacin, ni siquiera la actualizacin del modelo de Prototipo (Copy Model). De modo que las definiciones y modificaciones que se hayan hecho en el modelo de Diseo, no se copiarn automticamente al modelo de Prototipo, y ser responsabilidad del programador hacerlo, seleccionando uno de los tems posibles para ello1. Es sumamente importante que un modelo de Prototipo/Produccin con el cual se est trabajando en determinada etapa (veremos que podrn haber modelos en una base de conocimiento con los cuales no se est trabajando momentneamente), est actualizado con respecto al modelo de Diseo (es decir, que siempre que se trabaje en el modelo de Diseo, al pasar al modelo de Prototipo, se ejecute la operacin Copy Model, ya sea automticamente luego de ejecutar una reorganizacin, o a pedido del analista si no hubo reorganizacin). Si se pasa a un modelo de Prototipo/Produccin y ste no se actualiza con las definiciones del modelo de Diseo (Copy Model), los objetos del modelo de Prototipo/Produccin al cual se pas estarn desactualizados. Si se especifican y generan estos objetos, deber comprenderse que se tratar de definiciones viejas; y si se ejecuta la aplicacin generada, no se vern las nuevas definiciones realizadas, ya que las mismas quedaron hechas en el modelo de Diseo, pero falt que fueran copiadas al modelo de Prototipo, y recin luego de ello, se tendran que haber especificado y generado. Adems, si el analista llegara a modificar objetos desactualizados en el modelo de Prototipo, la prxima vez que realice una actualizacin del modelo de Prototipo (Copy Model), se perdern las modificaciones realizadas en versiones viejas de los objetos, ya que se traern las versiones de los objetos del modelo de Diseo. Concluyendo, hemos recomendado en qu modelo definir qu objetos, cundo habr que pasar de un modelo a otro, y cules pasos seguir. Como dijimos anteriormente, si bien es posible hacerlo en Diseo, la especificacin de los objetos suele realizarse en el modelo de Prototipo. En el modelo de Diseo no se generan programas a continuacin de las especificaciones, y el nico motivo por el cual se podra necesitar especificar algn objeto, sera porque se vaya a seguir trabajando en el modelo de Diseo realizando definiciones, y se necesite corroborar la lgica interpretada 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 Diseo. En los modelos de Prototipo y Produccin, en cambio, lgicamente ser necesario especificar y generar los objetos que hayan sufrido cambios, previamente a la ejecucin de la aplicacin. Otras opciones del tem Build Todas las opciones que se describen a continuacin se encuentran disponibles nicamente para modelos de Prototipo y Produccin. Build / Impact Database Al seleccionar esta opcin, se ejecutar un anlisis de impacto para el modelo en el cual se est trabajando. Seguidamente se desplegar el reporte de anlisis de impacto correspondiente. Build / Impact From Un anlisis de impacto siempre se efecta comparando las definiciones del modelo de Diseo con las definiciones del modelo actual o destino. No obstante, esta opcin permite realizar un anlisis de impacto tomando cualquier modelo definido en la base de conocimiento como base, en relacin al modelo actual. Al seleccionar esta opcin se desplegar un dilogo para seleccionar cul de todos los modelos definidos en la base de conocimiento se desea tomar como base para realizar un anlisis de impacto para el modelo actual. Es fundamental tener bien claras todas las acciones posibles que pueden desencadenarse al efectuar un anlisis de impacto:

------------------------------------------------------------------------------------------------------------------Existen algunas opciones del men que permiten hacer esto, con algunas variaciones y son las que se presentan al final de esta pgina, bajo el ttulo Otras opciones del tem Build.
1

69

Sin embargo, puede ocurrir que no se desee ejecutar un anlisis de impacto, ni reorganizacin consecuente, ni actualizacin total del modelo actual, sino que solo se deseen copiar algunos de los objetos del modelo de Diseo al modelo actual.

Build / Impact Objects Se desplegar la lista de objetos que tengan diferencias en el modelo de Diseo con respecto al modelo actual y se podrn 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 en el modelo de Diseo con respecto al modelo actual, slo podrn ser copiados aquellos objetos que usen la misma estructura de base de datos en ambos modelos. Por ejemplo, una transaccin no podr copiarse al modelo actual si se le ha agregado un nuevo atributo (en el modelo de Diseo) y an no se ha efectuado la reorganizacin correspondiente. Resulta sencillo de entender que no sea posible solamente copiar una transaccin al modelo actual, si la misma tiene implicada una reorganizacin pendiente para hacer. Para cada objeto de la lista que se haya seleccionado e intentado copiar al modelo actual, se informar si fue posible realizar la copia o no (y en caso negativo, el motivo).

Build / Create Database Se ejecutar un anlisis de impacto para el modelo en el cual se est trabajando, con la particularidad de que se analizar el impacto causado por las definiciones del modelo de Diseo, sobre el modelo actual como si estuviera vaco. En consecuencia el reporte de anlisis de impacto informar que se debern crear todas las tablas con sus estructuras vacas.

70

Ejecucin de las aplicaciones

Build / Run:

Bajo el tem Build de la barra de men de GeneXus, se encuentra la opcin Run para ejecutar las aplicaciones generadas. Al seleccionar Build/Run o F5, se desplegar el dilogo de ejecucin (Execution Dialog) mostrado arriba. El dilogo de ejecucin ofrece todos los programas posibles de ser compilados y ejecutados. Estos son: 1) Developer Menu: Es un programa que GeneXus genera automticamente, y el mismo contiene invocaciones 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 el principal 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).

71

Modos de las transacciones en tiempo de ejecucin

Al ejecutar una transaccin se pueden distinguir los siguientes modos, dependiendo de la operacin que se realice:
Modo Insert: Indica que se est efectuando una insercin Modo Update: Indica que se est efectuando una actualizacin Modo Delete: Indica que se est efectuando una eliminacin Modo Display: Indica que se est efectuando una consulta

Dependiendo del ambiente de generacin, habr algunas diferencias en lo que se refiere a la operativa de las transacciones en tiempo de ejecucin. No obstante, ms all de la plataforma, cada vez que se realice una operacin de insercin, actualizacin, eliminacin, o consulta a la base de datos a travs de una transaccin, habr un modo asociado.

72

INTEGRIDAD REFERENCIAL

73

Diagrama de Bachman

COUNTRY
1

CountryId* CountryName

CUSTOMER

CustomerId* CustomerName CountryId

El concepto de integridad referencial es un concepto que tiene que ver con las bases de datos relacionales. Se refiere a que debe haber consistencia entre los datos de las distintas tablas de una base de datos relacional. Las tablas de una base de datos relacional se encuentran relacionadas por atributos que tienen en comn. Estas relaciones implican que los datos de las tablas no son independientes, sino que al insertar, modificar y eliminar registros en una tabla, se deben tener en cuenta los datos de las otras tablas para que siempre se conserve la consistencia de la informacin 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: CustomerId Clave Fornea: CountryId (COUNTRY) El hecho de que el atributo CountryId en la tabla CUSTOMER sea una clave fornea con respecto a la tabla COUNTRY, establece una relacin entre ambas tablas. La relacin entre ellas puede verse en el diagrama que mostramos arriba (Diagrama de Bachman). En el Diagrama de Bachman, la flecha simple representa la existencia de una instancia de la tabla apuntada, para cada instancia de la otra (es decir, que para cada cliente existe un y solo un pas). La flecha doble representa la ocurrencia de varias instancias de la tabla apuntada, para cada instancia de la otra tabla (es decir, que para cada pas, existen muchos clientes). Se dice que la relacin entre la tabla COUNTRY y la tabla CUSTOMER es 1 a N (1 a muchos). Recprocamente, la relacin entre CUSTOMER y COUNTRY es N a 1 (muchos a 1).

74

Diagrama de Bachman
COUNTRY
1 N
Hay que verificar existencia del COUNTRY referenciado.

CUSTOMER

En transaccin Customer: si se inserta nuevo registro, o si se modifica el CountryId de un registro

COUNTRY
1 N

En transaccin Country: si se quiere eliminar un registro

CUSTOMER

Hay que verificar la no existencia de ningn CUSTOMER que lo referencie.

En la terminologa GeneXus, decimos que existe una relacin de subordinacin 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 el registro relacionado en la tabla superordinada (COUNTRY). Cuando se elimina un registro en la tabla superordinada (COUNTRY), no deben existir registros relacionados en la tabla subordinada (CUSTOMER).

Debido a esta relacin entre las tablas, la informacin contenida en ellas no es independiente, y es necesario realizar controles para que los datos sean consistentes. A estos controles se les llama de Integridad Referencial y bsicamente son los siguientes: Cuando se inserta o modifica un registro en la tabla CUSTOMER, el valor ingresado en el atributo que es clave fornea (CountryId), debe existir como valor de clave primaria de un registro en la tabla COUNTRY. Cuando se elimina un registro en la tabla COUNTRY, no deben existir registros en la tabla CUSTOMER cuyos valores de la clave fornea (CountryId), sean iguales al valor de la clave primaria del registro que se desea eliminar. GeneXus genera los programas asociados a las transacciones, incluyendo en el cdigo generado estos controles de Integridad Referencial. Por esta razn, si el usuario final inserta (o modifica) un cliente a travs de la transaccin "Customer", se validar automticamente que el valor ingresado en el cdigo de pas CountryId, exista como clave primaria de un registro en la tabla COUNTRY. En caso de fallar este control de integridad referencial, un mensaje se le desplegar al usuario indicndole que no se encontr ese pas.

75

ndices

Los ndices son vas de acceso eficientes a las tablas. GeneXus crea automticamente algunos de ellos, y los otros debern ser creados por el programador cuando ste as lo determine, basndose en criterios de optimizacin. Existen cuatro tipos de ndices en GeneXus: Primarios Forneos De usuario Temporales

De todos ellos, los nicos que no son creados automticamente por GeneXus son los de usuario. En cuanto a los tipos de ndices que son creados por GeneXus, la diferencia que hay entre ellos es el momento en que son creados y el tiempo durante el cual se mantienen. - Los ndices primarios y forneos son creados al momento de crear o reorganizar las tablas que componen la base de datos, y de ah en ms son mantenidos automticamente por GeneXus. - Los ndices temporales, en cambio, son creados al ejecutar las aplicaciones, para acceder a tablas ordenadas por algn atributo o conjunto de atributos para el/los que no existe un ndice de usuario creado; stos se crean en tiempo de ejecucin de las aplicaciones, se utilizan, y luego se eliminan. NDICES PRIMARIOS Y FORNEOS GeneXus crea para cada tabla un ndice por su clave primaria (ndice primario), y un ndice por cada clave fornea que la tabla tenga (ndices forneos). Por qu crear ndices primarios y forneos para las tablas desde el comienzo en forma automtica, siendo que luego deben ser mantenidos? Sean las tablas COUNTRY y CUSTOMER, que vimos un par de pginas atrs, creadas en nuestro modelo de datos a partir de las estructuras de las transacciones "Country" y "Customer. Existe entre estas tablas una relacin 1-N, que viene dada por el hecho de que el atributo CountryId en la tabla CUSTOMER es una clave fornea con respecto a la tabla COUNTRY.

76

ndices primarios y forneos

CountryId* CountryName
PK

ICountry

ICustomer CustomerId* CustomerName ... FK ICustomer1 CountryId

PK

CountryId CountryName 1 2 3 Uruguay United States China

CustomerId 4 1 3 2

CustomerName Ana Diez Juan Prez Mara Donoso Jessica Deep

CountryId 1 1 1 2

Si en transaccin Country queremos eliminar United States:

El programa debe buscar sobre CUSTOMER si registro con CountryId = 2 para hacer eficiente esta bsqueda: ndice forneo (ICustomer1)

Por existir esta relacin, 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 travs de la transaccin "Customer", se validar automticamente que el valor ingresado en la clave fornea CountryId exista como clave primaria de un registro en la tabla COUNTRY. En caso de fallar este control de integridad referencial, se le indicar al usuario que no se encontr ese pas. Para controlar esto, se debe buscar en la tabla COUNTRY la existencia de un registro que tenga ese valor de CountryId como clave primaria; dado que se debe consultar la tabla COUNTRY, buscando por la clave primaria, resulta evidente que la bsqueda puede optimizarse si existe un ndice por la clave primaria en dicha tabla. Si el usuario final intenta dar de baja un pas a travs de la transaccin Country, se validar automticamente que no existan clientes con dicho pas asociado, como clave fornea; en caso de encontrar un registro en la tabla CUSTOMER, cuyo valor de clave fornea CountryId sea el que se desea eliminar, se le indicar al usuario que no es posible eliminar el pas (ya que de lo contrario quedaran datos inconsistentes en la base de datos). Para controlar esto se debe consultar la tabla CUSTOMER, buscando por la clave fornea CountryId. Esta bsqueda ser ptima si existe un ndice por CountryId en la misma. Control de unicidad de clave primaria Otro control que GeneXus tambin incluye en los programas asociados a las transacciones es la unicidad de la clave primaria; esto es, en ninguna tabla podrn existir dos registros con el mismo valor en la clave primaria. Para controlar esto, cuando el usuario final intenta insertar un registro se valida automticamente que el valor ingresado para la clave primaria no exista ya como clave primaria de otro registro en la tabla. Para hacer esta bsqueda con eficiencia, se debe utilizar el ndice primario de la tabla. Concluyendo, GeneXus al crear cada tabla de la base de datos crea tambin su ndice primario, y un ndice forneo por cada clave fornea que la tabla contenga. La creacin de estos ndices permite realizar los controles de integridad referencial y de unicidad de clave primaria accediendo a las tablas de forma eficiente.

77

ndices de usuario
Los crea el analista sobre una tabla. Deber categorizarlos segn si aceptar valores repetidos (duplicate) o no (unique).

Si en la realidad modelada, un mismo nombre se puede repetir para dos clientes:

CustomerId 1 2 3 CustomerName Ana Ana Mara CountryId 1 2 1

NDICES DE USUARIO Estos ndices deben ser definidos explcitamente por automticamente. Se dividen en duplicate y unique. el analista. No son definidos

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 para atributos que no son una clave candidata). Este tipo de ndices se define fundamentalmente para acceder a los datos ordenados por determinados atributos de forma eficiente. A modo de ejemplo, suponiendo que el nombre de cliente no es clave en la tabla CUSTOMER (sus valores se pueden repetir) podremos definir un ndice de usuario duplicate por el atributo CustomerName, siendo muy til para realizar consultas y listados que se necesite salgan ordenados por nombre. Un ndice de usuario unique se utiliza para especificar que un conjunto de atributos es clave candidata en una tabla (diferente de la clave primaria). Esta es la forma de representar claves candidatas en el modelo de datos. Con ello logramos que GeneXus incorpore automticamente el control de unicidad correspondiente en las transacciones asociadas. A modo de ejemplo, si el nombre de cliente no se puede repetir, la forma de representarlo y lograr que GeneXus lo controle automticamente es definiendo en la tabla CUSTOMER un ndice de usuario unique por el atributo CustomerName.

78

ndices de usuario
Si un mismo nombre no puede repetirse (es por tanto un atributo clave de la tabla)
CustomerId 1 2 3 CustomerName Ana Diez Ana Prez Mara Rua CountryId 1 2 1

La forma de definir claves candidatas en el modelo de datos es a travs de ndices unique. GeneXus pasar a incorporar controles en las transacciones, utilizando el ndice, para no permitir la insercin de registros duplicados.
Si se intenta ingresar un nuevo cliente con nombre Ana Prez la transaccin 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, el analista elige una de las claves como la clave primaria. GeneXus identifica la clave primaria de la tabla de acuerdo a los atributos que fueron calificados por el analista con el smbolo de llave. Supongamos que en la realidad adems de poder identificar a un cliente por su cdigo, tambin se lo puede identificar por su cdula de identidad. En este caso tanto el atributo CustomerId como el atributo CustomerSSN (donde se almacena la cdula de identidad) seran claves de la tabla CUSTOMER. Al indicar que CustomerId es el identificador de la transaccin, GeneXus crear automticamente un ndice primario por dicho atributo y controlar la unicidad de los valores ingresados para el mismo. Y qu suceder con la cdula de identidad del cliente? Al ser este atributo clave, quisiramos que GeneXus obrara de igual manera, no permitiendo que se ingrese un registro, si es que ya existe otro con el mismo valor de cdula de identidad (CustomerSSN). Para poder controlar esto de forma eficiente, GeneXus debera contar con un ndice por cada atributo clave. La forma de definir en GeneXus que un atributo o conjunto de atributos es clave alternativa o candidata y que por lo tanto se debe chequear su unicidad, es definiendo un ndice de usuario compuesto por ese atributo o conjunto de atributos, y calificndolo 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 lgica de la transaccin ese control de unicidad utilizando ese ndice definido por el usuario. En resumen, las transacciones GeneXus realizan automticamente los siguientes controles: Integridad referencial Unicidad de clave (tanto primaria como candidatas)

79

ndices temporales
Son creados automticamente, bajo ciertas condiciones, cuando son necesarios, y se eliminan cuando termina la ejecucin del objeto que los cre. Si se desea acceder a los datos ordenados por determinados atributos, pero no se desea crear un ndice permanente para ello: GeneXus crear un ndice temporal.
Se crean solamente en algunas plataformas (como Visual FoxPro con base de datos local, o en iSeries). En otras plataformas, las consultas para las cuales se quiere obtener el resultado ordenado por determinados atributos, y no existe el ndice de usuario, son resueltas por el DBMS correspondiente sin la creacin 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 muy poca frecuencia), entonces, dependiendo de la plataforma, se crear un ndice temporal.

80

Manejo de nulos

Para cada atributo no inferido, ni identificador en la estructura de una transaccin, es posible definir si admitir nulos o no, en la tabla asociada

La permisin 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 vlido 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 transaccin (es decir, no inferidos) siempre y cuando no sean atributos primarios en dichas tablas (ya que por definicin las claves primarias no soportan valor null). Resumiendo: el objetivo de esta propiedad es definir qu valor se va a almacenar en la base de datos cuando no digitemos nada en el campo (el valor <NULL> o el valor empty).

81

Manejo de nulos
Valores posibles que ofrece la propiedad Nulls: - No: el atributo en la tabla asociada, no permitir valor null
- Yes: el atributo en la tabla asociada, s admitir valor null
Valor por defecto

Atributos parte de la clave primaria no soportan valor null (propiedad Nulls = No, siempre) Atributos clave fornea s, y esto tendr repercusin en los controles de integridad referencial.

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 definicin 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 una reorganizacin (para redefinir a nivel de la base de datos el soporte de nulabilidad del atributo en su tabla).

82

Manejo de nulos
Repercusin en controles de integridad referencial CountryId* CountryName CountryId* CityId* CityName CustomerId* CustomerName CountryId CityId

FK compuesta

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 realizar chequeo contra COUNTRY. si se deja nulo CityId, se

Repercusin en controles de integridad referencial La definicin de nulls para atributos que conforman una clave fornea le dice a GeneXus cun fuerte es la referencia a la otra tabla. Si ninguno de los atributos que componen una clave fornea permiten valores nulos (caso 1), se tratar de una referencia fuerte (tambin 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 fornea que tenga al menos un atributo que soporte nulos (caso 2), establece una referencia dbil (tambin conocida como null reference), ya que si alguno de los atributos que conforman la clave fornea son nulls, entonces la referencia no ser chequeada. Cuando una clave fornea es compuesta y estn permitidos los nulos para algunos de sus atributos, pueden aparecer nuevas referencias (no chequeadas en caso de tratarse de referencias fuertes) si los atributos que restan componen tambin una clave fornea. Un ejemplo es el que presentamos arriba, donde en caso de que el usuario deje nulo el valor de CityId para un cliente, se realizar el chequeo de IR contra COUNTRY, para asegurarse que el pas ingresado sea correcto.

83

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 debe ser considerado como: no especificado no disponible no asignado desconocido

Mtodos segn si atributo permite null o empty:

IsEmpty IsNull SetEmpty SetNull

Mtodos para trabajar con nulos y vacos IsEmpty, IsNull: devuelven true en caso de que el atributo contenga valor empty o null respectivamente. 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 didnt specify a Country) if ContryId.IsNull();

84

TABLA BASE Y TABLA EXTENDIDA

85

Tabla Base y Tabla Extendida

Definicin
Dada una tabla X de la base de datos, a la cual llamamos tabla base, se denomina tabla extendida de la misma al conjunto de atributos conformado por: Atributos que pertenecen a la tabla X. Atributos de toda tabla Y, tal que la relacin entre la tabla extendida determinada hasta el momento y la tabla Y sea N-1.

Los criterios de normalizacin del diseo de la base de datos apuntan a minimizar la posibilidad de inconsistencia en los datos. Una base de datos diseada de esta manera tiene una serie de ventajas importantes (tal es as que actualmente la normalizacin de datos es un estndar de diseo), pero se deben tener en cuenta tambin algunos inconvenientes. El inconveniente ms notorio es que los datos se encuentran dispersos en muchas tablas, y por lo tanto cuando se quieren hacer consultas ms o menos complejas a la base de datos, se debe consultar una cantidad importante de tablas. As, por ejemplo, si el siguiente Diagrama de Bachman representa nuestro modelo de datos:

para listar las facturas sera necesario consultar las tablas: INVOICE e INVOICELINE (lneas de Facturas), 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 en determinado momento; y dada cierta tabla base, su tabla extendida comprender a todos los atributos de la propia tabla base, ms todos los atributos de las tablas que tengan informacin relacionada unvocamente con la tabla base (relacin N-1 desde la tabla base, directa e indirectamente).

86

Tabla Base y Tabla Extendida

INVOICE
InvoiceId* InvoiceDate CustomerId

CUSTOMER
CustomerId* CustomerName CountryId

COUNTRY
CountryId* CountryName

INVOICELINE
InvoiceId* ProductId* InvoiceLineQuantity InvoiceLineAmount

PRODUCT
ProductId* ProductDescription ProductPrice ProductStock

Utilizando el Diagrama de Bachman es fcil determinar cul es la tabla extendida correspondiente a una tabla base cualquiera: Partiendo de la tabla base, se deben seguir las relaciones N-1, (es decir, se deben seguir las flechas que 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-1 desde la tabla base, formarn parte de su tabla extendida.

87

Tabla Base y Tabla Extendida

Para cada tabla de nuestro modelo de datos, describimos cul es su tabla extendida.

88

Descripciones en vez de Cdigos

Country Transaction CountryID* CountryName Customer Transaction CustomerID* CustomerName CountryID CountryName
Este atributo no es CountryName, sino CountryId disfrazado de CountryName. Se muestra (y acepta) en ejecucin el valor de CountryName, mientras que lo que se almacena es CountryId.

Hasta ahora hemos visto que el usuario final debe manipular los cdigos con los que el sistema identifica a sus entidades. Por ejemplo, a la hora de ingresar un nuevo cliente a un sistema, vimos que el usuario final ingresa el cdigo del pas de ese cliente y a continuacin se le muestra en forma inferida, el nombre correspondiente a ese pas. Para ello debe memorizar un cdigo que no tiene demasiada carga semntica (ninguna cuando stos son numricos) o apelar a prompts para poder buscar por descripcin o nombre y recuperar as el cdigo a ser colocado en el campo. Sin embargo no es necesario condenar al usuario a que manipule cdigos. Puede manipular las descripciones, que son las que contienen la semntica 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 descripcin, CountryName, y que automticamente se resuelva la manipulacin del cdigo, CountryId. Cmo? 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 es CountryName! Por el contrario, es el atributo: CountryId disfrazado de CountryName. Mientras el usuario escribe Uruguay internamente se realiza una bsqueda en la tabla COUNTRY para recuperar el cdigo correspondiente a ese nombre. Ese valor, en nuestro ejemplo, 1, es el que realmente queda almacenado all. Pero para el usuario esto es absolutamente transparente. Para que esto pueda lograrse, deber haber una relacin biunvoca entre el cdigo (o identificador) y la descripcin. Es decir, para cada descripcin solo existir un cdigo asociado. En el ejemplo, no deber haber dos o ms pases 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 navegacin de la transaccin se mostrar la siguiente advertencia: Spc0107 Candidate Key CountryName for CountryId may have duplicated values. y en ejecucin, si el usuario selecciona un valor duplicado (para el que existen varios CountryId) dar un error Country is ambiguous, dado que no sabr con cul quedarse.

89

Descripciones en vez de Cdigos

Propiedad InputType del atributo identificador
Valores posibles: Values
atributo real: lo que muestra es su contenido

Descriptions

atributo disfrazado: toma las descripciones de otro atributo, aunque su contenido sigue siendo el propio.

En la figura se muestra el dilogo de definicin del atributo CountryId. Como podemos ver, en la solapa Control Info del dilogo de definicin del atributo, aparece la propiedad InputType. Esta propiedad solo se ofrece cuando el atributo est asociando a un control 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 ejecucin mostrar los valores que contiene (cdigos). Descriptions: aqu es donde le indicamos que queremos que disfrace sus valores en ejecucin, mostrndole al usuario no sus valores reales, sino los asociados y definidos en la propiedad que se habilita: Descriptions from. En la propiedad Descriptions from se debe indicar de qu atributo se tomarn las descripciones. Evidentemente este atributo no puede ser cualquiera: debe tener una relacin biunvoca con el que estamos definiendo, y adems, debe ser un atributo de descripcin, es decir, un atributo cuyo tipo de datos sea Character o Varchar. De lo contrario se arrojar el siguiente error de especificacin: spc0112: Item value %1 for control %2 must be Character or VarChar.

90

Como en casi todos los casos, cuando una propiedad tiene que ver con la forma en que un atributo funciona a nivel de pantalla (control), existe la posibilidad de configurar su comportamiento: 1- En forma centralizada: Es decir, a nivel de la definicin del atributo en s (en la solapa Control Info asociada a la definicin del atributo), para que aplique por defecto en todos los forms en donde el atributo est presente como control 2- En forma particular: Es decir, para un control atributo en concreto de un form determinado (en la solapa Control Info asociada a la definicin del control).

Definicin en forma centralizada (a nivel del atributo) En el caso de configurar la propiedad IntputType a nivel de atributo, en toda transaccin en la que este atributo sea clave fornea (FK), GeneXus colocar en el form de la transaccin, el valor de la propiedad Title, del atributo elegido como descriptor (en este caso el title de CountryName) y a su lado al atributo identificador (en este caso la FK CountryId), que mostrar los valores de CountryName, pero almacenar los de CountryId. Como resulta evidente, ya no es necesario que en el form se coloque el atributo real CountryName, porque el atributo CountryId se disfraz de l. El usuario no sabr que mientras l est seleccionando o escribiendo un nombre de pas, en realidad lo que se est grabando en ese atributo es el cdigo o identificador correspondiente. GeneXus quita automticamente del form el atributo descriptor al momento en que la FK es definida con InputType= Description. Sin embargo, el atributo descriptor debe estar presente en la estructura de la transaccin, pues de lo contrario dar el siguiente error al especificar: Spc0109 CountryName is (part of) a candidate key. It must be referenced in the transactions structure. En la transaccin en la que el atributo identificador con InputType=Description es clave primaria, como resulta evidente, no toma ningn efecto esta propiedad. Es decir, en la transaccin Country el atributo CountryId se ver en ejecucin conteniendo cdigos, y el atributo CountryName esperar ser ingresado con datos del usuario.

91

Descripciones con autocomplete

Propiedad Suggest

Podemos hacer que en lugar de que el usuario tenga que recordar los valores existentes para ingresar uno correcto, se le sugieran los valores posibles para ese control, de modo que l pueda elegir el que deseaba y que ser necesariamente correcto. Aqu estamos combinando 2 propiedades: InputType y Suggest, lo que no es obligatorio.

La propiedad Suggest posibilita brindarle una ayuda til al usuario final, para que elija en tiempo de ejcucin 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 ms adelante. Habilitando la propiedad Suggest en un control edit, se conseguir que una lista de posibles valores para 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 las entradas del usuario) o haciendo pedidos explcitos (el usuario manualmente tendr que hacer un pedido para que se calculen las sugerencias y se le muestren). La actualizacin de la lista es asincrnica y los tiempos de clculo dependen de la calidad de la conexin. Esta propiedad es independiente de la propiedad InputType, aunque la utilizacin combinada de ambas producir aplicaciones con interfaces mucho ms amigables para el usuario.

92

Descripciones con autocomplete

Propiedad Suggest
El control para CountryId disfrazar sus valores por los de CountryName, que ahora le sern sugeridos al usuario a medida que vaya digitando letras del nombre Valores posibles: Incremental No OnRequest

Si miramos un par de pginas atrs, cuando vimos la propiedad InputType, tenamos la misma pantalla de propiedades para el atributo CountryId, solo que el valor que tenamos especificado en la propiedad Suggest era el valor por defecto: No. En ese caso el usuario tena que digitar el nombre del pas 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 ejecucin entre los valores posibles y no tenga que recordar exactamente el valor. Valores de la propiedad Suggest: Incremental: Se le irn sugiriendo al usuario los valores que correspondan con lo que haya digitado hasta el momento. Es incremental, puesto que va reduciendo el rango de lo mostrado interactivamente a medida que el usuario va agregando letras a lo que lleva digitado hasta el momento. OnRequest: La nica diferencia que tiene el valor Incremental es que en este caso no es interactivo. El usuario ingresar el substring que recuerde de la palabra y luego pedir explcitamente las sugerencias de las palabras que empiecen por o contengan esa cadena. Por ejemplo, si el usuario final sabe que un cliente que est buscando tiene apellido Prez, pero no recuerda el nombre, puede escribir Prez y pedir las sugerencias. Si tuviera configurado el valor Incremental en esta propiedad, entonces al digitar P de Prez ya se le traeran todos los nombres de clientes que empiezan con P y se ira afinando la bsqueda a medida que siga escribiendo letras. No: no sugiere nada. Este es el valor por defecto, y en este caso el usuario no recibir ningn tipo de ayuda para ingresar el valor en el campo. Para lograr que el usuario trabaje con descripciones en lugar de cdigos, otra posibilidad es configurar que el atributo CountryId utilice el control: combo box dinmico (indicndose tambin en este caso, que se muestren los nombres de los pases existentes en la tabla COUNTRY (CountryName), mientras que al momento de seleccionar uno en el combo, quedar el cdigo correspondiente en el atributo CountryId.

93

Reglas
Se utilizan para definir el comportamiento de las transacciones. Algunas reglas: Default Asignacin Msg Error Noaccept Add Subtract Serial Update Pueden incluir: atributos, variables, constantes y funciones. Son LOCALES a la transaccin. Programacin DECLARATIVA.

Las reglas, en el objeto transaccin, cumplen un rol muy importante ya que permiten programar su comportamiento (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 el orden en el que se ejecutarn. Pueden involucrar a los atributos definidos en la estructura de la transaccin1, as como a variables definidas dentro del objeto, constantes y funciones. Son solo vlidas dentro de la transaccin en la que estn definidas, es decir, son locales.

-------------------------------------------------------------------------------------------------------1 Todas las reglas de transacciones pueden involucrar atributos de las tablas base asociadas a la transaccin; y la mayor parte de ellas puede tambin involucrar atributos de las tablas extendidas de dichas tablas base. Para poder referenciar un atributo en una regla, el mismo deber estar incluido en la estructura de la transaccin (ya sea que pertenezca a alguna de las tablas base asociadas a la transaccin, o a sus tablas extendidas).

94

Algunas reglas vlidas para transacciones son:

Default
OBJETIVO: Permite asignar un valor por defecto a un atributo o variable; el valor por defecto inicializar al atributo o variable si se est realizando una insercin por medio de la transaccin (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 transaccin. var: es el nombre de una variable. exp: es una expresin que puede involucrar constantes, funciones, variables u otros atributos. FUNCIONALIDAD: Esta regla asigna el valor de la expresin exp como valor por defecto del atributo att o variable var, cuando la transaccin se ejecuta en modo Insert. Esta regla no es vlida para atributos que forman parte de la clave primaria de alguno de los niveles de la transaccin, porque es disparada luego de que la clave es ingresada (ya que solo en ese momento el modo es conocido y esta regla se dispara solo en modo Insert). EJEMPLOS: Default( InvoiceDate, &today ); /*Regla definida en la transaccin Invoice*/

Cuando se est insertando una factura nueva, se sugiere como valor de InvoiceDate el valor contenido en la variable del sistema today. Default( InvoiceDate, Today()); /*Regla definida en la transaccin Invoice*/

Anloga a la anterior, solo que en lugar de utilizar la variable del sistema today, se utiliza la funcin Today que devuelve la fecha correspondiente al da. Default( InvoiceLineAmount, ProductPrice*InvoiceLineQuantity); /* Regla definida en Invoice */ Cuando se est insertando una lnea de factura, se sugiere que el atributo InvoiceLineAmount (importe de la lnea) tome el valor resultante de evaluar la expresin ProductPrice*InvoiceLineQuantity (precio del producto por cantidad llevada del mismo). Nota: El tipo de datos de la expresin debe coincidir con el tipo de datos del atributo o variable

Regla de asignacin
OBJETIVO: Permite asignar a un atributo o a una variable, el valor de una expresin. 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 transaccin, o a sus tablas extendidas (debe estar declarado en la estructura). var: es el nombre de una variable. exp: es una expresin que puede involucrar constantes, funciones, variables u otros atributos, y debe ser del mismo tipo que att o var. cond: es una expresin booleana (puede contener los operadores lgicos 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 especfico de ejecucin de una regla. FUNCIONALIDAD: Una regla de este tipo permite asignar al atributo o variable de la izquierda, el valor resultante de evaluar la expresin. Como puede verse, la condicin es opcional; de no ponerla, la asignacin se realiza siempre. La asignacin a un atributo, implica su actualizacin en el registro que corresponda. Se pueden definir reglas de asignacin a atributos de alguna de las tablas bases asociadas a la transaccin, e incluso de sus tablas extendidas. Esto significa que pueden actualizarse atributos inferidos en una transaccin (siendo necesario declararlos en la estructura). EJEMPLO: InvoiceLineAmount = ProductPrice*InvoiceLineQuantity; /*Regla definida en la transaccin Invoice*/

Si el importe de cada lnea de una factura se calcula siempre multiplicando el precio del producto por la cantidad llevada del mismo, podemos utilizar esta regla de asignacin para liberar al usuario de realizar el clculo.

95

Error
OBJETIVO: Permite desplegar un mensaje de error si la condicin se satisface. Sirve para definir los controles que deben cumplir 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 expresin 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 transaccin es definida tambin como business component1. cond: es una expresin booleana (que puede contener los operadores lgicos 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 especfico de ejecucin de una regla. FUNCIONALIDAD: Esta regla despliega el mensaje del parmetro msg, var o character expresion, si la condicin cond que se evala resulta verdadera. El mensaje de error se despliega en una ventana popup cuando el ambiente de trabajo es Windows y en el control Error Viewer y/o un cuadro de texto cuando el ambiente de trabajo es Web, deteniendo cualquier actualizacin a la base de datos. Cuando la transaccin se ejecuta como business component1, de dispararse 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 transaccin Customer*/ Se evala la condicin CustomerName.isEmpty(), y si sta se satisface, se despliega el mensaje No se permiten clientes sin nombre en pantalla. No se permite continuar hasta que el usuario ingrese un nombre en el campo CustomerName o abandone la transaccin (en cuyo caso no se har en la base de datos actualizacin alguna). Error(No se permite eliminar facturas) if Delete; /* Regla definida en la transaccin Invoice */ Se necesita prohibir la eliminacin de facturas. Con esta regla, si el usuario intenta realizar una eliminacin, la condicin dar True y se disparar la regla, evitando la eliminacin.

Msg
OBJETIVO: Permite desplegar un mensaje de advertencia si la condicin 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 del primer parmetro, si la condicin se satisface, anlogamente a la regla Error; pero a diferencia de esta ltima, permite continuar con la ejecucin si la condicin sigue satisfacindose. Del mismo modo, si la transaccin es business component1, 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 de texto en ambiente Web. EJEMPLO: Msg( No se permiten clientes sin nombre ) if CustomerName.isEmpty(); /*Regla definida en la transaccin Customer*/ Se evala la condicin CustomerName.isEmpty(), y si sta se satisface se despliega el mensaje No se permiten clientes sin nombre. A diferencia de lo que ocurre con la regla Error, aqu s se permite continuar la ejecucin, pues no se trata de un error sino de una advertencia.

-------------------------------------------------------------------------------------------------------------------------------1 Estudiaremos este tema ms adelante en el curso.

96

Noaccept
OBJETIVO: Permite indicar que los atributos no aceptarn valores por parte del usuario (sern solo de salida). SINTAXIS: Noaccept( att1[, atti]) [if cond]; DONDE: atti: es un atributo perteneciente a alguna de las tablas bases asociadas a la transaccin. cond: es una expresin booleana (puede contener los operadores lgicos 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 especfico de ejecucin de una regla. FUNCIONALIDAD: En una transaccin, todos los atributos que pertenecen a las tablas base asociadas a la transaccin, por defecto son aceptados. Si queremos que algunos atributos con estas caractersticas no sean aceptados, entonces contamos con la regla Noaccept. EJEMPLO: Noaccept( IvoiceDate) if Update; /* Regla definida en la transaccin 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 condicin especificada. SINTAXIS: subtract(att1, att2) [if cond]; DONDE: att1, att2: son atributos pertenecientes a alguna de las tablas base asociadas a la transaccin, o a sus tablas extendidas (y deben estar declarados en la estructura) cond: es una expresin booleana (que puede contener los operadores lgicos and, or, not). FUNCIONALIDAD: La sustraccin se realiza teniendo en cuenta el modo en el que se est trabajando en la transaccin (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 transaccin Invoice, cada vez que se ingresa una lnea con un producto que se est comprando, se debe disminuir el stock del mismo, segn la cantidad llevada. Esto podra hacerse en forma sencilla con la siguiente regla de asignacin: ProductStock = ProductStock InvoiceLineQuantity; Si prestamos atencin, sin embargo, vemos que esta regla no nos sirve, pues no est condicionada a un modo particular, razn por la cul se disparar tanto cuando se est insertando una nueva lnea en la factura, como cuando se est eliminando o modificando una ya existente. Y en estos ltimos dos casos es incorrecto disparar la regla. De hecho, cuando se est eliminado una lnea existente, debe realizarse la operacin contraria, es decir, se debe devolver al stock lo que se haba quitado cuando se insert la lnea. Lo correcto entonces, teniendo en cuenta todos los casos posibles sera tener 3 reglas: ProductStock = ProductStock InvoiceLineQuantity if Insert; ProductStock = ProductStock + InvoiceLineQuantity if Delete; ProductStock = ProductStock + old(InvoiceLineQuantity) InvoiceLineQuantity if Update; Aqu estamos utilizando la funcin old, que devuelve el valor almacenado del atributo (es el valor antes de modificarlo). Para evitar tener que hacer todo esto, GeneXus provee la regla subtract que se encarga de hacer la asignacin correcta de 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.

97

Add
OBJETIVO: Suma el valor de un atributo al valor de otro atributo, si se satisface la condicin especificada SINTAXIS: add( att1, att2) [if cond]; DONDE: att1, att2: son atributos pertenecientes a alguna de las tablas base asociadas a la transaccin, o a sus tablas extendidas (y deben estar declarados en la estructura). cond: es una expresin booleana. FUNCIONALIDAD: La adicin se realiza teniendo en cuenta el modo en el que se est trabajando en la transaccin (Insert, Update 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 transaccin Customer, un atributo de nombre CustomerTotalPurchases, para registrar el importe total de compras efectuadas por el mismo. El comportamiento que se desea es que cada vez que se cree una factura para un cliente dado, se le sume el total de la factura (InvoiceTotal) al total de compras efectuadas por el cliente (CustomerTotalPurchases). Al igual que vimos en la regla subtract, no debemos olvidar que en la transaccin Invoice podemos tambin eliminar y modificar facturas, y no solo crearlas; por lo tanto es importante tener en cuenta el modo de trabajo en la transaccin (Insert, Update, Delete). GeneXus nos libera de tener que considerar nosotros a los modos, teniendo que escribir las siguientes tres reglas de asignacin en la transaccin 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 transaccin Customer agregamos el atributo CustomerTotalPurchases (total de compras del cliente): CustomerId* CustomerName CustomerAddress CustomerGender ... CustomerTotalPurchases y en la transaccin Invoice inferimos al atributo CustomerTotalPurchases, ya que pertenece a la tabla extendida y 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 atributo InvoiceTotal si se elimina una factura (Delete): se le sustrae al valor del atributo CustomerTotalPurchases el valor del atributo InvoiceTotal si se modifica una factura (Update): se le suma al valor del atributo CustomerTotalPurchases, la diferencia entre el valor nuevo y el viejo de InvoiceTotal

98

Serial
OBJETIVO: Permite numerar serialmente atributos numricos. SINTAXIS: Serial( att1, att2, step); DONDE: att1: es un atributo perteneciente a alguna de las tablas base asociadas a la transaccin (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 att1. step: es el paso o incremento de la serializacin. FUNCIONALIDAD: El propsito de esta regla es asignar un nmero correlativo a att1 cada vez que se inserta un registro en la tabla a la que pertenece att1. Se toma el valor de att2 (att2 contiene el ltimo nmero utilizado en la autonumeracin), se le suma el valor del parmetro step, y el valor resultante se asigna tanto al atributo att1 del nuevo registro, como al atributo att2 para conservar el ltimo nmero asignado. Es decir, cuando se est insertando un registro por medio de una transaccin en la cual se ha definido 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 obtenido tanto a att1 del registro que va a ser insertado, como a att2 perteneciente a una tabla directamente superordinada con respecto a la tabla que contiene a att1. Si se disea a la transaccin Invoice conteniendo un Nmero de Lnea de Factura (atributo InvoiceLineId) como identificador nico del segundo nivel, la estructura de la transaccin sera: InvoiceId* CustomerId CustomerName InvoiceDate InvoiceLastLineId (InvoiceLineId* ProductId ProductDescription ) En este diseo el atributo ProductId no es identificador nico del nivel, sino clave fornea nicamente. Cada lnea tiene un nmero de lnea que la identifica en forma nica, y es posible ingresar el mismo producto en distintas lneas. Podra ser til asignar por medio del sistema, nmeros correlativos al campo InvoiceLineId, definiendo la regla: serial(InvoiceLineId, InvoiceLastLineId, 1); El primer parmetro de la regla serial define cul es el atributo a numerar automticamente, en el segundo parmetro debe indicarse un atributo cuya funcin es guardar el ltimo valor asignado hasta el momento, y por ltimo el tercer parmetro es para indicar el incremento (en este caso se incrementa de uno en uno). El segundo parmetro (en el ejemplo InvoiceLastLineId) debe pertenecer a una tabla directamente superordinada a la tabla que contiene el atributo que se desea numerar automticamente (InvoiceLineId). La regla serial lo requiere as. En el ejemplo, se puede observar que InvoiceLastLineId se encuentra en la tabla de clave 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 nmero de lnea asignado hasta el momento (InvoiceLastLineId). La regla serial est implementada de forma tal que

99

necesita este atributo (para fijarse el ltimo nmero utilizado, sumarle el incremento, y asignar el prximo nmero a la nueva lnea). Consideracin: La regla serial es til a la hora de autonumerar lneas, no as cabezales (por ejemplo identificadores de facturas, de clientes, etc.). El motivo es el siguiente: para utilizar la regla serial, se requiere definir un atributo en una tabla directamente superordinada; esto resulta bien sencillo si se desean autonumerar lneas ya que alcanza con incluir este atributo en el nivel de la estructura inmediatamente superior al del atributo a autonumerar. Sin embargo, si lo que se quiere numerar automticamente es un atributo del primer nivel (cabezal), all no existe un nivel inmediatamente superior en la estructura; esto no es un problema sin solucin ya que para definir una relacin de superordinacin/subordinacin entre tablas, no solo est la posibilidad de disearlo en una misma estructura de transaccin con ms de un nivel; tambin transacciones distintas con atributos en comn, provocan la creacin de tablas relacionadas, y por ende, con relaciones de superordinacin / subordinacin entre ellas. El siguiente diseo incluye a una tabla de nombre NUMBER superordinada a las tablas INVOICE y CUSTOMER:

NUMBER

NumberCode* NumberLast

InvoiceId* CustomerId* INVOICE CUSTOMER InvoiceDate CustomerName NumberCode NumberCode CustomerId Como se puede observar, la tabla NUMBER tiene solamente 2 atributos: NumberCode que sera un cdigo para almacenar el tipo de nmero que se brinda (nmero de factura, nmero de cliente, etc.) y NumberLast para almacenar el ltimo nmero dado para cada NumberCode. La estructura de la tabla NUMBER sera: NumberCode* CUSTOMER INVOICE NumberLast 20 10 ltimo identificador de cliente asignado ltimo identificador de factura asignado

Para obtener este diseo, deberamos definir una transaccin Number con estructura: NumberCode* NumberLast Y relacionarla con las transacciones en las cuales se utilizara la regla serial:

InvoiceId* InvoiceDate CustomerId CustomerName NumberCode NumberLast (InvoiceLineId* ProductId ProductDescription )

Inferido: est en la tabla NUMBER directamente subordinada

CustomerId* CustomerName NumberCode NumberLast

100

Finalmente, agregando en la transaccin Invoice las siguientes reglas, lograramos 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 transaccin en modo insert, y filtra los registros que tengan dicho valor en el atributo, cuando se ejecuta la transaccin en modo update y delete. Y en la transaccin Customer la situacin es anloga; con las reglas siguientes podemos autonumerar clientes: serial( CustomerId, NumberLast, 1 ); equal( NumberCode, CUSTOMER ); Sin embargo, contamos con una solucin mucho ms simple para autonumerar cabezales: cuando una tabla tiene una clave simple (es decir formada por un solo atributo) y el tipo de datos es numrico, puede numerarse automticamente utilizando la funcionalidad que brindan los manejadores de base de datos para esto. La forma de indicarlo en GeneXus es configurando la propiedad Autonumber del atributo clave:

Si en la propiedad Autonumber de un atributo numrico clave, se selecciona el valor True, significa que se realizar la numeracin automtica del mismo. Se agregarn las siguientes propiedades en el dilogo: Start: Mediante esta propiedad se configura a partir de qu nmero comienza la numeracin automtica. Step: Mediante esta propiedad es posible configurar el incremento del campo (entre dos registros). For replication: Esta propiedad es slo vlida para el motor de base de datos SQL Server; el valor Yes le indica a ste que no debe aplicar la propiedad en caso de que la tabla sea receptora de replicacin (sino que debe mantener los nmeros que le vienen por replicacin). Para profundizar en el manejo de esta propiedad, recomendamos acceder al Help de GeneXus.

101

Update
OBJETIVO: Posibilita actualizar en el form de una transaccin (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 transaccin. FUNCIONALIDAD: En una transaccin, todos los atributos que pertenecen a las tablas base asociadas a la transaccin, por defecto son aceptados y los que perteneciendo a la tabla extendida, no pertenecen a la base, son inferidos, y por tanto no aceptados. Pero si queremos que algunos de estos atributos inferidos sean aceptados, para que el usuario pueda modificar desde el form su valor, entonces contamos con la regla Update. EJEMPLO:

InvoiceId* InvoiceDate CustomerId CustomerName

CustomerId* CustomerName

update(CustomerName);

102

Conceptos importantes sobre reglas de transacciones

En qu nivel de una transaccin se ejecutarn las reglas definidas en la misma? Cmo condicionar reglas para que se ejecuten en determinados modos?

En qu nivel de una transaccin se ejecutarn las reglas definidas en la misma? La mayor parte de las veces no es necesario agregar explcitamente en la definicin de las reglas el nivel de la transaccin en el cual se desea que se disparen, ya que los atributos involucrados en las reglas le dan 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 transaccin en la cual se encuentra definida (ya sea en la propia regla o en la condicin de disparo), GeneXus entender que la misma estar asociada al primer nivel de la transaccin. Anlogamente, si una regla referencia solamente a atributos del segundo nivel de la transaccin en la cual se encuentra definida (ya sea en la propia regla o en la condicin de disparo), GeneXus entender que la misma estar asociada al segundo nivel de la transaccin. 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 que contar con los valores de todos los atributos implicados. A continuacin presentamos ejemplos concretos: 1) Si se define la siguiente regla en la transaccin Invoice: Default(InvoiceDate, &today); como el nico atributo que se menciona en la regla es InvoiceDate, y es un atributo del primer nivel de la transaccin, GeneXus determinar que se tratar de una regla asociada al primer nivel. 2) Si se define la siguiente regla en la transaccin Invoice: subtract( InvoiceLineQuantity, ProductStock ); como los dos atributos que se mencionan en la misma se encuentran en el segundo nivel de la transaccin, GeneXus determinar que se tratar de una regla asociada al segundo nivel.

103

3) Si se define la siguiente regla en la transaccin Invoice: InvoiceLineDiscount= InvoiceLineAmount * CustomerDiscountPercentage/100; siendo InvoiceLineDiscount (descuento correspondiente a una lnea) un atributo perteneciente al segundo nivel de la transaccin Invoice y CustomerDiscountPercentage (porcentaje de descuento otorgado a un cliente) un atributo declarado en el primer nivel de la transaccin Invoice, GeneXus determinar que se tratar de una regla asociada al segundo nivel de la transaccin. Cuando nos referimos a que una regla est asociada a determinado nivel, significa que la misma se ejecutar para cada instancia con la cual se trabaje a travs de ese nivel (si se cumple la condicin de disparo de la regla, claro est). En el caso del primer ejemplo visto, la regla Default(InvoiceDate, &today) es una regla asociada al primer nivel de la transaccin Invoice. Esto significa que se ejecutar para todo cabezal de factura que se inserte a travs del primer nivel de la transaccin Invoice (la regla Default tiene la particularidad de dispararse nicamente cuando el modo de ejecucin es Insert). En el caso del segundo ejemplo visto, la regla subtract(InvoiceLineQuantity, ProductStock) es una regla asociada al segundo nivel de la transaccin Invoice. Esto significa que se ejecutar para toda lnea de factura que se inserte, actualice o elimine a travs del segundo nivel de la transaccin Invoice. En el caso del tercer ejemplo, la regla: InvoiceLineDiscount = InvoiceLineAmount * CustomerDiscountPercentage/100 es una regla asociada al segundo nivel de la transaccin Invoice. De modo que esta regla se ejecutar para toda lnea de factura que se inserte, actualice o elimine a travs del segundo nivel de la transaccin Invoice. Concluyendo, tal como se desprende de todo lo explicado, para cada factura con la cual se trabaje a travs de la transaccin Invoice: - para el cabezal: se ejecutarn las reglas asociadas al primer nivel - para cada una de las lneas: se ejecutarn las reglas asociadas al segundo nivel Es importante saber que como norma general GeneXus siempre determina que una regla se dispare en el primer momento en que sea posible, es decir, en aquel momento en el que cuente con todos los datos necesarios. Y solamente en algunos casos que as lo requieran, una misma regla se volver a disparar ms adelante. 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 transaccin 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. Cundo hay que especificar explcitamente el nivel de disparo de una regla? Existe una clusula opcional de nombre Level que permite modificar el nivel por defecto de disparo de una regla, cambindolo por un nivel posterior. Es decir, si por ejemplo una regla se ejecuta por defecto para el primer nivel de una transaccin y se desea que se ejecute para el segundo, se deber agregar a la regla el componente Level seguido de un atributo o conjunto de atributos del segundo nivel. Esto har que la regla se ejecute para cada una de las instancias correspondientes a las lneas, y no para la instancia correspondiente al cabezal como era el comportamiento por defecto. Por ejemplo, si definimos la siguiente regla en la transaccin 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 transaccin, ya que el nico atributo referenciado en la regla se encuentra en el primer nivel de la transaccin. Si por algn motivo deseamos que la regla se ejecute para cada una de las instancias correspondientes a las lneas en vez de ejecutarse para la instancia correspondiente al cabezal, tendremos que agregar en la definicin de la regla, la clusula Level seguida de uno o varios atributos del segundo nivel: msg(La fecha de la factura es mayor a la fecha actual) if InvoiceDate>&Today Level InvoiceLineAmount;

104

Agregar la clusula Level a una regla solamente tiene sentido si a continuacin de la misma se mencionan atributos que son de algn nivel posterior a los niveles de los atributos implicados en la definicin de la regla en s. En el ejemplo que sigue, el hecho de haber agregado la clusula Level a la regla no aporta ms informacin de la ya aportada por el atributo implicado en la definicin de la regla en s: msg(La fecha de la factura es mayor a la fecha actual) if InvoiceDate > &Today Level CustomerId; Es fcil 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 clusula Level en el ejemplo no aporta ms informacin y por lo tanto su agregado es innecesario. Por ltimo, en el ejemplo que sigue: InvoiceLineDiscount= InvoiceLineAmount * CustomerDiscountPercentage/100 Level InvoiceDate; si bien se incluy la clusula Level en la definicin de la regla, como el atributo que sigue a la clusula es de un nivel superior al nivel de los atributos referenciados en la regla, la clusula Level definida no aportar informacin til en este caso tampoco. Es decir, no es posible que habiendo involucrados atributos de un segundo nivel en una regla, la misma se ejecute en el primer nivel, ya que en el primer nivel no se tiene la informacin del o de los niveles inferiores (adems de que hay N instancias para el o los niveles inferiores). De modo que la regla seguir estando asociada al segundo nivel de la transaccin Invoice, no habiendo aportado informacin til la clusula Level en este ejemplo. Concluyendo, la clusula Level solamente tiene sentido que sea agregada para modificar el nivel por defecto de disparo de una regla, a un nivel posterior. Cmo condicionar reglas para que se ejecuten en determinados modos? GeneXus provee las siguientes funciones booleanas para poder incluirlas en la condicin de disparo de las reglas con el objetivo de limitarlas a que se ejecuten puntualmente en algunos de los modos posibles: Insert Update Delete

Ejemplos de uso (todas las reglas correspondern a la transaccin 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 la regla sin la condicin de disparo que hemos explicitado, el atributo InvoiceDate se deshabilitara en todos los modos de ejecucin. 2) Error( No se permite eliminar facturas ) if Delete; Si se intenta eliminar una factura, se disparar el error deteniendo la eliminacin. Como no hay atributos involucrados en la regla, por defecto el nivel asociado a la regla ser el primero. 3) Error( No se permite eliminar lneas de facturas ) if Delete Level InvoiceLineQuantity; Si se intenta eliminar una lnea de una factura, se disparar el error deteniendo la eliminacin. Observar que se ha explicitado en la regla la clusula Level seguida de un atributo del segundo nivel de la transaccin Invoice, para indicar que se desea que la misma est asociada al segundo nivel de la transaccin.

105

Tipos de dilogo
Dilogo campo a campo
Las validaciones, disparo de reglas y frmulas y grabaciones, se van efectuando en forma interactiva, en la medida que el usuario va trabajando en la pantalla (Ej: Vb, Vfp con interfaz Win)

Dilogo a pantalla completa (full screen)

Todas las validaciones, disparo de reglas y frmulas y grabaciones, se efectan cuando se confirma la pantalla completa (Ej: Java y .Net con interfaz Win)

Dilogo con Validacin a nivel del cliente (CSV)

Hbrido entre los dos anteriores
Disparo de algunas reglas y frmulas interactivas Grabaciones cuando se confirma la pantalla completa
(aqu se redisparan reglas y frmulas)

(Ej: Java y .Net, Win y Web)

GeneXus genera distintos tipos de dilogos para las transacciones. El dilogo utilizado para un modelo en particular, depender de su ambiente o plataforma (en particular de su interfaz, Win o Web). Los dos tipos de dilogo clsicos son: campo a campo a pantalla completa (full screen) Luego se ha creado un hbrido entre ambos, que funciona en algunos aspectos como el dilogo a pantalla completa y en otros como el campo a campo. Le llamaremos: dilogo con validacin a nivel del cliente (Client Side Validation).

Dilogo campo a campo En este tipo de dilogo, cada vez que se digita un valor en un campo y se abandona, se controla inmediatamente su validez. Las reglas y frmulas1 se van disparando a medida que se va pasando por los campos, y los datos de la tabla extendida se van infiriendo ni bien se van ingresando los valores de las claves forneas. Generalmente la grabacin de los datos en este tipo de dilogo es por registro, vale decir: Ni bien se terminan de ingresar los datos del cabezal y se pasa a las lneas, el registro correspondiente al cabezal es grabado. Ni bien se terminan de ingresar los datos de una lnea y se pasa a la siguiente, el registro correspondiente a la lnea de la cual se sali, es grabado. La grabaciones se van realizando interactivamente, y si se realiza explcitamente una confirmacin de datos, se grabar puntualmente el registro con el cual se est trabajando (el correspondiente al cabezal o el correspondiente a cierta lnea en la cual el cursor se encuentre). Los generadores Visual Basic y Visual FoxPro trabajan con este tipo de dilogo.

-----------------------------------------------------------------------------------------------------------------Estudiaremos las frmulas un poco ms adelante.

106

Tipos de dilogo
Client Server Client Server

Ingreso de datos Confirmacin

Validaciones Controles IR inferencias Reglas Frmulas Grabaciones

Ingreso de datos Validaciones Controles IR Inferencias Algunas reglas Frmulas Confirmacin

Validaciones Controles IR inferencias Reglas Frmulas Grabaciones

Dilogo a pantalla completa

Dilogo con CSV

Dilogo a pantalla completa (full screen) En este tipo de dilogo no se realizan validaciones de los datos, controles de integridad referencial (IR), inferencias de la tabla extendida, ni disparos de reglas y frmulas a medida que los datos van siendo ingresados por el usuario en la pantalla. Las validaciones, reglas y frmulas se disparan solamente en dos momentos: 1. Al ingresar a la transaccin (reglas que no dependen de nada, no tienen condiciones de disparo). 2. Al confirmar los datos. La confirmacin de los datos determina la grabacin de la pantalla completa, disparando previamente todas 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 dilogo. Sin embargo existe la posibilidad de modificar este comportamiento, para que el usuario final pueda tener mayor interaccin con la aplicacin de manera tal que no deba esperar a confirmar la transaccin para ver los atributos inferidos, as como las validaciones y disparo de reglas y frmulas. En lo que sigue explicaremos el dilogo a pantalla completa con Validacin a nivel del Cliente. Dilogo a pantalla completa con Validacin a nivel del Cliente (Client Side Validation) La base de este dilogo es a pantalla completa, pero el usuario tendr mayor interaccin con la aplicacin. Tanto las validaciones de datos, como los controles de IR y disparo de algunas reglas y frmulas, adems de realizarse cuando se confirma la transaccin (como en el dilogo full screen clsico), tambin se realizarn antes, en forma interactiva a medida que el usuario vaya ingresando y abandonando los campos de la pantalla. Las grabaciones de los registros s se realizarn a pantalla completa, tras la confirmacin. De modo que se trata de un hbrido entre los dilogos 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 el browser, y el servidor en este caso es el Servidor Web que ejecuta la aplicacin. Si bien la naturaleza de internet no posibilitaba la validacin a nivel del cliente (es decir, enviar partes de la lgica de las transacciones al browser), con el advenimiento de Ajax1, un conjunto de tecnologas existentes operando juntas, esto ahora es posible.
1

-----------------------------------------------------------------------------------------------------------------Puede encontrar un artculo interesante Ajax: A New Approach to Web Applications en http://www.adaptivepath.com/publications/essays/archives/000385.php

107

Dilogo con Validacin a nivel del cliente (Client Side Validation)

En su base es full screen, con algunas validaciones en el cliente que le permiten incrementar la interaccin 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 frmulas en la medida que el usuario va ingresando datos en la pantalla. Estas acciones se repiten cuando se confirma. (valor predeterminado) No: Todas las validaciones y disparo de reglas y frmulas se realizan cuando se confirma.

Propiedad a nivel de modelo y de objeto

Mientras que para aplicaciones .Net y Java con interfaz Web siempre se trabajar con dilogo con validacin a nivel del cliente (WCSV: Web Client Side Validation) posible solo gracias a la irrupcin del conjunto de tecnologas conocido como Ajax en el mundo de Internet, para el caso de las mismas aplicaciones para interfaz Win existe la posibilidad de configurar una propiedad de nombre Client Side Validation, para poder, si as se desea, trabajar con el dilogo base, exclusivamente a pantalla completa. Interfaz Win Cuando se trabaja con generadores .Net o Java y ambiente Windows, la validacin a nivel del cliente ofrece una alternativa al dilogo a pantalla completa para proveer mayor interaccin 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 la pantalla y/o ingresando informacin en ellos, se irn validando los datos, infiriendo los atributos de la tabla extendida, y disparndose las reglas y frmulas definidas. Todas estas operaciones se ejecutarn en forma interactiva para que el usuario final pueda ir viendo resultados. De todas formas, las caractersticas del dilogo a pantalla completa se mantendrn, en el sentido de que cuando el usuario final confirme los datos, se grabarn los de la pantalla completa (disparndose previamente todas las validaciones y acciones, esta vez en el servidor). Este es el valor por defecto. -No: Indica que el dilogo a pantalla completa ser puro, es decir, sin el agregado de las validaciones en forma interactiva. La propiedad Client Side Validation se encuentra disponible tanto a nivel de modelo como a nivel de objeto. Esto significa que el valor que se configure en la propiedad a nivel del modelo determinar el comportamiento de todas las transacciones, a excepcin de aquellas que tengan configurado el valor contrario 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 del Wizard de creacin de dicho modelo contiene un combo titulado Client Side Validation que ofrece los dos valores posibles: Yes o No. De esta manera el analista ya puede determinar si desea que su aplicacin tenga un dilogo a pantalla completa (propiedad CSV = No) o si por el contrario, desea incrementar la interactividad de las transacciones, con validacin a nivel del cliente (propiedad CSV = Yes). Tambin se puede configurar esta propiedad a nivel del modelo ms tarde (editando las propiedades del modelo), as como a nivel de objeto si se desea que ciertas transacciones tengan el comportamiento contrario al configurado para el modelo.

108

Dilogo con Validacin a nivel del cliente

(Client Side Validation)

En la medida que el usuario final va ingresando informacin en la pantalla, se van validando los datos, realizando las inferencias, y disparndose las reglas y frmulas definidas. Procesamiento de datos (grabaciones) a pantalla completa Inferencia de modo:

WIN:

CSV=No CSV=Yes

Hay botn get / no se infiere el modo No hay botn get / se infiere el modo

WEB:

Hay botn get / no se infiere el modo

Resumen sobre dilogo a pantalla completa con validacin a nivel del cliente: Mientras el usuario va trabajando con la pantalla, ingresando datos en los distintos campos y abandonndolos, se irn realizando validaciones de los mismos, controles de IR e inferencias de la tabla extendida, as como disparo de reglas y frmulas que involucren a esos atributos que se abandonan. Esto le brindar al usuario la idea de una alta interaccin. Luego, cuando el usuario termina de trabajar con la instancia de cabezal y lneas, confirma presionando el botn de confirmacin, y all se realiza el procesamiento de datos a pantalla completa. Aqu vuelven a validarse los datos, a dispararse los controles de IR e inferencias, junto con las reglas y frmulas, adems de realizarse las grabaciones de todos los registros correspondientes (cabezal y lneas). Todo esto se realiza en el servidor, como si nada hubiese ocurrido en el cliente (tiene que ver con aspectos de seguridad, dado que si no vuelven a realizarse las validaciones luego en el servidor, podra haberse colado algo en el camino al servidor que burle la seguridad).

109

Dilogo a pantalla completa

Propiedad: Confirmation
Se cuenta tambin con la propiedad Confirmation, til fundamentalmente en dilogo a pantalla completa. Posibilita trabajar con o sin confirmacin explcita del usuario:
Con confirmacin: validacin en 2 pasos (grabacin en el ltimo). WIN: cambia texto del botn, confirm en el 2do. paso WEB: no cambia texto, confirm se muestra
en el 2do. paso en el Error Viewer

Sin confirmacin: se valida y graba en 1 solo paso

En Win: no hay botn Confirm, solo Insert o Update, dependiendo del modo. En Web: no hay mensaje de confirmacin en el Error Viewer

La propiedad Confirmation se encuentra disponible tanto a nivel de modelo como a nivel de objeto. Esto significa que el valor configurado en la propiedad a nivel de modelo determinar el comportamiento de todos los objetos del modelo, a excepcin de aquellos que tengan configurado otro valor en forma particular en su propiedad 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 solicite confirmacin al usuario para hacerlo. para reportes y procedimientos: si se desea o no, que antes de que se comience a ejecutar el proceso, se le solicite al usuario confirmacin para hacerlo. Los valores que admite esta propiedad son: Always prompt: Si se selecciona este valor, se le solicitar confirmacin al usuario. Never prompt: Si se selecciona este valor, no se le solicitar confirmacin al usuario. Do not prompt on first level: Este valor se ofrece nicamente para los generadores Visual Basic y Visual Fox Pro, y aplica solamente a transacciones. Si se selecciona el mismo, se le solicitar confirmacin al usuario antes de que se graben los datos en cada nivel de la transaccin, a excepcin del primero. El trabajo con confirmacin reviste relevancia fundamentalmente en el caso en que se trabaje con dilogo a pantalla completa (sin validaciones del lado del cliente), pues como dijimos, es en ese tipo de dilogo en el que el usuario no tiene una respuesta interactiva por parte del sistema respecto a los datos que acaba de ingresar y requiere de una primera confirmacin para obtener alguna respuesta. Por ejemplo, puede haber ingresado un valor que no era el que deseaba para una clave fornea que corresponde al pas del cliente (suponiendo que no disfraza los valores del atributo y trabaja directamente con los cdigos1), y en ese caso como las inferencias no se realizarn interactivamente, puede querer realizar una confirmacin en dos pasos, de modo tal que en el primero se le muestren los datos inferidos y as ya sabr que el pas que digit era el deseado. En caso que no lo fuera, podr modificarlo antes de que la informacin sea efectivamente grabada en la base de datos (cosa que se lograr recin en el 2do. paso). Para interfaz Web (que trabaja con CSV) as como para Win con validacin a nivel del cliente, no resulta necesario este tipo de comportamiento, ya que las inferencias y validaciones se van disparando interactivamente a medida que el usuario va trabajando con la interfaz. Si igualmente se utiliza Confirmacin, las validaciones, controles de IR e inferencias, las reglas que no dependen de las grabaciones de los registros, y disparo de frmulas se ejecutarn tres veces (una en el primer paso de la confirmacin (en el cliente), segunda vez en el 2do. paso de la confirmacin (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 cdigos dentro del tema Integridad Referencial en este manual.

110

Transacciones en tiempo de ejecucin

WIN

eliminacin de lneas (tecla Supr)

Cmo trabaja el usuario final en ejecucin con las transacciones? En el ejemplo de arriba la transaccin Invoice se est ejecutando en un ambiente GUI-Windows, y .Net con validacin a nivel del cliente. Por tanto, ni bien el usuario ingresa un valor para el atributo que es PK y abandona el campo, se infiere el modo (ser Insert en caso en que no exista factura con ese identificador en la tabla, u Update en caso contrario). Update En caso de existir registro con ese identificador, se edita en los campos del form, as como se recuperan tambin las lneas 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 de lneas), para los atributos para los que esto est permitido (los que no sean read only), insertar nuevas lneas en el grid, as como eliminar alguna lnea existente (posicionndose en la lnea y presionando la tecla DEL-Suprimir del teclado). Luego de efectuadas todas las modificaciones (de datos preexistentes, insercin de nuevas lneas o marcado para la eliminacin de lneas mediante la tecla DEL), se presiona el botn de Confirm1 para aplicar los cambios. En cambio, si lo que se desea es eliminar la factura entera, en ese y solo ese caso se presiona el botn Delete. Insert En caso de no existir registro en la tabla INVOICE con el valor ingresado por el usuario en la PK, entonces los campos del form estarn vacos esperando ser ingresados por el usuario. El botn de confirmacin dir Insert. El grid no contendr lneas ingresadas. El usuario ingresar por tanto los datos para el cabezal y las lneas, pudiendo arrepentirse de una lnea que ingres previamente y borrarla utilizando el mismo procedimiento indicado antes (tecla DEL-Suprimir del teclado sobre la lnea). Obsrvese que en este caso no tendr sentido presionar el botn Delete, dado que los registros aun no existen en la base de datos, por lo que no hay nada que borrar. Simplemente cerrando la transaccin, o pasando a editar otro registro, lo digitado por el usuario en la pantalla se perder sin grabarse. Luego de ingresados sus datos, el usuario confirmar la pantalla mediante el botn Insert (teniendo luego que reconfirmar si se trabaja con confirmacin; botn Confirm). --------------------------------------------------------------------------------------------------------1 Si se trabaja con confirmacin el botn dir Update en primera instancia y luego Confirm. Si se trabaja sin confirmacin, solo dir Update.

111

Transacciones en tiempo de ejecucin

WEB

eliminacin de lneas (&GxRemove)

Para la misma transaccin, generada en ambiente Web la historia es muy similar. Existen algunas pequeas diferencias, no obstante. Mientras que en ambiente Win contamos con el control Grid que muestra la cantidad de lneas por pantalla que determine el analista cuando disea el form de la transaccin, permite sin embargo el desplazamiento vertical (barra de scroll), permitiendo entonces ingresar tantas lneas como se desee, con tan solo hacer scroll cuando se han ingresado todas las lneas de la pantalla. En Web, sin embargo, al no contar con esta facilidad, siempre se mostrar un nmero de lneas vacas fijas para ser ingresadas por el usuario (valor configurable por el analista a nivel del grid, en su propiedad Rows). Por defecto se muestran 5 lneas vacas. Si el usuario ingres las 5 lneas y necesita ingresar ms, le bastar con presionar Apply Changes y 5 lneas vacas ms se adicionarn al formulario (si se trabaja con confirmacin, esto dar la oportunidad de agregar las lneas sin ingresar todo lo anterior en la base de datos). Otra diferencia respecto al tratamiento de las lneas con respecto a Win es que en el grid del form Web se incorpora automticamente una primera columna conformada una variable del sistema de nombre &GxRemove, en la forma de check box. Como lo indica su nombre, se utiliza para permitir al usuario en ejecucin marcar varias lneas para ser eliminadas. Lo que en Win se realizaba mediante la tecla DEL, aqu se realiza marcando el check box de la lnea que quiere eliminarse. Cuando se ingresa en la transaccin en modo Insert, el check box no aparecer en el grid, dado que no existe ninguna lnea an ingresada, que pueda ser por tanto eliminada. Al aplicar los cambios (Apply Changes) esta primera columna aparecer para las lneas ingresadas en el form. Por lo dems, el modo de operacin (cmo insertar, modificar, o eliminar registros) es anlogo al de Win.

112

Algunos elementos ms de las transacciones

Propiedades Documentacin Ayuda
Ayuda Documentacin Propiedades

Propiedades Las propiedades asociadas a un objeto en este caso nos referimos a una transaccin, pero vale en general, independientemente de cul objeto se trate- permiten definir ciertos detalles referentes al comportamiento general del objeto. Para ingresar al dilogo 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 botn de la barra de herramientas Fast Access que sealizamos en la transparencia. Sin tener el objeto abierto, es posible editar sus propiedades haciendo botn derecho sobre el nombre del objeto, y seleccionando el tem Properties del men contextual. Mediante cualquiera de los caminos anteriores, se abre un dilogo que ofrece las propiedades asociadas al objeto activo, y donde el analista podr especificar sus valores, definiendo as detalles referentes al comportamiento del objeto. Por ejemplo, la propiedad Confirmation de la que hablamos antes, as como la propiedad Client Side Validation aparecen en este dilogo en caso de estar trabajando en un modelo .Net o Java Win, dado que como dijimos oportunamente, pueden configurarse a nivel de objeto. La propiedad Confirmation tambin aparecer en este dilogo si el modelo es .Net o Java Web; no as la otra. Asimismo dentro de la seccin Web Transaction properties del dilogo de configuracin de propiedades, se encontrar la propiedad Theme para asociarle un objeto tema a la transaccin. Cada modelo, dependiendo de su configuracin (lenguaje, interfaz, etc.), tendr algunas propiedades u otras para configurar. A lo largo del curso iremos viendo algunas de estas propiedades. Para profundizar en el manejo de alguna propiedad en particular, recomendamos acceder al Help de GeneXus.

113

Documentacin Los objetos GeneXus ofrecen una seccin para que el analista pueda incluir documentacin tcnica acerca del objeto. Para ingresar a la seccin de documentacin de un objeto, teniendo al objeto abierto, se deber seleccionar la solapa Documentation, o el tem Object / Documentation de la barra de men de GeneXus. Tambin el botn de la barra de herramientas Fast Access que sealizamos en la transparencia, conducir a la seccin de documentacin del objeto activo. Se abrir un editor html para que el analista ingrese la documentacin tcnica correspondiente. Ayuda Los objetos GeneXus tienen una seccin especfica para poder escribir la Ayuda para el usuario final en el uso del objeto. Para ingresar a la seccin 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. Tambin el botn de la barra de herramientas Fast Access que sealizamos 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 de especificar y generar las aplicaciones, se deber generar el Help. Para ello se deber seleccionar el tem Build / Generate Help. Al seleccionar el tem Build / Generate Help, se desplegar una pantalla para elegir entre dos formatos: CHM y WEB. Tambin 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 ayuda generada 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 ejecucin se abrir un browser con el texto 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 Visual Studio, pero no se instala automticamente, 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 que se crear un archivo con extensin HTML por cada objeto/atributo/variable que tenga ayuda. Si el formato elegido es CHM, se crear adems un archivo de nombre APPHLP.CHM en el directorio del modelo, y un archivo de definicin de proyecto (de extensin HHP) que ser utilizado por el compilador de Help, para la generacin del CHM. El funcionamiento en ejecucin ser el siguiente: Cuando el usuario final seleccione el botn de Ayuda de la transaccin: 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 ese atributo no tiene definido texto de ayuda, se desplegar la ayuda del objeto. ------------------------------------------------------------------------------------------------------------------------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 aplicacin. Es decir, la posibilidad de tener un texto de Help para cada idioma posible. As deber seleccionarse aqu cul de esos textos de help (el correspondiente a qu lenguaje) deber tomarse para generar el help.
1

114