Anda di halaman 1dari 444

Curso Desarrollo de aplicaciones para

Internet
con GeneXus

Versión 9.0
Enero 2007

www.genexus.com/training

Curso No presencial “Desarrollo de aplicaciones para Internet con


GeneXus”

Bienvenido al curso “Desarrollo de aplicaciones para Internet con GeneXus”

Este curso - actualizado a la versión GeneXus 9.0 - lo va a capacitar en el desarrollo de aplicaciones


para Internet utilizando los objetos web GeneXus.

Para poder realizar el curso debe contar con la versión 9.0 de GeneXus. El curso consta de los
conceptos teóricos necesarios para el desarrollo de una aplicación web, así como la puesta en
práctica de los mismos en una aplicación ejemplo. El desarrollo de esta aplicación podrá ser
visualizado paso a paso a lo largo del curso mediante videos incluidos en el mismo. La idea es que
Ud. vaya realizando esta aplicación en paralelo (a medida que avanza capítulo por capítulo en forma
ordenada).
En caso de estar interesado en consultar a un docente del curso las dudas que le vayan surgiendo,
y/o dar un examen final de forma tal de obtener (en caso de aprobación) un certificado de haberlo
realizado en modalidad no presencial, diríjase a nuestro sitio de capacitación a distancia:

http://www.gxtechnical.com/capacitacionadistancia donde podrá informarse y contratar estos


servicios.

INTRODUCCIÓN

En este capítulo intentamos ofrecer una orientación básica sobre el curso y su logística.

Incluye información acerca de la estructura del curso, cómo navegar a través del mismo, cómo
comunicarse con un instructor y cómo obtener información de interés para el correcto desarrollo del
mismo.

Metas y objetivos

Este curso lo va a capacitar en el desarrollo de aplicaciones para Internet utilizando GeneXus 9.0.

El curso está dividido en capítulos, cada uno de los cuáles tiene una introducción que establece los
temas que serán abordados dentro del mismo y en algunos casos sugerencias acerca de cómo leerlo.
Para facilitar el aprendizaje, los conceptos teóricos van acompañados de ejemplos prácticos y de
videos demostrativos, que complementan lo explicado, de manera tal que el alumno pueda obtener
una profunda comprensión de los temas tratados.
A medida que se avanza en los capítulos se va desarrollando una aplicación bien simple que pone en
práctica los conceptos más importantes que se van estudiando y que permite que el alumno pueda
comenzar a interactuar con la herramienta reproduciendo lo realizado en los videos primeramente,
y realizando los ejercicios prácticos propuestos, luego.

Al finalizar el curso Ud. será capaz de desarrollar aplicaciones para Internet de la vida real utilizando
la metodología GeneXus y haciendo uso de la potencia que ofrece la herramienta.

Asimismo este material podrá ser utilizado como manual de consulta en una etapa posterior, de
manera de poder refrescar algún tema en particular, o profundizar en detalles no considerados en
una primera instancia.

Los primeros ocho capítulos constituyen el corazón del curso, y deben ser seguidos con
detenimiento. Estos capítulos transmiten la esencia del desarrollo de aplicaciones para Internet con
GeneXus. Los demás capítulos tienen distintos grados de importancia, pero podrían ser
eventualmente omitidos en una primera lectura si lo que se busca es comenzar rápidamente a
desarrollar este tipo de aplicaciones.

Cualquier sugerencia que desee realizar, con gusto la recibiremos en la siguiente dirección de correo
electrónico training@genexus.com.

Prerrequisitos

Existen dos requisitos fundamentales que es necesario satisfacer antes de comenzar este curso. Ellos
son tener conocimientos de GeneXus (preferentemente la versión 9.0) y conocimientos de Internet.

El primero de los requisitos es excluyente: el curso está dirigido a personas con conocimientos de
GeneXus que hayan desarrollado aplicaciones con la herramienta. De no contar con estos
conocimientos, la dificultad para alcanzar un nivel de comprensión aceptable será importante.

Las diferencias inherentes a las versiones de GeneXus pueden dificultar también la comprensión del
curso por lo que se recomienda realizar una actualización previa a la versión 9.0.

El segundo de los requisitos, si bien no es excluyente, debe alcanzarse antes de comenzar el curso.
Para ello se incluye un capítulo como anexo, de Introducción a Internet que establece la
terminología y conceptos necesarios para entender este ambiente. Quién no cuente con dichos
conocimientos, deberá comenzar por ese capítulo y no continuar hasta no haber asimilado todos los
conceptos allí vertidos.

Requerimientos computacionales

Debe contar con GeneXus versión 9.0 full. En el presente curso desarrollaremos una aplicación de
ejemplo generando para una plataforma .NET, utilizando como DBMS (DataBase Management
System) el SQL Server 2005 Express Edition.

Está disponible en nuestro sitio todo el software necesario para poder desarrollar la aplicación de
entrenamiento en la plataforma mencionada. No obstante ello, si Ud. cuenta con otra plataforma de
desarrollo de las soportadas por GeneXus y desea realizar la parte práctica del curso utilizándola en
lugar de la que ofrecemos, puede hacerlo. Deberá tener en cuenta que en tal caso pueden haber
diferencias con lo que verá en los videos, pues cada plataforma tiene características propias, y
habrán configuraciones particulares que deberá realizar de forma distinta a la mostrada.

En el manual de instalación de GeneXus 9.0 encontrará los requerimientos de hardware y software


para generar en todas las plataformas soportadas por GeneXus. Por tanto, si Ud. no desea
desarrollar la aplicación de ejemplo del curso en .NET, pues cuenta con otro generador, podrá
referirse a este manual para obtener los requerimientos computacionales particulares a su caso.

El manual de instalación se encuentra disponible para ser bajado de nuestro Download Center:

http://www2.gxtechnical.com/portal/hgxpp001.aspx?15,8,77,O,S,0,,1924;4;4;;/%20%20/;/%20%20/;
M

A continuación se presenta una lista del hardware y software necesario para ejecutar GeneXus y las
aplicaciones generadas en una plataforma .NET contra SQL Server 2005 Express Edition:

Hardware Requirements Procesador: 500 MHz Intel Pentium class

Memoria: al menos 128 MB de RAM (recomendada 512 MB)


Disco duro: al menos 50 MB de espacio libre en disco para
instalar el Development Environment más 10 MB para el
generador. Para generar aplicaciones GeneXus necesitará
espacio adicional o una unidad de disco compartida para
crear las bases de conocimiento.

Video: resolución 800x600 o mayor, con 256 colores

Software Requirements Microsoft Windows con tecnología NT; Microsoft Windows


2000 o superior.

Si Ud. está utilizando Windows NT, debe instalar el service


pack 6a o superior.

Microsoft .NET Framework 1.1 o 2.0 Redistributable Package


1

Microsoft Visual J# Distribution Package 2

Microsoft SQL Server 2005 Express Edition 3

ADO.NET

Microsoft Internet Explorer 6.0 SP1 o superior 4

1
El .NET Framework 1.1 Redistributable Package puede ser bajado del sitio web de Microsoft:

http://msdn.microsoft.com/netframework/downloads/framework1_1redist/

2
El Visual J# Distribution Package 1.1 puede ser bajado del sitio web de Microsoft:

http://msdn.microsoft.com/vjsharp/downloads/howtoget/default.aspx

3
Se recomienda tener instalado el "Microsoft SQL Server Management Studio Express", el cual
puede ser bajado del sitio web de Microsoft:

http://www.microsoft.com/downloads/details.aspx?FamilyId=C243A5AE-4BD1-4E3D-94B8-
5A0F62BF7796&DisplayLang=en

4
Puede bajarlo de nuestro Download Center:
http://www.gxtechnical.com/main/hdcenter.aspx?2,5,36,1183

Necesitará contar con algún reproductor de archivos multimedia para poder ver los videos incluidos
en el curso, que son archivos de extensión AVI.

El video debe reproducirse con el mismo tamaño del original (size 100%) pues de lo contrario la
imagen puede degradarse y no verse con nitidez.

Asimismo, antes de reproducir la primera de las demos, deberá haber ejecutado en su máquina el
archivo TSCC.EXE que viene junto con el curso. TSCC es el codificador que se utilizó al producir los
videos de este curso, para compactar los videos sin perder calidad de imagen. Debe estar instalado
en toda máquina en la que se vayan a visualizar los videos del curso.

En el documento Problemas con la reproducción de los videos tiene la solución a algunos de los
problemas que se le podrían presentar al intentar reproducir los videos incluidos en el curso. Allí se
indica también de dónde se pueden bajar reproductores en forma gratuita.

Recomendamos una resolución de pantalla de 800x600, para poder ver los videos correctamente.

Comunicación con un docente y examen final

En caso de estar interesado en contar con la ayuda de un docente a quien se le podrán


consultar las dudas que vayan surgiendo, y dar un examen final de forma tal de obtener, en
caso de aprobación, un certificado de haberlo realizado en modalidad no presencial, diríjase a
nuestro sitio de capacitación a distancia: http://www.gxtechnical.com/capacitacionadistancia
donde podrá contratar estos servicios e informarse acerca de los mismos.

Cómo utilizar este curso

Elaboramos este curso intentando por un lado no aburrir al alumno con detalles innecesarios en una
primera lectura, pero por otro brindando información completa de los temas tratados.

Una forma de alcanzar estos objetivos sería postergar la complejidad y/o los detalles para capítulos
más avanzados dentro del curso. Si bien de esta manera lograríamos los dos objetivos anteriores, un
mismo tema estaría desperdigado en muchos capítulos, dificultando así una consulta posterior.

Con la intención de que el material sea utilizado tanto en la etapa de aprendizaje como en una
etapa de consulta posterior -a modo de libro de referencia- aparece pues un tercer objetivo: que los
temas estén tan auto-contenidos como sea posible, de modo de facilitar la consulta posterior.
En la mayoría de los casos estos objetivos se tornan contrapuestos, por lo que buscamos una
solución de equilibrio.

Intentamos dejar los temas lo más encapsulados posible en capítulos, sin perder de vista los
aspectos didácticos. Para ello, establecimos una simbología que incluimos en los documentos para
orientar visualmente al lector discriminando qué partes de la documentación pueden excluirse en
una primera lectura, qué partes son de fundamental importancia y deben convocar toda su
atención, etc. Asimismo establecimos una simbología análoga a nivel del índice –árbol- del curso. En
las tablas que aparecen al final de esta página listamos estos símbolos y sus significados.

Es así que el curso se divide en capítulos, cada uno de los cuales contiene una introducción que
resume los puntos que se tratarán dentro del mismo, brindando sugerencias al lector acerca de
cómo leerlo. Los capítulos contienen documentos de distintos tipos, así como subcapítulos.

Este curso está pensado para ser seguido fundamentalmente de manera secuencial. Algunas veces
se podrán producir desviaciones a ese orden, tanto por decisión del lector, como por alguna
sugerencia explícita dentro del curso. Normalmente se comienza con la introducción de un capítulo,
y luego se pasa a leer el documento que le sigue en orden dentro del índice.

Si bien los documentos están ordenados de modo de ser leídos secuencialmente, pueden, no obstante,
contener links que los relacionen con otros documentos de otras partes que están más adelante o más atrás
en el curso.
Aconsejamos seguir los links “hacia adelante” solo cuando se está realizando una “referencia posterior”, es
decir, cuando ya se ha dado una primera lectura a todo, y se está consultando un tema específico. La razón
es que el lector ya llegará a esos temas cuando siga secuencialmente con el curso, y de hacerlo en el
momento en que encuentra el link corre el riesgo de perder el foco de lo que estaba estudiando.
Los que son “hacia atrás” sí pueden utilizarse en la primera lectura, pues posibilitan refrescar o
recordar temas, conceptos, ideas, etc. vistos recientemente y aún no suficientemente afianzados.

Del texto que se despliega al pasar el mouse sobre del link se desprenderá claramente el tipo del link
-si es “hacia adelante” o “hacia atrás”.

Lea las tablas de símbolos que figuran a continuación para entender el significado de los símbolos
que aparecerán a lo largo de todo el curso.

Tabla de símbolos de los documentos

Símbolo Significado

Denota que lo que se encuentra en esa sección es de fundamental importancia


y debe prestarse especial atención a lo que allí se dice. Generalmente se trata
de conceptos de gran relevancia. Si el símbolo se encuentra al principio del
documento, aplica a todo el documento. Si por el contrario aparece delimitado
por líneas, aplica solo a lo delimitado por ellas.

Es una referencia a un “pie de página”. Se incorpora en la mitad de un texto


para establecer un link a dicho pie de página.

Representa una nota en alguna parte del documento.

Sugerimos tener GeneXus abierto mientras se está siguiendo el curso, de manera tal de poder ir
viendo en la herramienta los elementos que se van mencionando e ir probando en la aplicación de
ejemplo.

Desarrollo de una aplicación

Como el propósito de este curso es que el alumno pueda desarrollar aplicaciones de la vida real para
Internet utilizando GeneXus, elegimos una aplicación de ejemplo bien simple para ir poniendo en
práctica a lo largo del curso los conceptos que se vayan incorporando.

En el Capítulo 2 se presenta el primer paso en el desarrollo de la aplicación, que irá creciendo a lo


largo de los capítulos subsiguientes de forma tal de ir incorporando los nuevos elementos que vayan
apareciendo.

El desarrollo se presenta mediante videos demostrativos que el alumno deberá observar


primeramente, para luego intentar reproducir. A menos que se indique lo contrario, a continuación
de un video demostrativo el alumno deberá reproducir lo visto.

En algunas ocasiones se le indicará explícitamente al alumno luego de un video alguna variante al


mismo, para que no lo repita exactamente, sino con alguna modificación.

La aplicación que hemos elegido es una simplificación de una aplicación real: un sistema para una
agencia de viajes que permite la búsqueda de pasajes y servicios turísticos.
A grandes rasgos: la agencia contará con un sitio en Internet donde permitirá a los clientes realizar
búsquedas de destinos, los vuelos existentes y los diferentes servicios brindados. Incluirá también
todo el back-end para el mantenimiento de la información relacionada.

Convenciones para la documentación

En los documentos de este curso se utilizan algunas convenciones tipográficas:

 Todos los nombres de atributos y variables aparecerán en cursiva.


 Los nombres de objetos GeneXus aparecerán entrecomillados, con la primer letra en mayúscula y el
resto en minúscula.
 Los nombres de tablas aparecerán sin comillas y en mayúscula.
 Los nombres de índices estarán también sin comillas y en mayúscula.

Utilizamos las convenciones de sintaxis de los comandos, reglas, eventos, etc. del lenguaje que se utilizan en
el Help de GeneXus, por lo que recomendamos leer el documento “Syntax Conventions” del Help.

Algunos links de interés

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

Puede ser consultada online o puede ser utilizada en forma local mediante una sencilla instalación.

http://www.gxtechnical.com/gxdl

Podrá crearse un usuario en nuestro sitio web GxTechnical, http://www.gxtechnical.com, y bajar del
Download Center todo el material permitido según el nivel de su usuario. En el Download Center
encontrará productos, cursos, ejemplos, manuales, release notes, GXDL, utilitarios, technical papers,
etc.

Temas que no serán abordados en este curso

A continuación mencionaremos los temas que están relacionados con el curso para que el lector
pueda recurrir a la GXDL en caso de tener interés en abordarlos por su cuenta.

Ellos son:
 Introducción a “Business Intelligence” (Data Warehousing)

 “GXFlow” (Aplicaciones de workflow)

Problemas con la reproducción de los videos

Los videos son archivos con extensión .avi. Debe configurar su máquina para que los abra siempre
con el reproductor con el que cuente.

¿Por qué mis videos no se ven?

Los videos que se utilizan en este curso son producidos utilizando un codificador, TSCC, que permite
comprimir los archivos sin degradar la calidad de la imagen. Este codificador debe estar instalado en
toda máquina en la que se vayan a visualizar los videos.

El archivo TSCC.EXE que incluimos junto con el curso, debe ser ejecutado en su sistema de manera
de instalar el codificador TSCC en su máquina. Esta acción solo debe realizarse una vez.

Para Windows NT/2000/XP los usuarios deben tener permisos de administrador para realizar la
instalación.

También puede ser descargado del sitio web:

http://www.techsmith.com/download/studiodefault.asp

Si aún así no se ven, pruebe utilizar el Media Player en modo v6.4.

¿Por qué mis videos se ven borrosos?

Si se escala el video en la aplicación que lo está reproduciendo el video se verá borroso. Los videos
deben reproducirse con su tamaño original, sin ser escalados.

Problemas con la reproducción con Media Player

Si el video se está reproduciendo en Media Player 7, 8 o 9 y ud. no logra ver la imagen nítidamente,
el problema probablemente sea de que el video no se está reproduciendo al 100% del tamaño
original. Es un problema que tienen estas versiones del Media Player en sus “skins” mode
predeterminados. Por defecto escalan los videos durante la reproducción a un tamaño menor,
dando como resultado la degradación de la calidad de la imagen. Muchas veces el seleccionar
View/Video Size/100% no tiene el menor efecto.

La solución es configurar el Media Player para que no escale las imágenes. Hay varias formas de
hacerlo:

1. Configurar Media Player para que utilice “Classic skin”. Presionar el botón “Skin Chooser” y
seleccionar “Classic”.

2. Correr el player en “Compact mode”. En Media Player seleccionar View/Skin Mode.

3. Correr Media Player en modo 6.4.

Uso de Media Player 9 en modo v6.4

1. Localizar y ejecutar el archivo MPLAYER2.EXE que está ubicado en Program Files/Windows


Media Player. Esto correrá MP9 en modo v6.4.

2. Cuando v6.4 está corriendo seleccionar View/Options/Formats, presionar Select


All/Apply/OK. Esto configurará las asociaciones del shell de Windows para usar Media Player
6.4 cuando se hace doble clic sobre un video en Windows Explorer, o en otras aplicaciones
que usan las asociaciones del shell de Windows para ejecutar un reproductor.

3. Seleccionar View/Options/Playback y configurar el nivel de Zoom en 100%

Si desea utilizar v6.4 puede bajarlo de:

http://www.microsoft.com/windows/windowsmedia/en/download/default.asp

Otra opción es utilizar el TechSmith Camtasia AVI Player, que puede bajarse libremente de:

http://www.techsmith.com/products/studio/player.asp. En este caso no habrán problemas de


escalado.
INTRODUCCIÓN

En este capítulo comenzaremos a introducirnos en el desarrollo de aplicaciones Web con GeneXus.

Veremos la arquitectura en general de estas aplicaciones y las alternativas disponibles en GeneXus.

Crearemos una base de conocimiento para implementar una aplicación para una agencia de viajes
que iremos desarrollando gradualmente a lo largo del curso.

Además, entraremos a GeneXus para dar los primeros pasos en el desarrollo de una aplicación Web
y comenzaremos a trabajar con el editor GeneXus para estos objetos.

Veremos las barras de herramientas.

Arquitectura de las aplicaciones Web

En la imagen que mostramos a continuación se puede observar un esquema simplificado de la


topología de Internet.

Por un lado se tiene la red de la empresa (Intranet), donde se tiene un Servidor Web en el cual se
publican las páginas Web.

Este servidor puede ser también el servidor de base de datos, o se puede tener un servidor
específico para realizar esta tarea.

Los usuarios de Internet tendrán acceso a las páginas que sean públicas y podrán acceder a los datos
almacenados en la empresa a través de páginas dinámicas.

Por otro lado, los usuarios de la empresa (Intranet) podrán acceder a las páginas públicas y a las
páginas privadas de la empresa.
Alternativas para el desarrollo de aplicaciones Web con GeneXus

Java y .NET son los generadores disponibles en GeneXus para desarrollar aplicaciones Web.

Las aplicaciones podrán ejecutar con un servidor Web Windows, UNIX o ISeries y podrán usar
cualquier manejador de base de datos, dentro de las plataformas soportadas por cada uno de los
generadores GeneXus.

Dependiendo del sistema operativo del servidor de Base de Datos y del servidor Web a utilizar, es el
generador GeneXus que puede seleccionarse. En varias plataformas se plantean varias alternativas.
La decisión del generador a utilizar se tomará principalmente por los requerimientos adicionales o
interacciones con otras aplicaciones, ya que el ‘look and feel’ de la aplicación será el mismo
independientemente del generador que se utilice.
Servidor de Base de datos Servidor Web Generador .NET Generador Java

Windows Windows SI SI

Windows Unix NO SI

Unix Windows SI SI

Unix Unix NO SI

ISeries Windows SI SI

ISeries ISeries NO NO

Desarrollo de Aplicaciones Web con GeneXus

Como es sabido, la primera tarea cuando se comienza a desarrollar una aplicación con GeneXus es
crear la base de conocimiento que representará e implementará al sistema. Lo mismo ocurre
cuando la aplicación a desarrollar es Web.

Puede ocurrir, que la base de conocimiento ya exista (por ejemplo con interfaz Win) y lo que deba
crearse en ese caso es solamente un nuevo modelo en esa base de conocimiento.

Puede ocurrir también, que se quiera agregar en un modelo existente algunos objetos Web. En ese
caso, deberá definirse solamente un ambiente Web.

Lo importante es que la interfase elegida (en File / Edit Model / Environment / User Interface) sea
Web form. De esta manera se podrán definir en GeneXus los objetos para desarrollar aplicaciones
Web (Web Panels y Transacciones Web).

En modelos de Prototipo o Producción con ambiente Web, el tipo de objeto que se propone al crear
un nuevo objeto es Web Panel.
Práctico: Creación de una base de conocimiento
1. Entraremos a GeneXus y crearemos una base de conocimiento para comenzar el desarrollo del
sistema para la Agencia de viajes.

Le sugerimos que utilice la versión de GeneXus 9.0 y cree su propia base de conocimiento en el
directorio que estime conveniente. Esta base de conocimiento será la que utilizará a lo largo del curso,
tanto para reproducir las demos, como para hacer los ejercicios prácticos que se vayan indicando.

2. Luego de crear la base de conocimiento, consolide el archivo KBInicialAgency.xpz.

3. En este momento, crearemos un modelo de Prototipo utilizando el generador .NET y la base de


datos SQL Server 2005 Express.

Le sugerimos que utilice el Wizard para la creación del modelo.


Deberá elegir un nombre para el modelo. El nombre elegido en el desarrollo de la aplicación que Ud. verá
en los videos es AgencyNet pero Ud. puede elegir el que desee.
Además, deberá elegir Web como User Interface. También deberá asignar el Language y DBMS que
desee utilizar.
Consulte el documento Propiedades de .NET donde se detallan las principales propiedades que debe
configurar en este modelo.
En caso de querer utilizar el generador Java, recomendamos que consulte el documento Propiedades del
modelo Java para más información.

4. Al realizar el impacto, GeneXus nos informará de las nuevas tablas que creará en la base de datos.
Confirme y ejecute dicha creación.
5. Ahora, está en condiciones de copiar los datos que se encuentran en Agency.bak del cd1.
6. Ahora, deberemos especificar y generar todos los objetos. Para confirmar que todas las propiedades
del modelo quedaron bien configuradas, conviene ejecutar un objeto del modelo.
7. Compile el Developer Menu2 y ejecute por ejemplo la transacción Country.
8. Se recomienda utilizar un directorio virtual específico para el práctico. Por ejemplo:
http://localhost/practico. De esta forma estamos definiendo un directorio virtual específico para
nuestra aplicación y evitando tener un único directorio virtual para distintas bases de conocimiento
activas.

Se entiende que el alumno cuenta con conocimientos en GeneXus por lo cual los pasos aquí descriptos
son sencillos y no requieren del apoyo de un video para llevarlos a cabo.

1
El archivo Agency.bak, es un Back up de la base de datos. Para poder copiar los datos deberá realizar un
Restore de la base de datos Agency.
2
El Developer Menu implementado para aplicaciones Web, al ejecutarlo desde el menú de GeneXus
Build/Run (F5), abrirá una página en el navegador: <VirtualDirectory>/execute.xml. La misma
tiene links a todos los objetos Web, estos son: Web Panels, Transacciones con Web form, Procedimientos con
call protocol = http y Reportes con call protocol = http.
Editor de Objetos Web

Para editar los objetos Web se cuenta con un editor “WYSIWYG” (What you see is what you get)
similar al Front Page de Microsoft, que fue diseñado siguiendo el estándar de las herramientas
Microsoft Office, lo que permite que los usuarios puedan utilizarlo rápidamente y en forma intuitiva.

Es un editor orientado a páginas, lo que significa que la posición de los controles que se encuentran
dentro del form en diseño es relativa al tamaño de la ventana que contenga la página.

Este editor provee el manejo de tablas, característica fundamental a la hora de diseñar páginas Web.
Esta facilidad habilita al usuario a diseñar mejores páginas, así como le permite manipular la
alineación de los controles dentro de los objetos Web.

Complementando este editor, existe el Editor de Temas (que veremos más adelante), que permite
configurar de una forma sencilla las propiedades de estos controles (definiendo clases para los
mismos), simplificando así el desarrollo y mantenimiento de las aplicaciones Web.

Podemos clasificar los controles que se pueden utilizar dentro de los objetos Web en dos grupos:

1. Aquellos que pueden ser usados en todos los objetos GeneXus:

 Atributos

 Variables

 Botones

2. Los que son propios de los objetos Web, o tienen un comportamiento diferente que en el resto
de los objetos:

 Imágenes

 Grid

 Texto

 Text Block

 Tabla

 Grid Free Style

 Error viewer
 Web Components

 Embedded Pages

Más adelante se detallan estos tipos de controles.

Para trabajar con objetos Web se dispone de dos barras de herramientas: una habilita las
funcionalidades del editor, mientras que la otra permite la inserción de los controles. A continuación
se documentan las operaciones que se pueden realizar con cada una de ellas, así como las
características de los controles disponibles en objetos Web.

Barra de herramientas Pallete

Para insertar controles en el form del objeto Web se puede utilizar la opción Insert del menú de
GeneXus o la barra de herramientas denominada Pallete.

Select Habilita la selección de uno o más


controles.

Attribute

Text

Hyperlink Inserta un hipervínculo en el Web form. Se


despliega un diálogo, desde el cual se
podrá configurar el hipervínculo.

Line Opción deshabilitada en ambiente Web

Rectangle Opción deshabilitada en ambiente Web

Table

Grid

Free Style Grid

Button
Image Inserta una imagen en el Web form. Se
despliega un diálogo, desde el cual se
selecciona la imagen a insertar.

Tab Control Opción deshabilitada en ambiente Web

Print Block Solo habilitada en objeto Reporte

ActiveX Opción deshabilitada en ambiente Web

Web Component

Embedded Page

Barra de herramientas Formating

Esta barra de herramientas permite realizar las operaciones estándares de edición y formateo de
texto.

Una de las opciones destacables relacionada con objetos Web es , que permite visualizar los
bordes de las tablas cuya propiedad Border esté con valor 0. De esta forma, se pueden ver en diseño
los bordes de las tablas aún cuando éstos no se vean en ejecución.

Otra opción interesante es que facilita el trabajo con controles de tipo Text Block.

Design vs. Source

Cuando se visualiza el form de un objeto Web, se pueden observar varias secciones en el borde
inferior de la pantalla, entre ellas el ‘Web Form’.

Cuando el objeto es una transacción las secciones disponibles son:

Cuando el objeto es un Web panel, las secciones son:


Al hacer clic sobre esta sección se puede diseñar la pantalla del objeto Web, es decir se insertan los
controles y se visualiza el aspecto que va a tener en ejecución el mismo.

Si se presiona el botón derecho del mouse dentro del formulario del objeto Web, además de la
opción Properties (que permite configurar las propiedades del form) se visualizan dos opciones:
‘View Source’ y ‘Edit HTML Source’.

Al seleccionar la opción ‘View Source’ se abre una ventana donde se puede visualizar el código
HTML que se va a generar al ejecutar dicho objeto. Al cerrarla, se vuelve al formulario del objeto
Web.

Si se selecciona la opción ‘Edit HTML Source’, se puede modificar el código HTML o agregar código,
de forma tal que el cambio se mantiene en el objeto y se genera posteriormente. En este caso, el
código se visualiza dentro de la ventana del objeto Web y para volver al formulario, es necesario
volver a presionar el botón derecho del mouse y seleccionar la opción ‘Edit Web Form’.

La opción “Edit HTML Source” se usa para cualquier caso en el que sea necesario agregar código
HTML manualmente, por ejemplo, agregar código javascript (si bien esto se puede hacer de otras
formas). Todo el HTML que se agregue queda entre los Tags <Body></Body> del objeto generado.

Normalmente, se diseña el objeto Web sin requerir editar el código HTML, pero en caso de
necesitarse esta es la forma de hacerlo.

Controles y sus propiedades

En este capítulo iremos viendo los diferentes controles de los objetos Web y las propiedades de cada
uno de ellos.

Es importante resaltar que la asignación de las propiedades puede hacerse directamente en el


control o en una clase de un Tema.
En ambos casos, se asigna el valor a la misma, pero lo que varía es el costo de mantenimiento
posterior.

En el caso de asignar las propiedades directamente en el control, estas solamente aplicarán al


mismo.

Esta asignación puede hacerse en tiempo de diseño y para algunas de las propiedades pueden
modificarse en tiempo de ejecución (programando los eventos del objeto). Cualquier cambio,
requerirá generar y compilar el objeto.

En el caso de asignar las propiedades en la clase de un tema, cualquier cambio de diseño, se


realizará en el Tema, sin necesidad de generar/compilar absolutamente nada.

En este capítulo se verá una introducción al objeto Tema y el Editor de Temas, y más adelante en el
curso, se verá en detalle el funcionamiento de ambos.

Por detalles de la forma de asignar las propiedades de los controles, referirse a: Orden de
precedencia de las propiedades

¿Qué es un Tema?

Un Tema es un objeto GeneXus, mediante el cual se pueden definir clases para los diferentes
controles Web GeneXus, y asignar propiedades a dichas clases.

Una vez asociado un Tema a un objeto (mediante la propiedad “Theme”), los controles de ese objeto
podrán ser asociados a alguna clase del Tema.

Al asociar una clase a un control éste pasa a heredar la configuración de las propiedades dada en la
clase.

Los Web Panels y las Transacciones son los objetos a los que se les puede asignar un Tema.
Cómo asociar un tema a un objeto

Las formas de asociar un tema a los objetos GeneXus son tres: asignarla a nivel de la base de
conocimiento, del modelo o específicamente del objeto. Este es el orden también para la
precedencia: si está asignada a nivel de objeto, se considera ese valor, sino el del modelo y si no está
asignado, el de la base de conocimiento.

Para asociarlo al objeto directamente, se debe configurar la propiedad Theme perteneciente a las
“Object Properties”.

Para asociarlo al modelo, se debe configurar la propiedad “Theme” disponible en el grupo “Web
Information” (File / Edit Model / Properties).

Para asociarlo a la base de conocimiento, se debe configurar la propiedad Theme del modelo de
diseño (File / Edit Model / Properties / Theme)

Este mismo orden de precedencia se utiliza para determinar los valores por defecto de la propiedad
“Theme”: el valor por defecto de la propiedad de un objeto es el valor de la propiedad del modelo y
el del modelo es el valor de la misma propiedad de la base de conocimiento.

La propiedad Theme del modelo, está asociada por defecto al Tema “Default”, por lo cual, por
defecto los objetos de la base de conocimiento están asociados al mismo Tema.

Cómo asociar una clase a un control

La forma de asociar una Clase de un Tema a un control, es a través de la propiedad “Class”. La propiedad
Class es una propiedad del control, y es posible también cambiarla en tiempo de ejecución.

Cómo modificar un tema

Los temas se modifican utilizando un Editor especial, que es de libre distribución y puede ser
ejecutado independientemente de GeneXus. Esto permite a los diseñadores del sitio Web trabajar
en el diseño del sitio en forma independiente al ambiente GeneXus.

En el siguiente documento se describen las Generalidades del Editor de Temas.


Text Block

Los controles ‘Text Block’ pueden ser vistos como texto insertado directamente en el form, con la
ventaja que en forma dinámica (en ejecución) se puede modificar el mismo. Para insertar un Text

Block, se puede presionar el botón de la barra de controles disponibles.

Edición del control Text Block

Los text blocks no pueden ser editados directamente desde el form y tienen que ser modificados
desde las propiedades del Menú contextual (botón derecho, properties).

En la barra de herramientas para el form HTML se incluye un botón que facilita el trabajo con
controles de tipo Text Block. Al presionar el botón mencionado, se visualizan los TAG’s que lo
definen permitiendo detectar cualquier problema en diseño.

Propiedades del control Text Block en diseño

Las propiedades de este tipo de control son:

 Caption
 ControlName
 Class La propiedad Class solo se encuentra disponible si el control está en el form de un objeto
que tiene un Tema asociado.
 Format: El valor por defecto para Text Blocks es Text, y se puede cambiar a través de la
propiedad “Default HTML Format(Textblocks only)” del modelo de diseño.
 Fill
 ForeColor
 Font
 OnClickEvent
 ReturnOnClick

Propiedades del control Text Block en ejecución

Además de las propiedades detalladas anteriormente, se pueden modificar las siguientes


propiedades de los Text Blocks en tiempo de ejecución:

 BackColor
 Visible
 Enabled
 Link
 LinkTarget
 Format

Propiedades del control textblock en los Temas

Además de estas propiedades mencionadas, en la clase Textblock (o alguna clase derivada de ella) de un
Tema, se pueden configurar otras propiedades para los Text blocks. Ver Clase Textblock.

Demo: Creación del primer Web Panel

Comenzaremos creando un Web Panel donde el usuario deberá registrarse. El nombre del objeto
será Login.

En este objeto, le pediremos que ingrese un usuario y una contraseña y validaremos la información
con la base de datos donde se almacenan los usuarios registrados en el sitio.

Para que pueda ingresar un valor para el usuario y la contraseña, definiremos dos variables en el
form.

Para que no se visualice lo que escribe mientras ingresa la contraseña, es decir, que aparezcan
asteriscos, se debe utilizar la propiedad “IsPassword” asociada a las variables.

Si se programa Variable.IsPassword = 0 se puede visualizar lo que el usuario digita sobre la variable.


Si por el contrario, programamos Variable.IsPassword = 1, al ejecutar aparecen asteriscos (*******)
mientras el usuario digita sobre la variable.Definiremos también un botón que tendrá asociado el
evento “Login” donde más adelante se realizará la lógica de validación del usuario.

Vea la demostración aquí


Ahora, especificaremos, generaremos y compilaremos el Developer Menu para poder ejecutarlo.

En ejecución, el Web Panel se verá como lo siguiente:

Si observamos bien el Web Panel, las variables de ingreso de datos no están alineadas.

Para alinear controles (por ejemplo: que todas las variables donde el usuario va a ingresar los datos
queden alineadas a la izquierda), se deben usar Tablas.

Vale la pena destacar que si las dos variables se insertan al mismo tiempo (desde el diálogo
correspondiente) GeneXus automáticamente incluye una tabla para alinear los controles.

En el próximo punto veremos cómo alinear los controles del Web Panel insertándolos dentro de una
tabla.

Pero antes de eso, realicemos algunos cambios en el Tema para verificar los conceptos aprendidos
recientemente.
Demo: Trabajando con Temas

Observe que en la base de conocimiento que Ud. ha creado para realizar los ejercicios prácticos,
existe un Tema de nombre “Default”. Este Tema se crea automáticamente al crear una nueva base
de conocimiento.

Observe también que la propiedad “Theme” del modelo, está asociada por defecto al Tema
“Default”, por lo cual, por defecto los objetos de la base de conocimiento están asociados al mismo
Tema.

Observe lo dicho anteriormente, en el Web Panel creado.

Ahora, modificaremos el Tema “Default”, de forma de ejemplificar como se trabaja con los Temas.

Haremos las siguientes modificaciones

 Darle un valor a la propiedad BorderStyle y ForeColor de la clase Attribute

 A la clase Button, le asignaremos un BackColor y un Height

En la siguiente demostración veremos los pasos seguidos para modificar el Tema “Default” y el
efecto de esos cambios sobre el Web Panel que hemos creado en este capítulo.

Es posible también definir la configuración de los HTML Tags involucrados en el HTML de la Web
Page. En el curso, a medida que se vayan realizando los ejercicios prácticos, se explicarán más
detalles del objeto Tema y su funcionalidad, incluyendo casos de uso de los HTML Tags, y las
ventajas que presenta a la hora de realizar el diseño estético del sitio Web.

Tablas

Cuando se trabaja con objetos web, es necesario utilizar tablas para poder alinear los controles
dentro del formulario para mejorar el diseño de los mismos.
Agregar tabla

Para insertar una tabla se debe utilizar el botón de la barra de controles. Una tabla está
compuesta por filas y celdas, dentro de las que se encuentran los controles.

Propiedades de las tablas

Las propiedades varían dependiendo de la selección realizada, es decir que las propiedades
disponibles para una celda tienen alguna variación con respecto a las disponibles para la tabla o la
fila. A continuación se documentan las propiedades a nivel de tabla, fila y celda.

Para editar las propiedades de una tabla se debe marcar la tabla (el puntero del mouse cambiará al
posicionarse en los bordes de la misma y en la barra de status se indicará el nombre del control
seleccionado) y presionar el botón derecho del mouse. Seleccionar la opción Properties del menú
pop-up que se despliega.

Otra forma de editarlas es presionando el botón derecho del mouse estando posicionado en
cualquier celda de la tabla, y después ir a la sección de Table. En este caso, se podrán editar además
de las propiedades de la tabla, las de la fila a la que pertenezca la celda y las propias de la celda.
 ControlName

 Class
La propiedad Class solo se encuentra disponible si el control está en el form de un objeto
que tiene un Tema asociado.

 Tooltiptext

 Align

 Background

 Backcolor

 BorderWidth: 0 indica que no tendrá borde en ejecución, pero podrá verse en diseño usando el

botón de la barra de herramientas. El valor por defecto es 1.


 BorderColor

 Cellpadding

 Cellspacing

 Height

 Width

 Rules

PROPIEDADES DE LAS FILAS DE UNA TABLA

Como se puede observar en el diálogo de propiedades –sección ROW-, se pueden asignar valores a
propiedades para una fila particular dentro de las tablas. Estos valores tendrán preferencia a los
asignados para la tabla en general.

Las propiedades de las filas, son algunas de las propiedades de las tablas, más una propiedad
adicional: Vertical Align.
 Identifier

 TooltipText

 Align

 Vertical Align

 Backcolor

 BorderColor

PROPIEDADES DE LAS CELDAS DE UNA TABLA


Las propiedades de una celda de una tabla son las que se muestran a continuación:
 Identifier

 Tooltiptext

 Align

 VerticalAlign

 Background

 Backcolor

 Bordercolor

 Height

 Width

 Colspan

 Rowspan

Propiedades de tablas en los Temas

Además de estas propiedades, en la clase Table (o derivadas de ella) de un Tema, se pueden


configurar otras propiedades que permiten definir otras características a las tablas. Ver Clase Table
Demo: Creación de una Tabla

Como decíamos anteriormente, para alinear los controles debemos definir una tabla en el form.

Podríamos definir una nueva tabla de 3 x 2 y arrastrar los controles a la misma.

Podríamos también, seleccionar nuevamente las variables para que GeneXus automáticamente
agregue la tabla con las variables y las descripciones correspondientes.

Luego, debemos posicionar el Mouse en la última celda y con el botón derecho seleccionar la opción
Insert Row para agregar una nueva fila donde incluiremos el botón.

Vea la demostración aquí

Ahora, compruebe en ejecución la alineación de los controles.

Más adelante, veremos más casos prácticos del uso de las tablas.

Demo: Cómo darle un mensaje al usuario

En este momento ya tenemos implementada nuestra pantalla donde el usuario final va a ingresar su
usuario y contraseña.

Tenemos que verificar en el evento Enter del botón “Login” si existe en nuestra tabla de usuarios
(Users) un usuario con dicho Nick Name. Si existe, verificar que la password ingresada sea correcta y
en caso de no existir darle un mensaje al usuario final informándole que se debe registrar como
nuevo usuario.

En un Work Panel normalmente lo haríamos utilizando el comando msg(), y se abriría una nueva
ventana con el mensaje. En los objetos Web utilizamos el mismo comando msg(), la diferencia está
en dónde se mostrará dicho mensaje, en una caja de texto y/o en el control Error Viewer (como
veremos más adelante) ya que contamos en Web con las facilidades que nos brinda Ajax.
Volvamos entonces a nuestro ejemplo para hacer el control del usuario y password en el evento
Enter del botón “Login” y agregar el comando msg() para desplegarle al cliente el mensaje que
corresponda.

Haga clic aquí para ver la demostración

Orden de precedencia de las propiedades

Las propiedades de un control se pueden configurar en:

 Ejecución (cambiando el valor de la propiedad mediante código GeneXus).

 Diseño (en las propiedades del control mismo, seleccionando el control y con botón
derecho haciendo clic en “Properties”).

 El Tema En este último caso se configuran las propiedades en una clase del Tema. La clase
se asocia al control, a través de la propiedad “Class” del mismo. La propiedad “Class” se
puede asignar a un control tanto en tiempo de diseño como en ejecución. Para poder asociar
una clase determinada a un control en tiempo de diseño, es necesario que el Tema en el cual
está definido la clase se asocie al objeto que contiene el control. La asociación de un Tema a
un objeto se hace a través de la propiedad “Theme” del objeto.

El orden de precedencia que se tiene en cuenta para que el control adopte las propiedades
configuradas, es el siguiente:

1. Ejecución

2. Diseño

3. Tema

Es decir que si una propiedad de un determinado control está configurada en el Tema, y también en
diseño; la configuración dada en diseño tiene precedencia sobre la del Tema; y la dada en ejecución
sobre la de diseño.
Se recomienda en general configurar las propiedades a nivel de los Temas, ya que de esta forma se
reduce el costo de mantenimiento del sitio.

Cuando se trabaja con objetos Tema de la base de conocimiento, el Editor de Temas, salva en el
directorio Web un archivo con extensión .CSS (Cascading Style Sheet).

Cambiando el Tema asociado al objeto que se desea modificar, basta con llevar el CSS a producción y
no es necesario generar/compilar nuevamente la aplicación. Esto último sí resulta necesario de
hacer en caso de configurar las propiedades en tiempo de diseño.

Nota: Observar que si un control está asociado a una clase de un Tema, el valor default de las
propiedades del control se corresponde a los valores configurados en la clase.

En el diálogo de propiedades, el valor default se puede identificar con un asterisco negro al lado de
la propiedad:

En el siguiente ejemplo, el control tiene una clase asociada (“Attribute”), sin embargo, la propiedad
“ForeColor”, está configurada a nivel de diseño.

En este caso, el asterisco al lado de la clase se visualiza en color gris (valor no default).
Propiedades del Form

Al form de los objetos Web se le pueden asignar propiedades haciendo clic y seleccionando la opción
Properties del menú.

Esta asignación de propiedades, puede hacerse en un objeto tema o directamente en el control.

En el caso de asignar propiedades en el control solamente aplicará al mismo y puede hacerse en


tiempo de diseño y algunas de ellas también pueden modificarse en tiempo de ejecución
(programando los eventos del objeto).

Propiedades en Tiempo de Diseño

Las propiedades del form que pueden asignarse son las que se muestran en el siguiente diálogo.
 Class: La propiedad Class solo se encuentra disponible si el form pertenece a un objeto
que tiene un Tema asociado.

 BackColor

 TextColor

 Background

 Background Properties

 TooltipText

 WordWrap

Propiedades para el color de los Links

 ActiveLinkColor

 VisitedLinkColor

 NotVisitedLinkColor

Propiedades para los márgenes

 TopMargin
 BottomMargin

 LeftMargin

 RightMargin

Propiedades del form HTML en tiempo de ejecución

En ejecución se pueden modificar las siguientes propiedades del Form:

 BackColor

 Background

 Caption: El caption del form se transforma en el título de la ventana. Por defecto, tiene
el nombre del objeto Web. Esta propiedad solamente puede modificarse en tiempo de
ejecución.

Propiedades del Form en los Temas

Es posible configurar en la Clase Form (o derivadas de ella) en el objeto tema, varias de las
propiedades de los forms disponibles en GeneXus y otras que no están en GeneXus.

En el caso de que una propiedad esté asignada en el control (en diseño o en ejecución) ese valor
tiene precedencia respecto al asignado en el tema. Ver Orden de precedencia de las propiedades.

Por detalles de propiedades del Form en los Temas, referirse a Clase Form.

Atributos y Variables

Al seleccionar un control y presionar el botón derecho del mouse aparecen sus propiedades para ser
modificadas. Esta modificación se considera realizada en tiempo de diseño.

Para modificar las propiedades de estos controles en ejecución, es necesario programarlo en algún
evento del objeto.

La sintaxis es normalmente <nombredecontrol>.<propiedad> = valor.

Un ejemplo puede ser &pwd.IsPassword = 1


Recuerde que muchas de estas propiedades pueden asignarse en el objeto Tema en la clase
Attribute, permitiendo así mayor dinamismo a la aplicación.

Si en el diálogo de selección de atributos o en el diálogo de selección de variables se seleccionan


varios a la vez, éstos se insertan en el formulario dentro de una tabla, simplificando así la tarea de
alineación.

Propiedades del control Edit en diseño

Las variables y atributos son controles de tipo Edit, que tienen las siguientes propiedades:

 Attribute

 Class
 Control Type: Las propiedades que se aplican sobre atributos y variables, dependen del tipo
de control que se seleccione. (Ver propiedades según el tipo de control).

 Dentro del grupo Appearance se encuentran todas las propiedades que aplican al aspecto
del control. Se detallan a continuación:

 Auto Resize: Esta propiedad aplica a controles edit que NO tengan la propiedad Read-Only con el
valor ‘True’, ya que en este caso se ignora el ancho especificado.
 Fill
 BackColor
 ForeColor
 Font
 Format
 Tooltiptext
 ReturnOnClick
 OnClickEvent
 Dentro del grupo Behavior se encuentran todas las propiedades que aplican al
comportamiento del control. Se detallan a continuación:

 ReadOnly
 EnableHistory
 EmptyAsNull
 IsPassword
 InputType: Esta propiedad permite sustituir lo que el usuario digita en un atributo por un valor más
amigable. Si esta propiedad toma el valor ‘Descriptions’, permite que el usuario digite la descripción
de otro atributo y se habilitan las siguientes propiedades: ItemValues, ItemDescription,
InstantiedAttributes, Conditions. Esto se puede realizar a nivel del atributo para que aplique por
defecto en todos los forms en donde este atributo esté presente como control, o también, es posible
definirlo en forma particular, para un control atributo en concreto de un form determinado. En este
último caso se definirá en el control info de ese control en particular.
 Suggest: Posibilita al usuario que elija entre un conjunto de valores posibles (una lista de posibles
valores que se despliega debajo del control) y no tenga que recordar exactamente el valor a digitar.
La lista de sugerencias puede ser calculada de un modo incremental (la lista es actualizada con las
entradas del usuario) o haciendo pedidos explícitos (el usuario manualmente hace un pedido para
que se calculen las sugerencias y se le muestren). La actualización de la lista es asincrónica y los
tiempos de cálculo dependen de la calidad de la conexión. Al tomar los valores Incremental u
OnRequest, se habilitan las siguientes propiedades: ItemValues, InstantiedAttributes, Conditions,
FilterOperator, SortDescriptions, CaseSensitive, SuggestMaxItems. Esto se puede realizar tanto a
nivel del atributo como del control.
 Conditions: Permite condicionar los valores sugeridos y/o los valores que puede tomar el atributo
edit.
 InstantiedAttributes: Permite filtrar el conjunto de valores dependiendo de otros atributos que no
pueden ser inferidos directamente.

Propiedades del Control Edit en Tiempo de Ejecución

Además de las propiedades vistas anteriormente, existen otras que permiten modificar en tiempo de
ejecución los controles de tipo edit. Las propiedades son:

 Backcolor
 BackStyle
 Enabled
 FontBold
 FontItalic
 FontName
 FontSize
 FontStrikethru
 FontUnderline
 ForeColor
 Format
 InternalName
 IsPassword
 Link
 LinkTarget
 Visible
 Class
Propiedades según el Tipo de Control

Hay otras propiedades, específicas según el tipo de control que se utilice.

COMBO BOX
Las propiedades a nivel de diseño que aplican son:

 Attribute
 BackColor
 ForeColor
 Fill
 Font
 ReadOnly

Las propiedades a nivel de ejecución son:

 Backcolor
 BackStyle
 Enabled
 FontBold
 FontItalic
 FontName
 FontSize
 FontStrikethru
 FontUnderline
 ForeColor
 InternalName
 Visible

NOTA: Alineación de un combo box/dynamic combo box en grids. Siempre se alinea a la izquierda
independientemente del tipo de datos. Esto se hace así porque aún cuando el combo sea sobre un
atributo numérico los valores que se muestran en el combo son de tipo carácter.

RADIO BUTTON, CHECK BOX


Las propiedades a nivel de diseño que aplican son:

 Attribute
 BackColor
 ForeColor
 Fill
 Font

Los radio button tienen también la propiedad Radio Direction que permite indicar si las opciones del radio
button se desplegarán en forma vertical u horizontal.

Las propiedades a nivel de ejecución son:

 BackColor
 BackStyle
 Caption
 Class
 Enabled
 FontBold
 FontItalic
 FontName
 FontSize
 FontStrikethru
 FontUnderline
 ForeColor
 Height
 ImeMode
 InternalName
 IsPassword
 Left
 Tag
 ToolTipText
 Top
 Visible
 Widht

Propiedades de atributos/variables en el Tema

Las propiedades se pueden configurar también en el Tema. La clase predefinida “Attribute” del Editor de
Temas reúne las propiedades para todos los controles en los cuales se puedan representar atributos/variables
en el form, a saber:
 Edit
 Combo Box
 List Box
 Radio Button

Obviamente se pueden derivar clases de la clase predefinida “Attribute”, por más información referirse a
Clase Attribute.

Propiedades de variables de tipo bitmap en diseño

Las propiedades que se detallan a continuación aplican únicamente a variables de tipo bitmap.

 Class
 Autoresize
 Borderwidth
 AlternateText
 Tooltiptext
 Hspace
 Vspace
 ReturnOnClick
 OnClickEvent

Propiedades de variables de tipo bitmap en tiempo de ejecución

A las variables de tipo bitmap se le pueden modificar las siguientes propiedades en tiempo de ejecución:
 AlternateText
 Borderwidth
 Class
 Enabled
 InternalName
 Link
 LinkTarget
 Tooltiptext
 Visible
 Vspace
 HSpace

NOTA: La propiedad Enabled de Runtime permite habilitar (Enabled=1)/deshabilitar (Enabled=0) la


ejecución del evento asociado a la variable bitmap.

Propiedades de variables de tipo bitmap en el Tema

Las propiedades de las variables bitmap (y controles imagen), se pueden configurar en los Temas.
Referirse a Clase Image.

Métodos de los Controles

Los métodos que aplican a los controles combo box, dynamic combo box, listbox y radio button son:

 AddItem

 Clear

 Removeitem

 Repaint

 Setfocus

 Text

 Value

Picture de los tipos de datos Date y Datetime

Se formatea lo digitado por el usuario en campos de tipo Date y Datetime. Esto permite, por
ejemplo, que el usuario final digite una fecha u hora sin los separadores ('/', ':', etc.) y se mejore la
"visualización".

El formateo ocurre cuando el usuario "sale" del campo y controla únicamente que el formato sea
correcto. No se controla que la fecha y/o hora sea válida: esto lo hacen los programas.

En caso de que el formato no sea correcto, se emite un mensaje de error (una ventana con el
mensaje 'Date or time format is not correct') y se vuelve el foco al campo incorrecto.
Botones

Para insertar un botón en el formulario se puede seleccionar el de la barra de controles


disponibles.

En los objetos Web se pueden usar varios botones y asociarles eventos (predefinidos de GeneXus o
definidos por el usuario). Al presionar el botón derecho del mouse se visualiza el siguiente diálogo
que habilita al usuario a editar las propiedades del mismo o a editar el evento que el botón tiene
asociado.

Propiedades de botones

Las propiedades de los controles de tipo Button que pueden modificarse en diseño son:

 ControlName

 Class
 OnClickEvent

 Caption

 Font

 ForeColor

 BackColor

 BorderWidth

 BorderColor

En ejecución se pueden modificar todas estas propiedades (excepto la control name) del botón y además
las siguientes:
 Enabled
 Internal Name
 Visible

Propiedades de botones en temas

Además de estas propiedades, en la clase Button de un tema se pueden setear otras propiedades que
permiten definir otras características a los botones. Ver Clase Button.

Tamaño de botones

El tamaño del botón queda determinado por el texto ingresado en la propiedad Caption del mismo.

Si se desea que los botones tengan un tamaño fijo, se deben asociar mediante la propiedad Class a
una clase de un tema que tenga un tamaño definido (propiedades Heigth y Width). En este caso, el
tamaño quedará fijo independientemente del caption.

Cómo asignar un evento a un botón

Para asignar un evento a un botón se puede ingresar directamente el nombre del evento (entre comillas
simples) o hacer clic al botón . Al utilizar este selector de eventos se visualiza el siguiente diálogo, con
los eventos disponibles, habilitando al usuario la creación un nuevo evento (mediante el botón New).
INTRODUCCIÓN

Los web panels al igual que los work panels son objetos GeneXus que permiten al usuario en tiempo
de ejecución, realizar interactivamente consultas a la base de datos a través de una pantalla.

El término interactivamente se refiere a que el usuario podrá ingresar en la pantalla de un web


panel, una y otra vez distintos valores de filtros, y consultar a continuación los datos que concuerden
con los mismos. Además, sobre los datos consultados, el usuario podrá realizar distintas acciones,
como veremos.

Los web panels no permiten la actualización de la base de datos, sino sólo consultarla.

El objetivo primordial de los web panels es la definición de consultas interactivas a la base de datos,
sin embargo se trata de un objeto muy flexible por lo que se presta para diversos usos más.

En este capítulo estudiaremos todos los detalles acerca de los web panels y los compararemos con
los work panels para establecer las similitudes y diferencias.

Opciones para definir filtros en Web Panels

Cuando un Web Panel es invocado desde otro objeto, y se requiere que reciba uno o más
parámetros para filtrar por igualdad por los mismos, la forma más directa y sencilla de resolverlo es
declarando en la regla parm del objeto, a dicho(s) parámetro(s) por los cuales se necesita filtrar por
igualdad, como atributo(s). (PIE 1)

Es decir, si por ejemplo un web panel exhibe las facturas de un cliente, y se requiere que reciba por
parámetro el código del cliente del cual se deben mostrar sus facuras, la opción más directa y
sencilla para definir el filtro es en la regla parm, recibiendo al código de cliente en el atributo
mismo: parm(CliCod);
De esta forma, GeneXus entenderá automáticamente que el atributo CliCod actuará como filtro por
igualdad en todo el objeto (es decir, que será un filtro global).

Otra alternativa posible, es recibir en la regla parm a una variable y luego definir una condición de
filtro: CliCod=&CliCod; Recordemos que cuando se reciben variables en la regla parm, GeneXus no
hace nada automáticamente con ellas, por lo tanto el analista deberá definir condiciones de filtro
explícitamente utilizando a las variables como desee.

Cuando en cambio, se trata de web panels que no reciben parámetros, y que las condiciones de
filtro deben definirse explícitamente (por ejemplo involucrando a variables cuyos valores son
ingresados por el usuario en tiempo de ejecución en la parte fija del web panel) habrá que decidir si
definir condiciones globales o condiciones a nivel de un grid en particular. (PIE 2)

Las opciones para definir filtros son las mismas en web panels y en work panels

Recomendamos acceder al material del Curso No Presencial de GeneXus donde encontrará


información específica de este tema.

Eventos en Web Panels

En los web panels se utiliza la programación dirigida por eventos, que es un estilo de programación
en el cuál se define código que permanece ocioso, hasta que suceden eventos provocados por el
usuario o por el sistema, que provocan que el código definido se ejecute.

Los eventos son acciones reconocidas por un objeto que pueden suceder o no. A cada evento se le
puede asociar código, que se ejecutará solamente si el evento se produce.

El código que se le puede asociar a un evento, se escribe con estilo procedural; y cuando el evento
se produce, el código asociado al mismo se ejecutará secuencialmente.
Eventos existentes en Web Panels

Los eventos existentes en los web panels, son:

 Evento Start

 Evento Refresh

 Evento Load

 Evento Enter

 Eventos de Usuario

 Evento clic asociado a un control

En primera instancia explicaremos cada uno de estos eventos conceptualmente y en qué momento
exacto se ejecutan, y a lo largo del curso veremos varios ejemplos de utilización de los mismos.

Orden de los datos en un Web Panel

Para definir en un web panel que una consulta se efectúe ordenando por cierto(s) atributo(s), y por
ende que los datos extraídos de la consulta se muestren ordenados con dicho criterio, se debe hacer
clic con el botón derecho del mouse sobre el grid, y seleccionar el ítem Order en el siguiente menú
pop up:
A continuación, se presentará el siguiente diálogo para que se ingrese por qué atributo(s) se desea
ordenar:

Definir esto es equivalente a definir la cláusula order en el comando for each , por ejemplo: que
para ordenar en forma descendente por un atributo se debe encerrar al atributo entre paréntesis (),
o que se crean índices temporales cuando no existe un índice físico por los atributos por los cuales se
indica ordenar.

Solamente si el form del web panel no tiene ningún grid, y se necesita definir un orden específico para la
consulta, se contará con la posibilidad de definir en la sección de reglas del web panel, la regla de sintaxis:
order(att1, att2, attN); siendo att1, att2, attN: la lista de atributos que define el orden de la consulta.

Recomendamos acceder al material del Curso No Presencial de GeneXus donde encontrará


información específica de este tema.

Reglas en Web Panels

En el objeto work panel, las reglas más utilizadas son las siguientes: Order, Noaccept, Search,
Hidden, Workfile_lines y default.

En los web panels, hay algunas diferencias en el uso de las mismas.


Order, Naccept, Hidden

Estas tres reglas se utilizan de la misma forma en los work panels que en los web panels.

Cuando se quiere usar la regla Hidden para atributos de un grid, se recomienda en lugar de eso, utilizar la
propiedad de Visible. El valor de los atributos / variables de la regla hidden se "guarda" para cada línea de
cada grid que exista en la pantalla. Los atributos con Visible en False, no se ven en el grid final pero también
se "guardan" aunque solamente para cada línea del grid en el que fueron definidos. Se sugiere que se
promueva el uso de los atributos con Visible en False para el desarrollo de aplicaciones en lugar de la regla
hidden. La causa de esto es que los hiddens se mandan en todos los grids mientras que los otros sólo para el
grid en que fueron definidos. Esto redunda en menos código HTML a enviar al Browser y, en consecuencia,
mejor performance.

Algo similar ocurre con la regla Order, ya que en caso de tener múltiples grids definidos en el objeto
se recomienda usar la propiedad a nivel del grid y no la regla ya que se estará indicando
concretamente a cual de los grids deberá aplicarse el orden.

Workfile_lines

Esta regla no aplica a los web panels ya que no existe una tabla temporal para almacenar el resultado de una
consulta a la base de datos. La forma de hacer esto en web panels es usando la propiedad Rows del grid.

Default

Esta regla asigna un valor por defecto a una variable (definida en el objeto). El valor puede ser un literal
entre comillas, un número o una de las funciones Today(), Date() o SysDate(), debiendo coincidir el tipo de
datos del valor con el tipo de datos de la variable.

El valor por defecto se asignará a la variable al principio de la ejecución del programa.

Comandos en Objetos Web

A continuación se detallan los comandos soportados por los Web Panels y las transacciones con
interfaz Web.

Call

El comando Call no presenta grandes diferencias con respecto al resto de los objetos GeneXus.

Es importante tener en cuenta que los objetos web ejecutan en el servidor y por consiguiente no
pueden realizar llamadas a programas que tengan salida en pantalla, ya que la ejecución de dicha
llamada cancelaría por time-out. En resumen, desde un objeto web, se puede llamar a otro objeto
web, a un procedimiento o reporte que no tengan salida en pantalla.
Link

El comando link es equivalente al comando call para llamar a páginas estáticas o redireccionar a una
URL. Este comando puede ser utilizado dentro de cualquier evento de un objeto web con excepción
del evento Load. El resultado de la utilización de este comando es el redireccionamiento en forma
automática a la URL especificada dentro del mismo.

Sintaxis:

Link( usr-pgm | ’url’ [{, parm}…] )

Donde:

usr-pgm

Es el nombre del web object al que se va a redireccionar

url

Es el nombre de la URL a la que se va a redireccionar

parm

Son los parámetros que recibe la URL. El pasaje de parámetros es opcional.

Ejemplo:

Event ENTER

Link(‘http://www.ARTech.com.uy’)

Endevent

Load

El comando Load es análogo al resto de los objetos GeneXus.


Refresh

El comando Refresh vuelve a cargar la página, teniendo el mismo efecto que presionar la tecla de
función F5 del browser. La página se cargará manteniendo los últimos valores sometidos para las
variables ingresadas por el usuario.

Return

Incluir el comando return en un objeto web, es equivalente a hacer un CALL al objeto que lo invocó.
En consecuencia no equivale a presionar el botón ‘Back’ del browser, ya que si se ingresaron valores
en variables del objeto web llamador, los mismos no son mantenidos al ejecutar el comando Return.

Este comando Return puede ser ejecutado en cualquier evento o subrutina del objeto, salvo el evento Load y
los métodos Load de las grillas. Tampoco puede ser ejecutado en subrutinas llamadas directa o
indirectamente por el evento Load o métodos Load de las grillas. En caso que se ejecute en las mencionadas
situaciones los resultados son impredecibles.

En el caso del primer objeto web, el return intentará cerrar el navegador.

Si se utiliza el método Set en un tipo de datos WebSession y luego se ejecuta el comando Return el valor de
la(s) cookie(s) se establece correctamente.

Comparación entre Web Panels y Work Panels

Se puede decir que los objetos Web Panel y Work Panel de GeneXus son similares ya que ambos
permiten definir consultas interactivas a la base de datos. Son objetos muy flexibles que se prestan
para múltiples usos, cuya programación está dirigida por eventos. De todos modos, hay algunas
diferencias causadas principalmente por el esquema de trabajo en Internet.

Tabla Base

La determinación de la tabla base de los Web Panels es análoga a la determinación de los Work
Panels.

Eventos

Los eventos de los Web Panels son los mismos que en los Work Panels, es decir evento Start,
Refresh, Load, Enter y los definidos por el usuario. La diferencia con los Work Panels es el orden de
disparo de estos eventos. Esto está relacionado con el esquema de trabajo en Internet.
Variables

Como se menciona en el documento Esquema de trabajo en Internet, las variables adquieren los
valores ingresados por el usuario después de presionar algún botón en el objeto web.

Por ejemplo, cualquier link a otro objeto web especificado en el evento Start con una variable que se
ingresa en un Web Panel no va a tener ningún valor cuando se haga clic sobre el link.

Si en un evento se usa una variable que se carga en otro evento, entonces esa variable debe estar
presente en el form. Si no está en el form, la variable no tendrá valor cuando se disparan los otros
eventos (esto es por el “orden” en que ocurren los eventos).

Además, deberá estar en el form después del control en el que se carga la variable. Por ejemplo, si la
variable se carga en el Evento Load de una grilla entonces la variable tiene que estar en pantalla
después de la grilla.

Disparo de fórmulas stand alone

En un Web Panel existen fórmulas que pueden ser gatilladas antes del evento Start y otras que
deben gatillarse luego del mismo evento.

Las fórmulas que se gatillan antes del evento Start son aquéllas que sólo dependen de los
parámetros que llegan al programa (mediante la regla parm())

Las fórmulas que se gatillan después del evento Start son aquéllas que dependen de atributos o
variables instanciados (vía asignación, Call, etc.) en el evento Start.

Propiedades

En los Work Panels las propiedades más utilizadas son las correspondientes al grupo Loading (Load
Records, Load at Startup, Automatic Refresh y When to Refresh) para manipular la visualización de
grandes cantidades de registros.

En los Web Panels no se dispone de estas propiedades.

En los Web Panels con tabla base la carga de los registros se realiza de una sola vez (lo que se
corresponde con el valor Load all records de la propiedad Load Records) y la grilla se carga por
primera vez inmediatamente a continuación de la apertura del form en tiempo de ejecución (lo que
se corresponde con el valor Yes de la propiedad Load at Startup).
En las grillas de los objetos Web para resolver la visualización de grandes cantidades de registros se
dispone de la paginación automática.

Determinación de la Tabla Base en Web Panels

Web Panel con tabla base (a lo sumo un grid)

El Web Panel es “con tabla base” cuando a lo sumo tiene un grid y GeneXus puede determinar un for each
implícito asociado a él.

Para determinar si un Web Panel tiene tabla base y en caso afirmativo cuál será, al momento de especificarlo
GeneXus analiza los atributos incluidos en:

 form: en la parte fija


 form: en el grid (visibles o no visibles)
 el order del grid
 las condiciones del grid (no en las condiciones globales)
 los eventos fuera de comandos for each

GeneXus no toma en cuenta para determinar la tabla base de un Web Panel:

 los atributos recibidos por parámetro


 los atributos mencionados en las condiciones globales del Web Panel

Éstos actúan como filtros una vez determinada la tabla base.

Web Panel con N tablas

Cuando un Web Panel contiene más de un grid en su form, GeneXus no determina una única tabla
base asociada, sino una tabla base asociada a cada grid.

Atributos que participan en la determinación de la tabla base de cada grid:

 Los incluidos en el grid (se tienen en cuenta tanto los atributos visibles como los no
visibles)
 Los referenciados en Order y Conditions locales al grid

Los atributos de la parte fija del Web Panel no participan en la determinación de la tabla base de
ninguno de los grids, pero deberán pertenecer a la tabla extendida de alguno de ellos (para que sea
posible inferir sus valores). De no respetarse esto, al especificar al Web Panel, se mostrará en el
listado de navegación resultante, un warning advirtiendo de esta situación.

Los atributos utilizados en los eventos del Web Panel tampoco participan en la determinación de la
tabla base de ninguno de los grids. Los atributos que se incluyan en los eventos fuera de comandos
for each, deberán pertenecer a la tabla extendida de alguno de los grids (al igual que los de la parte
fija).
Demo: Web Panel Principal del Sitio

Comenzaremos a desarrollar el Web Panel principal del sitio donde el usuario va a poder buscar las
atracciones turísticas y los servicios provistos de una ciudad como también los vuelos que arriban a
la misma. El nombre del objeto será MainSearch y como será el punto principal de entrada de
nuestro sitio lo definiremos como objeto Main asignando a la propiedad “Main” en “True”.

Las Transacciones que ya están definidas en este sistema son las siguientes (se describen solo los
principales atributos de las mismas)

Country CityAttraction ServiceProvider

CountryId* CountryId* TourismServiceProviderId*

CountryName CityId* TourismServiceProviderName

(CityId* (TouristAttractionId* TourismSerivceCatId

CitiName) TouristAttractionCatId) CountryId

CityId

(TourismServiceCatTypeId*

TourismServiceCatTypePrice)

Flights TourismServiceCategory TouristAttractionCategory

FlightId* TourismServiceCatId* TouristAttractionCatId*


TourismServiceCatDsc
DepartureCountryId TouristAttractionCatDescription
TourismServiceCatImage
DepartureCityId TouristAttractionCatImage
(TourismServiceCatTypeId*
ArrivalCountryId

ArrivalCityId TourismServiceCatTypeDsc)

(FlightCategory
FlightPrice)

Users

UserId*
UserNickName

UserPwd

UserLastName

UserFirstName

UserName

UserEmail

UserAddress

UserPhone

CountryId

CountryName

CityId

CityName

El objeto en ejecución deberá verse como el siguiente:


En estos capítulos iremos adquiriendo los conocimientos necesarios para implementarlo.

Nos centraremos primero en la parte principal de búsqueda.

Allí programaremos la paginación a pedido en los grids, cargando 5 registros a la vez y pudiendo
filtrar por país y ciudad. En cada grid, pondremos links a otros Web Panels con información más
detallada.

Para hacer esto crearemos dos variables en la parte fija del Web Panel, donde el usuario indicará los
filtros correspondientes para el país y la ciudad (&CountryId y &CityId).

Estas variables las definiremos basadas en los atributos para que “hereden” los tipos de datos de los
mismos.

Buscando que la interfaz sea amigable para los usuarios, se sugiere que el ingreso de datos sea
simple y rápido.
Para esto, se recomienda que los usuarios no deban ingresar (¡ni recordar!) códigos sino que puedan
ingresar los nombres y que el diálogo les sugiera valores posibles a medida que digitan.

Para esto, definiremos las variables como dynamic combo box con filtros.

Definiremos que &CountryId sea un combo dinámico. Los valores posibles serán el atributo
CountryId y las descripciones serán el nombre del país (CountryName).

Además, utilizaremos un valor vacío que indique que no está seleccionado ningún país. Para esto,
asignaremos a la propiedad “EmptyItem” el valor “Yes” y el texto será “Select a Country…” (se
configura en la propiedad EmptyItemText).

Lo mismo haremos con la ciudad. Para eso definiremos &CityId también como combo dinámico con
un valor vacío de texto “Select a City…”.

Recordar que al seleccionar más de un atributo, GeneXus crea una Tabla para alinear los
controles. Sin embargo, el orden elegido no será el deseado por lo que deberán moverse los
controles.
Para que el combo muestre las ciudades del país elegido previamente, es necesario definirle una
condición por el país.

La condición será:

CountryId = &CountryId;

Agregaremos también un botón para realizar la búsqueda de los datos.

Vea la demostración aquí

Podemos ejecutar el Web Panel que hemos desarrollado para ir probando la funcionalidad.

Primero lo especificaremos y generaremos.

En la navegación vemos que:


GeneXus navega la tabla COUNTRIES ordenada por nombre de país, para realizar la carga del combo
dinámico &CountryId. Mientas que para la carga de &CityId, recorre la tabla COUNTRIES1 ordenado
por el nombre de la ciudad y filtrando por el país seleccionado en la variable &CountryId.

Como el objeto es main, podremos compilarlo y ejecutarlo directamente ya que aparece en el


diálogo de ejecución.

Cuando se desea que todos los combos dinámicos de la base de conocimiento muestren el
mismo valor en ejecución para el valor vacío, se deja el valor GX_EmptyItemText propuesto en la
propiedad EmptyItem. Este texto aparecerá como código en el Objeto Lenguaje para que pueda
ser traducido. El texto propuesto es “(None)” cuando el idioma lenguaje es inglés.

Lo mismo ocurrirá si se asigna un valor específico a esta propiedad a nivel del control o del atributo.
En este caso, ese texto será una nueva entrada en los códigos del objeto Lenguaje.

Recuerde que es necesario especificar el objeto antes de que aparezcan los códigos en el objeto
Language.

Evento Start (de Web Panels)

El evento Start es un evento del sistema, que ocurre automáticamente.

¿En qué momento se ejecuta? Cuando comienza la ejecución del programa asociado a un web
panel, es decir, ni bien se abre un web panel en tiempo de ejecución.

¿Cuántas veces se ejecuta? Una vez cuando comienza la ejecución del web panel y tantas veces
más como ejecuciones de eventos de usuario se realicen que no incluyan una invocación a otro
objeto web.
En el evento Start no se conocen valores de atributos, salvo los recibidos por parámetro. Esto se
debe a que aún no se ha efectuado la consulta.

Generalmente se suelen incluir asignaciones de valores a variables, para inicializarlas.

El Evento Start de un work panel se ejecuta una vez sóla cuando comienza la ejecución del
mismo.

Evento Refresh (de Web Panels)

Cuando el usuario presiona el botón Refresh en un web panel se ejecuta el evento Refresh.

A su vez, cuando el usuario pasa de la parte fija del web panel al grid, también se ejecuta el evento
Refresh.

Y cuando se ejecuta el comando Refresh incluido por el analista GeneXus en algún evento, también
se ejecuta el evento Refresh.

Se ejecuta cada vez que se realiza un Get o Post..

El evento Refresh es un evento del sistema que a continuación de ejecutarse, causa que se ejecute
la consulta a la base de datos. Es decir, al ejecutarse el evento Refresh, se ejecuta el código
asociado al mismo, y a continuación se ejecuta la consulta a la base de datos. Seguidamente, se
ejecutará el evento Load.

El Evento Start de un work panel se ejecuta una vez sóla cuando comienza la ejecución del
mismo.
Evento Load (de Web Panels)

Cada vez que se ejecute el evento Refresh en un web panel, seguidamente a la ejecución del mismo,
se ejecutará el evento Load.

¿Cuántas veces se ejecutará el evento Load?

La cantidad de veces que se ejecutará el evento Load, dependerá de si el web panel tiene tabla base
o no tiene tabla base.

SI EL WEB PANEL TIENE TABLA BASE


Si el web panel tiene tabla base, el evento Load se ejecutará N veces: una vez por cada registro leído
en la consulta efectuada a la base de datos, justo antes de cargar los datos del registro en una línea
en el grid.

De modo que por cada registro leído en la consulta efectuada a la base de datos, se ejecutará el
evento Load (ejecutándose el código incluido en el mismo, y cargándose a continuación una línea en
el grid con los datos del registro).

SI EL WEB PANEL NO TIENE TABLA BASE


Si el web panel no tiene tabla base, el evento Load se ejecutará solamente una vez.

Que el web panel no tenga tabla base, significa que no tiene un for each implícito asociado; por lo
tanto, cuando se ejecute el evento Refresh, no comenzará a ejecutarse ninguna consulta; se
ejecutará el código asociado al evento Refresh, y a continuación se ejecutará el código asociado al
evento Load, una sola vez.

Evento Enter (de Web Panels)

Cuando se inserta un nuevo botón en el form de un Web Panel, por defecto aparece con el Caption
“Confirm” y aparece asociado al evento del sistema Enter.
El evento Enter puede asociarse a cualquier botón, atributo, imagen, text block, en la propiedad de
los controles: OnClickEvent.

De modo que si se necesita ejecutar acciones cuando el usuario final haga clic en el control asociado,
en este evento deberán codificarse.

Eventos de usuario (de Web Panels)

Además de los eventos ofrecidos por GeneXus, el analista puede definir eventos creados por él, los
cuales reciben el nombre de eventos de usuario.

Cada evento de usuario debe asociarse a un control insertado en el form del web panel de los que
soportan el OnClickEvent (botones, text blocks, imágenes, atributos).
En tiempo de ejecución, el evento de usuario ocurrirá luego de que el usuario haga clic sobre el
control asociado al mismo. Se consigue de dos maneras distintas:

1. Editando las propiedades del control, y definiendo un evento de usuario en la propiedad


OnClicEvent. De esta manera GeneXus define la siguiente sintaxis automáticamente:

Event ‘Nombre Evento de Usuario’ [key]


EndEvent

2. Dándole un nombre al control y en la sección de Eventos programando:

Event nombreControl.click

Endevent

Con esta última alternativa no tendremos que definir un evento de usuario, sino que estaremos
programando el evento clic del control.
Esquema de trabajo en Internet

Es importante entender que en Internet, cuando el usuario accede a una página del servidor Web
para visualizarla, el Browser baja la página al cliente. Por lo tanto, no existe forma de detectar lo que
realiza el usuario: el Servidor Web volverá a tener el control cuando se dispare el evento Enter o
algún evento de usuario. En ese momento se envía (o se somete, se hace un post) el resultado al
servidor para continuar con su procesamiento. Es decir, una vez que el objeto web finaliza la
ejecución en el servidor, no queda en memoria. Como consecuencia, la forma en que programamos
este tipo de aplicaciones presenta algunas diferencias con respecto a lo acostumbrado en ambientes
no web.

Es por esta razón importante destacar el orden en que se disparan los eventos y el momento en que
las variables adquieren el valor ingresado por el usuario.

Orden de ejecución de los eventos

El orden de ejecución de los eventos en web panels es diferente si se trata de la primera llamada al
mismo (GET) o si se disparó algún evento de usuario o enter (POST).

PRIMERA EJECUCIÓN DE LOS WEB PANELS


La primera vez que se ejecuta el web panel (se conoce también como el momento en que se hace el
“GET” de la página) los eventos que se disparan son los siguientes y en el siguiente orden:
1. Evento Start

2. Evento Refresh

3. Evento Load

Luego de esto, cuando se ejecuta el evento Enter o un evento de usuario que no llame a ningún otro
web panel (ya sea porque el usuario presionó un botón o dió clic en algún control del form con el
evento Clic programado), se ejecutará nuevamente éste y el orden de disparo de los eventos será
diferente.

RESTO DE LAS EJECUCIONES DE LOS WEB PANELS


En el resto de las ejecuciones (momento que se conoce también como el “POST” de la página) los
eventos se dispararán en el siguiente orden:

1. Evento Start (nuevamente se dispara el evento Start)

2. Nueva lectura de las variables de la pantalla. Esto se realiza porque el usuario


puede haberlas modificado (por ejemplo las variables de la parte fija del web panel
que están involucradas en las conditions)

3. Código correspondiente al evento asociado al botón seleccionado.

4. Evento Refresh

5. Evento Load

Relacionado con esto es importante destacar el momento en que las variables adquieren los valores
ingresados por el usuario: solamente lo harán después de ejecutar un evento (presionar un botón),
que es cuando el servidor Web tiene el control del procesamiento.

Esto implica algunos cambios importantes en la forma de programar los objetos.

Por ejemplo, cualquier link a otro web panel especificado en el Evento Start con una variable que se
ingresa en el web panel no va a tener ningún valor cuando se haga clic sobre el link.

Si en un Evento se usa una variable que se carga en otro evento, entonces esa variable debe estar
presente en el form. Si no está en el form, la variable no tendrá valor cuando se disparan los otros
eventos (esto es por el “orden” en que ocurren los eventos).

Además, deberá estar en el form después del control en el que se carga la variable. Por ejemplo, si la
variable se carga en el LOAD de un grid entonces la variable tiene que estar en pantalla después del
grid.

Si el evento que se ejecuta llama a otro web panel, comenzará a ejecutarse ese objeto,
disparándose los eventos del mismo según lo descrito antes en la primer Ejecución de los web
panels.

En HTML se puede especificar dos métodos distintos para someter un formulario. El método
se especifica dentro del elemento HTML “FORM”, usando el atributo “METHOD”, por ejemplo:

<form id="MAINFORM" name="MAINFORM" method="POST" ACTION="hwfmain.aspx">

Las especificaciones HTML definen técnicamente la diferencia entre GET y POST de la siguiente
forma:

 En el GET, los datos del form son codificados por el browser en la URL misma.

 En el POST, los datos del form van en el cuerpo del mensaje.

Entonces, cuando es METHOD="GET" los datos del form se codifican en una URL (o mas
genéricamente en una URI), lo cual significa que esa forma de someter el form es equivalente a
seguir un link a la URL codificada.

En general, el GET es para recuperar datos mientras que el POST sería para grabar, actualizar datos,
ordenar un producto, etc..

En GeneXus todos los eventos se resuelven con un POST y se ejecutan en el servidor Web.
Demo: Esquema de Trabajo en Internet
Aunque decimos que los web panels son similares a los work panels, hay una diferencia fundamental entre
ellos relacionada con el hecho que el objeto web una vez que finaliza la ejecución, no queda en memoria.
Como consecuencia, la forma en que programamos este tipo de aplicaciones presenta algunas diferencias con
respecto a lo acostumbrado en ambientes no web.

Es por esta razón que es importante tener claro el orden de ejecución de los eventos. Ejemplifiquemos esto,
programando nuestra aplicación.

Supongamos que en el evento donde validamos el usuario y la contraseña (en el web panel Login),
guardamos en una variable el código de usuario para poder utilizarlo en otro evento. Esto nos permitiría, por
ejemplo, llamar a un objeto que permita visualizar los datos del usuario.

En consecuencia, deberíamos programar lo siguiente en el evento donde validamos el usuario:

Event ‘Login’

for each

where UserNickName = &UserNickName

if UserPwd = &UserPwd

&UserId = UserId

login.Caption = "Welcome to Travel.com"

else

login.Visible = 1

login.Caption = "Invalid password"

endif

when none

login.Visible = 1

login.Caption = "Invalid User"

endfor

Endevent

Para realizar la llamada al web panel Perfil del Cliente (UserProfile), existen varias alternativas: se puede
definir un link en algún evento, o se puede agregar un botón y en el evento asociado invocar al objeto.

El link se podría definir en el mismo evento Login a continuación de la asignación de la variable.

Si agregásemos un botón o una imagen con un evento clic asociado, entonces el código seria el siguiente:
Event profile.clic/profile
Call(HUserProfile,&UserId)
Endevent

Otra alternativa (la que vamos a implementar en este caso), es usar un control textblock y hacer el llamado
al webpanel en el evento clic del textblock.

Repasemos entonces lo que pasa en este segundo caso:

1. En la primer ejecución se disparan los eventos: Start, Refresh y Load y podemos ingresar el usuario y
password.
2. Cuando presionamos el botón para validar el login, se asigna a la variable &UserId el código de
usuario correspondiente.
3. Cuando presionamos la imagen con el evento clic asociado, se dispara el evento Start, se leen las
variables que están en pantalla, se ejecuta el evento clic y ahí cuando trata de redireccionarnos al
Web Panel CustProfile, la variable &CustId no tiene valor ninguno, ya que la misma se perdió luego de
haber finalizado la ejecución del Web Panel en el punto 2.

Haga clic aquí para ver la demostración

Probemos el web panel con el usuario “myuser”, y password “mykey”. Este usuario ya ha sido definido en los
datos que se distribuyen con el curso.

Haga clic aquí para ver la ejecución

Es por esta razón, que si queremos disponer del valor de la misma, deberíamos agregar la variable &UserId
en el form y la ocultaríamos usando la propiedad Visible (por ejemplo en el evento Start).
Entonces en este caso, cuando el web panel ejecute por segunda vez, se dispararán los eventos:

1. Start
2. Se leen las variables del form (en este momento se obtiene el valor de CustId)
3. Se ejecuta el evento clic, y por consiguiente se llama al web panel con el código de cliente correcto!

Haga clic aquí para ver la demostración

Haga clic aquí para ver la ejecución

INTRODUCCIÓN

En los objetos web, se dispone de más de un tipo de grid: el grid estándar y el grid Freestyle. Estos
grids, potencian el diseño de aplicaciones Web, permitiendo al desarrollador mayor libertad a la
hora del diseño.

Además en el caso de los Web Panels, es posible utilizar múltiples grids y también anidarlos para
permitir navegaciones más complejas.

A lo largo de este capítulo iremos implementando todo esto a medida que vamos viendo los
conceptos teóricos necesarios para su desarrollo.

Control Grid

Este control permite desplegar, -y dependiendo del objeto GeneXus que se trate, también ingresar,
modificar y/o eliminar- información asociada a muchos registros.
Puede utilizarse en los objetos con interfaz, es decir transacciones, web panels o work panels y
permite incluir tanto atributos como variables (incluyendo las de tipo bitmap).

Cuando el control Grid se utiliza en una transacción, por medio del mismo será posible insertar,
modificar y/o eliminar registros, en la tabla asociada que corresponda (en ejemplo, en la tabla
TOURISMSERVICELEVEL1).

Cuando en cambio, el control Grid se utiliza en un web panel o work panel, el mismo permitirá
visualizar únicamente los datos almacenados en tablas.

En ejecución, el grid es una tabla HTML.

El botón que se encuentra en la barra de controles, permite insertar el control Grid. Al editar las
propiedades del control Grid, se abre un diálogo con las siguientes opciones: Columnas y
Propiedades.

Columns

Permite indicar las columnas que componen el grid.


Botones Add y Delete: Permiten agregar y eliminar columnas al grid respectivamente (tanto
atributos como variables).

Botones Move Up y Move Down: Permiten cambiar el orden de las columnas.

Botón Properties: Permite asignar propiedades específicas a la columna seleccionada.

Properties

Permite asignar propiedades de visualización para el grid estándar.

Propiedades del Grid

A continuación se detallan las propiedades generales del grid:


 Control Name

 Class La propiedad Class solo se encuentra disponible si el control está en el form de un


objeto que tiene un Tema asociado.

 AutoResize

 Width

 Heigth

 LinesColor

 LinesFont

 TitleForeColor

 TitleFont
 BackColorStyle

 BorderColor

 Rows

 AllowCollapsing

 Collapsed

 AllowSelection

 SelectionColor

 AllowHovering

 HoveringColor

Dependiendo del valor de la propiedad “BackColorStyle”, estarán disponibles otras propiedades


adicionales relacionadas con la configuración de las líneas del grid.

Si BackColorStyle = Header

 LinesBackColor

 TitleBackColor

Si BackColorStyle = Report

 LinesBackColor

 LinesBackColorEven

 TitleBackColor

Si BackColorStyle = Uniform

 BackColor

Cálculo del ancho de cada columna de un grid.

El ancho de cada columna de un grid se especifica como un porcentaje del ancho total del grid (que
por defecto no se especifica, el browser lo calcula en función al contenido de todas las celdas).
El ancho del grid NO se deduce como la suma de los anchos de las columnas, ya que si estos se
especifican en valores relativos (porcentajes), puede no corresponderse a lo deseado.

Las propiedades LinesColor, LinesFont, TitleForeColor y TitleFont:

Aplican a todas las columnas del grid, para modificar los valores correspondientes a una
determinada columna, se deben modificar las propiedades de la misma (ver más adelante).

TABLE
Los grids también tienen algunas propiedades configurables para las tablas. Estas propiedades son:

 ToolTiptext
 Align
 Background
 BorderWidth
 Cellpadding
 Cellspacing
 Rules

Propiedades modificables en ejecución

A continuación se detallan las propiedades que se pueden modificar a los grids en tiempo de
ejecución:

 Visible: si la propiedad Visible tiene el valor 0, el grid completo desaparece del formulario. No
aplica a los grids de las transacciones.
 Backstyle
 BackColor
 BackColorEven
 BackColorOdd
 PageCount
 RecordCount
 Rows
 Align
 AllowCollapsing

 AllowHovering

 AllowSelection

 BackColorStyle

 Background

 BorderColor

 BorderWidth

 CellPadding
 CellSpacing

 Class

 Collapsed

 Height

 HoveringColor

 InternalName

 Rules

 SelectionColor

 TitleBackColor

 Tooltiptext

 Width

Propiedades de las columnas del grid

También es posible indicar propiedades particulares para las diferentes columnas que forman el
grid. Para esto, se debe seleccionar la opción Columns del menú que aparece al hacer clic en el grid.
En este diálogo, seleccionando Properties sobre una columna se despliega un diálogo, como el
siguiente:
 ControlName

 Class La propiedad Class solo se encuentra disponible si el control está en el form de un


objeto que tiene un Tema asociado.

 ControlType

 InputType

 Suggest

 ReadOnly

 EnableHistory

 EmptyAsNull

 IsPassword

 Autoresize

 Font

 ForeColor

 Title

 TitleFont

 TitleForeColor

 Format

 Visible

 Tooltiptext

 ReturnOnClick
PROPIEDADES DE COLUMNAS EN TIEMPO DE EJECUCIÓN
En tiempo de ejecución se pueden modificar las siguientes propiedades de las columnas de un
grid:

 Backcolor

 Backstyle

 Enabled

 EnableHistory

 FontBold

 FontItalic

 FontName

 FontSize

 FontStrikeThru

 FontUnderline

 ForeColor

 Format

 InternalName

 IsPassword

 Link

 LinkTarget

 Title

 TitleBackcolor

 TitleBackstyle

 TitleFontBold

 TitleFontItalic

 TitleFontName

 TitleFontSize
 TitleFontStrikeThru

 TitleFontUnderline

 TitleForeColor

 TitleFormat

 Tooltiptext

 Visible

 Class

Propiedades de grids en los Temas

En la clase Grid o derivada de ella, en los Temas, es posible configurar propiedades adicionales para dicho
control. Ver Clase Grid.

Demo: Grid Estándar

Continuemos con el desarrollo de nuestro objeto MainSearch

Vamos ahora a definir el grid de los vuelos que arriban al país/ciudad seleccionado. Se quiere que
solamente cuando no se selecciona un valor para el país y/o ciudad, en el grid aparezca una columna
con esa información.

En la descripción del vuelo incluiremos un link a otro Web Panel (denominado “Flight” que
desarrollaremos más adelante, por eso definimos el nombre entre comillas para que lo considere
como objeto externo) para mostrar los detalles del vuelo.

Para esto, programaremos en el evento Load del control la propiedad link para el atributo FlightDsc.

Por defecto, GeneXus propone nombres para los controles (que sugiere según el tipo de control y la
cantidad de ese tipo que existan en el form). En muchos casos para simplificar la comprensión de la
lógica del control puede ser útil asignarles nombres más intuitivos.

Le asignaremos al control grid el nombre “Flights” y los atributos que lo componen serán la
descripción, la aerolínea y el código del país/ciudad de donde parte el vuelo, por lo tanto será un
grid con tabla base.
El evento será:

Event Flights.Load

FlightDsc.Link = Link("HFlight", FlightId)

Event Fligths.Refresh

if &CityId.IsEmpty()

ArrivalCityId.Visible = 1

else

ArrivalCityId.Visible = 0

endif

if &CountryId.IsEmpty()

ArrivalCountryId.Visible = 1

else

ArrivalCountryId.Visible = 0

endif

EndEvent // Refresh

Definiremos también las condiciones de filtro locales a este grid.

Las condiciones son:

ArrivalCountryId = &CountryId WHEN .NOT.&CountryId.isempty();

ArrivalCityId = &CityId WHEN .NOT.&CityId.Isempty();

Vea la demostración aquí


Especifiquemos el objeto y revisemos la navegación del mismo.

GeneXus navega la tabla COUNTRIES ordenada por nombre de país, para realizar la carga del combo
dinámico &CountryId. Mientas que para la carga de &CityId, recorre la tabla COUNTRIES1 ordenado
por el nombre de la ciudad y filtrando por el país seleccionado en la variable &CountryId.

Para resolver el evento Load asociado al grid Flights, GeneXus navega la tabla FLIGHTS ordenada por
número de vuelo y filtrando por el país seleccionado en la variable &CountryId (en el caso de que se
haya seleccionado uno) y por la ciudad seleccionada en la variable &CityId (en el caso de que se haya
seleccionado una).

Genere el objeto y ejecútelo para ver como funciona.

Al ejecutarlo habrá notado que si indica un valor para el país o la ciudad el dato no se muestra en la
línea del vuelo, pero el título se mantiene.
Esta es una de las principales diferencias entre los grids estándar y de tipo Free Style.

Notar que las condiciones de filtro por país y ciudad se realizan con la cláusula WHEN para
indicar que se toman en cuenta cuando las variables tengan un valor. En el caso de tener un valor
nulo, no se considera la condición por lo que se recorrerá toda la tabla.

Control Free Style Grid y sus propiedades

El grid Free Style permite al usuario definir el formato de los datos a desplegar de una forma menos
estructurada que el grid tradicional.

Puede utilizarse en los objetos con interfaz web, es decir transacciones y web panels. El grid Free
Style es básicamente una tabla a la que se le pueden insertar los atributos / variables, text blocks,
imágenes, botones, web components, embedded pages, grids Free Style y/o grids que se van a
mostrar posteriormente en la pantalla.

Este tipo de grid no posee títulos para las columnas y además permite tener más de un tipo de
control, atributo / variable en una misma celda, proporcionando de esta forma mayor libertad de
diseño.

En ejecución, el grid es una tabla HTML.

Para insertar el grid Free Style se debe utilizar el botón de la barra de controles disponibles. Se
despliega el diálogo de selección de atributos y variables que conformarán la grilla.

Propiedades del grid Free Style

Para visualizar las propiedades de un grid Free Style, hay que seleccionar la tabla del grid, presionar
el botón derecho del mouse y seleccionar la opción ‘Properties’.

A continuación se documentan las propiedades disponibles para el grid Free Style.


 Control Name

 Class La propiedad Class solo se encuentra disponible si el control está en el form de un


objeto que tiene un Tema asociado.

 BackColorStyle

 Rows

 Columns

 AllowCollapsing

 Collapsed

Dependiendo del valor de la propiedad “BackColorStyle”, estarán disponibles otras propiedades


adicionales relacionadas con la configuración de las líneas del grid.

Si BackColorStyle = Report

 LinesBackColor
 LinesBackColorEven

Si BackColorStyle = Uniform

 BackColor

Propiedades del grid Free Style modificables en ejecución

En tiempo de ejecución se puede modificar la siguiente propiedad:

 Visible: Si la propiedad Visible tiene el valor 0, el grid Free Style desaparece del formulario. En
el caso de tener grids anidados, la propiedad Visible aplicada al grid padre, aplica también a los
grids hijos.
 Align

 AllowCollapsing

 BackColor

 BackColorEven

 BackColorOdd

 BackColorStyle

 Background

 BorderColor

 BorderWidth

 CellPadding

 CellSpacing

 Class

 Collapsed

 Columns

 Height

 InternalName

 PageCount

 RecordCount

 Rows
 Rules

 Width

Propiedades del grid Free Style en los Temas

En la clase FreeStyleGrid o derivada de ella, en los Temas, es posible configurar propiedades adicionales para
dicho control. Ver Clase FreeStyleGrid.

Demo: Grid Free Style

Diseñando el Web Panel Flights

Vamos ahora a definir el Web Panel “Flights” que invocamos desde el grid de los vuelos del objeto
MainSearch para mostrar los detalles del vuelo.

Este será un Web Panel de salida (así se clasifican los Web Panels -y también los Work Panels- cuya
única función es exhibir datos).

Para que un Web Panel únicamente muestre datos, su form debe contener solamente atributos, ya
que los atributos al incluirse en Web Panels son indefectiblemente de salida. Otra posibilidad es
incluir en el form variables (sin ningún evento que las procese con el comando For Each line) y
cargarles valores explícitamente.

Mostraremos los datos básicos del vuelo, la aerolínea, el origen y el destino del mismo y también los
datos de los posibles precios.

Pondremos también las banderas de los países, para eso, usaremos variables de tipo bitmap donde
cargaremos las imágenes correspondientes.

Comencemos entonces creando un nuevo objeto de tipo Web Panel con nombre Flights.

Como recibiremos como parámetro el código del vuelo, definimos la regla parm(FlightId);

En el form incluiremos los atributos y definiremos el grid.

Usaremos una tabla para agrupar los atributos correspondientes al vuelo.


Para los precios, utilizaremos un grid Free Style, que nos de más libertad en el diseño.

Le asignaremos el nombre Prices al control y para mostrar la información en forma horizontal (y no


vertical) utilizaremos las propiedades Rows y Column.

Vea la demostración aquí


Se recomienda repasar la clasificación de los tipos de Work Panels en el material del curso
no presencial de GeneXus

Cómo trabajar con grids en Web Panels

A continuación se detalla la forma de trabajo con grids en Web Panels.

Cómo desplegar datos

Por defecto todo atributo y variable que está dentro de un grid se despliega en ejecución como
texto, es decir que son únicamente de lectura y por consiguiente no pueden ser modificados.

Cómo aceptar datos

Es posible aceptar datos en las variables de un grid dependiendo de la programación de los eventos
existentes en el objeto. Si:

1. dentro de un evento del Web Panel se está utilizando el comando For each line o For each
line in <grid>, ó

2. existe algún control en el grid con un evento clic asociado,

entonces todas las variables que están dentro del grid pasan a ser de ingreso. Es posible indicar en
este caso cuáles son las variables que no van a poder ser modificadas utilizando la regla noaccept() o
modificando la propiedad Read Only de la variable dentro del grid.

Cómo asociar eventos a una línea

Es posible asociar un evento a cualquier variable o atributo que pertenezca al grid. Se consigue de
dos maneras distintas:
1. Editando las propiedades del control, y definiendo un evento de usuario en la propiedad
OnClicEvent

2. En la sección de Eventos programando:

Event nombreControl.click

Endevent

Con esta última alternativa no tendremos que definir un evento de usuario, sino que estaremos
programando el evento clic.

Cómo seleccionar líneas

Para ello, se accede a las propiedades del grid haciendo clic en el botón derecho sobre el control grid
y se configura la propiedad AllowSelection con el valor ‘True’. Al hacerlo se habilitan tres
propiedades más, que permiten especificar SelectionColor: el color que tendrá la línea cuando el
usuario la seleccione (haciendo clic con el mouse sobre la misma); AllowHovering: la posibilidad de
que cambie el color de las líneas cuando el usuario se desplaza con el mouse sobre ellas, y
HoveringColor: el color que tendrá una línea cuando el mouse pasa sobre ella.

Demo: Cómo procesar registros en el grid

Volvamos al Web Panel MainSearch.

En el grid de los vuelos, existe una columna con una imagen que nos permite marcar el vuelo como
interesante para analizarlo más adelante en detalle y planificar así el viaje.

Para implementarlo, deberemos agregar una variable de tipo bitmap, la cual se cargará en el evento
Load del control Flights.
Agregaremos entonces en el Event Flights.Load :

&interesting = Loadbitmap("int_unsel.jpg")

Existen varias formas posibles para procesar el registro como se describió anteriormente.En este
ejemplo, programaremos el evento Click asociado a la variable:

Event &interesting.Click

call(“Interesting”, FlightId)

&interesting = Loadbitmap("int_sel.jpg")

EndEvent // &interesting.Click

Vea la demostración aquí

Como no implementaremos el procedimiento Interesting, lo hemos dejado entre comillas dobles


como invocación a un programa externo. Dicho procedimiento grabaría en una tabla los vuelos que
se han seleccionado como interesantes para que luego el usuario pueda consultar los vuelos que le
han resultado de interés.

Paginado de grids en Web Panels

En ambiente web, los datos resultado de una consulta a la base de datos que se devuelven en un
grid se trasforman en texto html y ocuparán tantas líneas como resultados.

Tanto por temas de usabilidad, de performance o de tamaño de la página HTML generada, puede ser
conveniente desplegar los resultados en un grid de tamaño fijo y permitir con botones de
movimiento la navegación entre las páginas de los mismos. Nos referimos a esto como paginación
del grid.
Para esto, se dispone de métodos asociados al control Grid, los que aplican cuando la propiedad
‘Rows’ del grid tiene un valor diferente de cero.

Aplica a ambos tipos de grids estándar y free style y también cuando los grids están anidados.

Existen algunas diferencias relacionadas con la paginación cuando un grid tiene tabla base o no.
Cuando el grid no tiene tabla base, no está disponible el método Last Page ni GotoPage.

Métodos

A continuación se describen los métodos disponibles:

FIRSTPAGE
El método FirstPage lleva al usuario al primer conjunto de registros devueltos.

Los valores devueltos por este método son los siguientes:

0: Operación exitosa

1: No está habilitado el paginado en el grid

Ejemplo

Event Enter

MyGrid.FirstPage()

Endevent

En este ejemplo cuando el usuario presiona el botón asociado al evento enter, en el grid se
mostrará el primer conjunto de registros.

NEXTPAGE
El método NextPage lleva al usuario al siguiente conjunto de registros.

Los valores devueltos por este método son los siguientes:


0: Operación exitosa
1: No está habilitado el paginado en el grid
2: Ya se encuentra en la última página.

Ejemplo

Event Following.Click

&err = MyGrid.NextPage()

if &err = 2

Message.Caption = ‘You already are in the last page’

endif

Endevent

En este ejemplo cuando el usuario presiona el botón Following, en el grid se mostrará el


siguiente conjunto de registros. En el caso que ya esté cargada la última página, se muestra
el mensaje ‘You already are in the last page’ en el textblock Message.

PREVIOUSPAGE
El método PreviousPage lleva al usuario al conjunto anterior de registros.

Los valores devueltos por este método son los siguientes:

0: Operación exitosa
1: No está habilitado el paginado en el grid
2: Ya se encuentra en la primera página

Ejemplo

Event Back.click

&err = MyGrid.PreviousPage()

if &err = 2

Message.Caption = ‘You already are in the first page’

endif

Endevent

En este ejemplo cuando el usuario presiona el botón Back, en el grid se mostrará el conjunto
de registros anterior y en el caso que ya esté cargada la primer página se muestra el mensaje
‘You already are in the first page’ en el textblock Message.
LASTPAGE
El método LastPage lleva al usuario al último conjunto de registros. Puede ser utilizado únicamente
si el grid tiene tabla base.

Los valores devueltos por este método son los siguientes:

0: Operación exitosa
1: No está habilitado el paginado en el grid
3: El grid no tiene tabla base

Ejemplo

Event Last.click

MyGrid.LastPage()

Endevent

En este ejemplo cuando el usuario presiona el botón Last, en el grid se mostrará el último
conjunto de registros.

GOTOPAGE
El método GotoPage(PageNumber) permite acceder en forma directa a un determinado conjunto de
registros. Puede ser utilizado únicamente si el grid tiene tabla base.

Los valores devueltos por este método son los siguientes:

0: Operación exitosa
1: No está habilitado el paginado en el grid

Ejemplo

En este ejemplo, dado el grid (GSearchResults) con el resultado de una búsqueda, y otro grid
(GPages) con el número de páginas de la primera para permitir un acceso más rápido de
paginado.

Event Refresh

&PageCounts = GSearchResults.PageCount

EndEvent
Event GPages.Load

if &PageCounts > 1

&Count = 1

Do while &Count <= &PageCounts

&PageNumber = &Count

SFPages.Load()

&Count += 1

enddo

endif

EndEvent

Event &PageNumber.Click

GSearchResults.GotoPage(&PageNumber)

EndEvent

Resumen

A continuación se incluye una tabla con un resumen de los métodos disponibles cuando un grid tiene
tabla base y cuando no.

Grid con tabla base Grid sin tabla base

FirstPage  
NextPage  
PreviousPage  
LastPage  
GoToPage  

Propiedades

Cada grid dispone de las siguientes propiedades que son utilizadas en la paginación:
 RecordCount

 PageCount

Consideraciones

 Si el web panel que se está paginando tiene filtros, se debería agregar el método FirstPage
dentro del evento que aplica el filtro, a los efectos de evitar que el resultado desplegado
corresponda a la página en la que se encontraba anteriormente.

 La eficiencia de los métodos FirstPage, NextPage, PreviousPage y GotoPage( N) está


asociada a la eficiencia de la definición de la navegación del grid correspondiente. En otras
palabras, si el grid, sin paginado tiene buenos tiempos de respuesta, los tiempos con
paginado serán semejantes.

 El método LastPage determina cuál sería la última página, para lo que utiliza la propiedad
Rows y la propiedad RecordCount del grid. El hecho de utilizar la propiedad RecordCount
implica que el DBMS (no el código generado) barre dos veces la tabla base del grid (la
primera vez para contar y la siguiente para "cargar").

 El método LastPage ha sido pensado para que se ejecute un único comando Load por cada
registro de la tabla base. Por ello, si existen IFs en el evento Grid.Load que pueden
condicionar la ejecución del comando mencionado o se ejecuta más de una vez el método
Load por cada registro, los resultados pueden ser inesperados.

Implementación

El paginado se realiza por "número de registro". Esto quiere decir que, la página 1 tendrá los
registros del 1 al valor de la propiedad Rows, la página 2 los que van del Rows +1 al Rows * 2 y así
sucesivamente. Para mostrar la página 2, internamente, se "pasa por" los registros de la página 1 sin
mostrarlos. En general, para mostrar la página N, se "pasa por" los registros de las páginas anteriores
(N-1) sin mostrarlos.

Dada la implementación, se recomienda:

1. Tener un buen filtrado de datos (de forma que no existan muchas páginas)
2. Evitar, cuando el costo sea alto, el uso de GotoPage( N) con valores altos de N, así como el
uso de LastPage.

3. También se recomienda salvar el valor de la propiedad RecordCount en una variable ya que


cada invocación de la propiedad implica un COUNT en la base de datos.

Ejemplo

Los métodos de paginado de grids pueden ser utilizados en los eventos escritos por el usuario. Por
ejemplo:

Event Start

&Count = MyGrid.RecordCount

If &Count > MyGrid.Rows

Pagina2.Visible = 1

EndIf

If &Count > MyGrid.Rows * 2

Pagina3.Visible = 1

EndIf

Endevent

Event Siguiente.Click

MyGrid.NextPage()

Endevent

Event Anterior.Click

MyGrid.PreviousPage()

Endevent
Event Enter

MyGrid.FirstPage()

Endevent

Demo: Paginación de grids

En el grid de vuelos, se quieren cargar de a 5 vuelos a la vez.

Para eso debemos modificar la propiedad Rows del grid y asignarle 5 como valor. Además, para
permitir la navegación entre todos los registros (las típicas acciones de ir a la primer página, a la
anterior, a la siguiente y a la última), vamos a incluir imágenes en el formulario programando su
comportamiento en el evento clic de cada una.

Definiremos entonces las variables de tipo Bitmap &first, &previous, &next y &last a las cuales les
asociaremos la imagen correspondiente en el evento start y luego en el evento click de cada una de
ellas programaremos el método de paginación del grid correspondiente.

El código que se ejecutará cuando el usuario haga clic sobre cada una de las imágenes será el
siguiente:

Event &first.Click

Flights.FirstPage()

EndEvent // &first.Click

Event &previous.Click

Flights.PreviousPage()

EndEvent // &previous.Click

Event &next.Click

Flights.NextPage()

EndEvent // &next.Click
Event &last.Click

Flights.LastPage()

EndEvent // &last.Click

Es decir: Flights.FirstPage(), Flights.LastPage()

Además cuando “modifiquemos” los valores de las variables &CountryId y &CityId de la parte fija,
vamos a presionar el botón de Buscar (“Search”) queriendo que se carguen los primeros 5 vuelos
que cumplen con los nuevos valores de las variables. Para esto, vamos a tener que programar en el
evento asociado al botón de Buscar lo siguiente:

Event Enter

Flights.FirstPage()

EndEvent // Enter

Vea la demostración aquí

Si el evento de Buscar no tiene al evento Enter asociado, esta lógica deberá estar en el evento
de usuario definido.

Web Panels con más de un grid

Cuando un web panel contiene más de un grid en su form, GeneXus no determina una única tabla
base asociada al web panel, sino una tabla base asociada a cada grid.

Es decir, GeneXus determina para cada grid una navegación independiente. Puede verse una
analogía entre un web panel con varios grids y un reporte con for eachs paralelos.
A continuación mostramos un ejemplo:

Dado que el web panel “View Users & Service Providers” tiene más de un grid en su form, GeneXus
no determinará una tabla base asociada al web panel, sino que determinará una tabla base para
cada grid.

Los atributos que participan en la determinación de la tabla base de cada grid son:

 los incluidos en el grid (se tienen en cuenta tanto los atributos visibles como los ocultos)

 los referenciados en Order y Conditions locales al grid

Los atributos de la parte fija del web panel no participan en la determinación de la tabla base de
ninguno de los grids, pero deberán pertenecer a la tabla extendida de alguno de ellos (para que sea
posible inferir sus valores). De no respetarse esto, al especificar al web panel, se mostrará en el
listado de navegación resultante, el warning: “Attribute not instantiated”.

Los atributos utilizados en los eventos del web panel tampoco participan en la determinación de la
tabla base de ninguno de los grids. Los atributos que se incluyan en los eventos fuera de comandos
for each, deberán pertenecer a la tabla extendida de alguno de los grids.
En el ejemplo, no hay definidos ni Order ni Conditions para ninguno de los grids, por lo que la tabla
base del grid que se encuentra arriba en el form será: USERS y la tabla base del grid que se
encuentra abajo en el form será: RATES.

Es importante resaltar que GeneXus determina la tabla base de cada grid, pero no busca ni establece
relaciones entre las mismas.
Al igual que en el web panel recientemente visto, si se define el siguiente web panel:

GeneXus determinará la tabla base del primer grid (que será USERS) y la tabla base del segundo grid
(que será COUNTRIES), pero no analizará si hay atributos en común entre ellas, y por ende no
definirá filtros automáticos. Es decir que los grids tendrán asociadas navegaciones independientes o
paralelas.

Si bien GeneXus no establece relaciones entre las tablas bases de los grids, el analista podrá definirlo
explícitamente. Primero estudiaremos los eventos en web panels con más de un grid, y a
continuación veremos cómo definir cargas relacionadas.

Eventos en Web Panels con más de un grid

En web panels con más de un grid, existe un evento Refresh global y un evento Refresh particular
para cada grid.

El evento Load, no existe global sino sólo a nivel de cada grid.

Los eventos Refresh y Load a nivel de grids, deben referenciar al grid usando la siguiente
nomenclatura:
Event <Subfile Control Name>.<Refresh | Load>

....

EndEvent

Por ejemplo, si en el último web panel visto, los nombres de los grid son GridUsers y GridCountries
respectivamente, para codificar los eventos Refresh y Load a nivel de los grids, la sintaxis deberá ser:

Event GridUsers.Refresh

....

EndEvent

Event GridUsers.Load

....

EndEvent

Event GridCountries.Refresh

....

EndEvent

Event GridCountries.Load

....

EndEvent

Además de estos eventos a nivel de los grids, estará el evento Refresh global:

Event Refresh

....

EndEvent
Cada vez que se ejecute cualquiera de las acciones que provocan que se ejecute el evento Refresh,
se ejecutará:

Refresh // (el genérico)

GridUsers.Refresh

GridUsers.Load

GridCountries.Refresh

GridCountries.Load

De esta manera, cada uno de los grids se cargará con los datos correspondientes.

El comando LOAD mantiene la misma sintaxis en web panels con más de un grid. Se debe incluir al
mismo para hacer cargas de grids sin tabla base, dentro del evento Load de un grid.

Cómo definir cargas relacionadas en Web Panels con más de un grid

Dadas las transacciones “Country” y “Cities” definida en una base de conocimiento:


Definiremos un web panel que muestre en un grid a todos los países (GridCountries), y cada vez que
el usuario seleccione un país, se cargarán sus ciudades en un segundo grid (GridCities).
Para asociar cargas, se deben definir grids con variables:

De modo que los grids “no tendrán tabla base” y en consecuencia el evento Load de cada grid, se
ejecutará una sóla vez.

A continuación detallamos el código que definimos para resolver las cargas:

Event GirdCountries.Load

For each

&CountryId=CountryId

&CountryName=CountryName

Load

Endfor

Endevent

Event GridCities.Load
For each

where CountryId=&CurrentCountryId

&CityId=CityId

&CityName = CityName

Load

endfor

Endevent

Luego codificamos el evento Enter asociado al botón “View cities”:

Event Enter

&currentCountryId = &CountryId

Endevent

Consideraciones

 Es posible especificar condiciones de filtro tanto a nivel global como a nivel de cada grid.
Para cada grid, se tendrán en cuenta las condiciones globales y las condiciones locales (es
decir: condiciones globales “and” condiciones locales).

 De necesitarse utilizar al comando For each line en un web panel con más de un grid, se
deberá incluir una referencia al grid con la siguiente sintaxis:

For each line IN <Grid Control Name>

Endfor

 No es posible nombrar a un atributo o variable de un grid determinado. Por ejemplo, no es


posible referirse a:
GridUsers.CountryId

GridCountries.CountryId

Sí podemos referirnos a CountryId y por ejemplo codificar sus propiedades, eventos y


métodos (por ejemplo, definir en algún evento la siguiente sentencia: CountryId.Visible=0).

De todos modos no se recomienda tener al mismo atributo / variable en más de un grid, ya


que las codificaciones que se le hagan, afectarán a todos los grids en los que se encuentre. Es
decir, si el atributo CountryId perteneciera a más de un grid, al ejecutarse la línea de código:
CountryId.Visible=0, el atributo CountryId quedaría invisible en todos los grids.

Demo: Múltiples grids en un Web Panel

Continuemos avanzando con el desarrollo de nuestro objeto MainSearch

Lo que nos quedaría por hacer en este Web Panel es desplegar la bandera y el resumen del "Destino
del Mes" y un grid con las ciudades del mismo.

Recordemos cómo es que dijimos que queríamos que apareciera el formulario en ejecución …
Lo primero que debemos hacer para poder mostrar el país del mes es agregar una celda a la derecha
de la celda donde filtramos por país/ciudad. La forma más sencilla de hacerlo es clic con el botón
derecho, y seleccionar la opción “Split Cell”. Una vez realizado este cambio es necesario modificar el
valor de la propiedad “Colspan” de la celda superior a 3, ya que ahora la misma debe abarcar 3
celdas en lugar de 2.

Para simplificar el desarrollo suponemos que el país del mes es el de código “URU”, entonces
podemos cargar la bandera y el resumen del mismo en el evento Start.

Definiremos las variables &MonthlyCountryFlag - de tipo bitmap -y &MonthlyCountryDetails basada


en el atributo correspondiente.

Por otro lado, vamos a tener que crear un grid con las ciudades del país del mes . Para eso el
nombre de la ciudad será la única columna del grid y en las condiciones locales al mismo definiremos
el filtro por el país del mes.

Podemos definir un grid estándar que tenga como título de la columnas Cities.

Para que no se vean en ejecución los bordes donde se carga el resumen del país del Mes, a la
variable correspondiente se la debe definir como ReadOnly.

Vamos entonces a hacer estos cambios a la aplicación…

Haga clic aquí para ver la demostración

Como no se asigna un nombre al grid, el control name correspondiente será Grid1. Se sugiere
que de todos modos se asigne el nombre Cities al control para facilitar luego la lectura del código y
también de la navegación del objeto.

Grids anidados

Es posible definir grids 'anidados' en un web panel.


Los grids anidados consisten en un grid Free Style al que se puede insertar dentro de una celda otro
grid. Cada grid puede ser un Free Style o un grid estándar, aunque si es estándar no puede tener
ninguno anidado.

Puede haber grids anidados de varios niveles y puede haber también paralelos.

Puede decirse que se está definiendo un árbol en donde cada nodo es un grid.

Los grids comunes solo pueden ser hojas del árbol de anidación.

Por ejemplo, se quiere tener un web panel que muestre los poveedores de servicios, pero
indentados por categoría:

Hoteles

Hotel Colonia

Hotel Oceanía

Transport

Alfa Travel

OtherWorld Travel

...

Para ello se define un grid Free Style con la categoría y dentro de este se inserta otro grid con los
poveedores de servicios (podría ser un grid estándar o Free Style).

Determinación de tablas bases

Los grids anidados cumplen las mismas reglas de relacionamiento que si fueran For Eachs anidados.
Por lo tanto, GeneXus determina la tabla base de cada grid (no son por completo independientes: en
la determinación de la tabla base del anidado influirá la del principal).

Luego, a partir de esas determinaciones, define las navegaciones que realizará para cada grid. La
lógica de los grids dependerá de las relaciones que encuentre entre las tablas determinadas.
Si no tiene tabla base, se deben cargar los datos con el comando Load.

Disparo de Eventos

Cada grid mantiene sus eventos load y refresh particulares.

Cada vez que se ejecuta el comando Load en un grid con anidaciones, se llama al evento Refresh y load de
cada hijo.

Demo: Grids Anidados en un Web Panel

Continuemos con el desarrollo de nuestro objeto MainSearch

Para mostrar las atracciones turísticas del país/ciudad seleccionado, debemos implementar grids
anidados.

El grid padre tendrá la categoría de las atracciones y en el grid anidado las atracciones en sí.

En caso de que no se seleccione un país, se mostrarán las atracciones del país del mes. Además
como no se referencia a la ciudad estarán todas las atracciones de las ciudades del mismo.

Agregamos entonces un grid Free Style (de nombre Attractions), donde colocamos el atributo
TouristAttractionCatDescription, CountryId y una variable bitmap para cargar la imagen correspondiente
(almacenada en el atributo TouristAttractionCatImage) y dentro de este grid colocamos otro (también de tipo
Free Style y de nombre Attraction) para desplegar la información de la atracción turística.

Suponiendo que el país del mes es Uruguay, en el grid Attractions, agregaremos las siguientes conditions:

CountryId = &CountryId WHEN .NOT.&countryid.IsEmpty();


CountryId = "URU" WHEN &countryid.IsEmpty();

Como vimos anteriormente el grid puede ser estándar o Free Style, en este caso elegimos un grid Free Style
simplemente por el modo en que esta página va a ser diseñada.

Haga clic aquí para ver la demostración

Grids en transacciones con form HTML

El botón que se encuentra en la barra de controles y permite insertar el control grid.


Al igual que en los Web Panels, el grid es en ejecución una tabla HTML.

Las columnas pueden ser atributos o variables (incluyendo las de tipo bitmap). El comportamiento
de los atributos y variables en un grid en una transacción es diferente al descrito en los Web Panels.

Como desplegar datos en un grid

En ejecución, los atributos que se encuentran en el formulario de una transacción son de ingreso,
por lo tanto lo mismo aplica a aquellos que se encuentran dentro de un grid. Si se quiere modificar el
comportamiento por defecto, es decir no se desea el ingreso de un atributo, entonces se puede
utilizar la regla noaccept(Att) o la propiedad Read Only de la columna.

Las variables que se colocan en una transacción son de sólo lectura.

Nuevamente en este caso, se despliegan en el grid todos los registros ingresados en la transacción,
pero en el caso de transacciones no se puede programar paginación a pedido, por lo que de ser
necesario, se aconseja el uso de un Web Panel para el ingreso de información.

Como aceptar datos en un grid

En el caso de las transacciones, el grid despliega por defecto 5 líneas de ingreso, este valor puede ser
modificado por el usuario utilizando las propiedades del mismo (Ver Propiedades del grid). Esto
significa, que siempre se despliegan x filas adicionales a los registros ya ingresados en la tabla.

Como se menciona anteriormente, los atributos en una transacción son de ingreso, por lo tanto no
es necesario realizar ninguna modificación.

Para poder ingresar valores en variables, es necesario utilizar la regla accept(&Var) para modificar el
comportamiento por defecto.

INTRODUCCIÓN

En este capítulo veremos los conceptos de Web Component y Embedded Page (página embebida).
El primero nos permite la reutilización de lógica entre los objetos y el segundo permite incluir dentro
de sitios diseñados con GeneXus páginas de terceros.

Incluiremos también en nuestra aplicación práctica un Web Component.

Web Components

Los Web Components permiten a los diseñadores de aplicaciones GeneXus Web un alto grado de
reutilización de los mismos.

Son objetos web que tienen una propiedad en la cual se indica que son componentes. Es decir,
pueden ser ejecutados en forma independiente (como cualquier otro objeto web) o pueden formar
parte de otro objeto web (Web Panel o Web Transaction).

Cualquier parte de un objeto web que se repita en varios objetos de una aplicación web, puede ser
definida como Web Component.

Los ejemplos más comunes son: menús, login, área que permite la personalización, etc.

La idea entonces es, en lugar de tener implementado, por ejemplo, la carga del menú en cada uno
de los objetos web que requieren el mismo, programarla en un Web Component y reutilizarlo en
cada Web Panel que requiere un menú.

Cómo definir un Web Component

Para definir un objeto web como Web Component se debe configurar la propiedad “Type” (antes
Web Component) con el valor “Component”. De esta forma, se habilita la propiedad “URL access”.
La cual puede tomar los siguientes valores:

 Yes: permite que el objeto sea ejecutado desde la URL.

 No: no permite que el objeto sea ejecutado desde la URL.

Se debe notar que un objeto web definido como Web Component no pierde ninguna de sus
características, por lo tanto, puede ser ejecutado en forma autónoma.
Los Web Components se generan dentro del mismo HTML del Web Panel que los contiene. Esto
significa que el servidor resuelve la inclusión del Web Component en tiempo de ejecución y devuelve
al navegador el código HTML con el Web Component ya incluido.

Uso de Web Components

Para insertar un control Web Component en un Web Panel o Web Transaction se debe elegir la

opción Insert / Web Component, o la opción de la barra de controles, con lo cual se creará un
control de tipo ‘Web Component’ en el objeto.

Además, se pueden insertar Web Components en grids free style.

Para determinar el objeto que se va a desplegar en lugar del control Web Component, se utilizan las
propiedades del mismo. El objeto web a desplegar se puede fijar en diseño o en tiempo de
ejecución, como se describe a continuación.
PROPIEDADES MODIFICABLES EN DISEÑO
El control Web Component tiene las siguientes propiedades de diseño:

 ControlName: Nombre del control.

 Object: Permite asociar un objeto web al Web Component. Sólo se aceptan objetos con la
propiedad “Type” en “Component”.

 Parameters: Permite especificar la lista de parámetros con los que se invocará el Web
Component.

PROPIEDADES MODIFICABLES EN EJECUCIÓN


A continuación se detallan las propiedades de los Web Components que se pueden modificar en
tiempo de ejecución:

 Object: permite determinar en tiempo de ejecución qué Web Panel o Transacción se va a


desplegar en el lugar del control.

Sintaxis

Control.Object = Create(Wxxx, [par1], ... [parn])

Donde:
Wxxx
Es el Web Panel o Transacción al que se le ha configurado la propiedad “Type” en “Component”.

[par1], ... [parn]


Son los parámetros recibidos por el mencionado objeto.

 Visible: determina si el control Web Component está visible o no.

Sintaxis:

Control.Visible = Value

Valores:

0: False. El control no se muestra en el form.


1: True. El control se muestra en el form.
Web Components dinámicos

Como lo demuestra la sintaxis, es posible dinamizar los Web Components, es decir que el contenido
de un Web Component sea variable. Por ejemplo:

&variable = ‘HMenu’

Comp1.Object = Create(&variable)

En el momento de hacer el Create (al ejecutar) GeneXus busca qué nombre de objeto (de los que
tengan definida la propiedad “Type” en “Component”) es igual al valor de la variable, si lo encuentra,
evalúa que coincidan los parámetros (cantidad y tipo), si no encuentra el objeto el espacio del Web
Component queda en blanco al ejecutar el Web Panel que lo contiene.

Esto implica que si se agrega un componente al modelo y el mismo será llamado de forma dinámica,
basta con generar y compilar el componente mismo.

Estos objetos se verán además en el object browser como objetos llamados.

Observaciones

En diseño, el tamaño del Web Component permanece fijo, pero en ejecución, el tamaño quedará
sujeto al espacio ocupado por el mismo. La forma de fijar el tamaño del Web Component en
ejecución es entonces incluyéndolo en una tabla y fijando el tamaño de la celda.

Un Web Component puede a su vez contener otros Web Components.

La asignación de un Web Component puede realizarse dentro de cualquier evento del Web Panel
‘padre’.

Si se asigna un Web Component en el evento Start del padre, los parámetros se pasarán solamente
la primera vez que se crea. En sucesivos POST, los parámetros se recordarán del render anterior.

Si se asigna un Web Component en cualquier otro evento (Refresh, Load, de usuario, etc.), los
parámetros se pasarán siempre que se ejecute dicho evento.

Si se asigna el objeto web en la propiedad Object del control Web Component en diseño, el pasaje
de parámetros se realiza en forma análoga a lo descrito en el punto anterior.
Los controles y las variables de los Web Components no son accesibles por los objetos que los
contienen (objeto web ‘padre’). Si por ejemplo se desea que un campo del Web Component tenga
un color determinado por el padre, se le tendrá que pasar por parámetro el color y asignarlo en el
evento Start del Web Component.

En ejecución, las propiedades del form del Web Component son heredadas del objeto web que lo
contiene. Por ejemplo si el form de un Web Component tiene color verde, pero el form del objeto
web que lo contiene tiene color blanco, entonces este último predominará sobre el primero. No es
así con las propiedades de los demás controles.

No se soporta el uso de atributos como primer parámetro de la función Create.

Ejecución de objetos web con Web Components


A continuación se describe la ejecución de objetos web que contienen Web Components.

Web Components en área plana del objeto Web

ORDEN DE EJECUCIÓN DE LOS EVENTOS


Se pueden diferenciar dos instancias al ejecutar un objeto web que incluye un Web Component: primera
llamada al objeto web (GET) y disparo de un evento en el objeto (POST).

Primer llamada (GET)


El orden de ejecución de los eventos al realizar la primer llamada al mismo (GET) es el siguiente:
1. Evento START del objeto web que contiene el Web Component (objeto web ‘padre’),
2. Evento REFRESH del objeto web ‘padre’,
3. Evento START de todos los Web Components dentro del objeto web que no están dentro de
grids,
4. Eventos REFRESH y LOAD de cada uno de los Web Components y de los grids en el orden que
aparecen en pantalla (de arriba a abajo y de izquierda a derecha).

Ejemplo:

En la siguiente figura, se puede observar un Web Panel que contiene 2 Web Components (A y B) y un grid.
Cada Web Component tiene a su vez un grid.
En este caso el orden de los eventos cuando se ejecuta por primera vez es el siguiente:

1. Evento START del Web Panel


2. Evento REFRESH del Web Panel
3. Evento START del Web Component A
4. Evento START del Web Component B
5. Evento REFRESH del Web Component A y evento LOAD del grid en el Web Component A
6. Evento LOAD del grid del Web Panel
7. Evento REFRESH del Web Component B y evento LOAD del grid en el Web Component B

Disparo de un evento (POST)


Al disparar un evento, el orden de los eventos depende de si se disparó el evento en el objeto web ‘padre’ o
en un Web Component. A continuación se analizan ambos casos.

Nota: La lectura de variables de cada objeto se realiza siempre inmediatamente después del evento Start de
dicho objeto.

Disparo de un evento de un Web Component

1. Evento START del objeto web ‘padre’


2. Evento START del Web Component cuyo evento se disparó
3. Evento de usuario del Web Component
4. Evento REFRESH del objeto web ‘padre’
5. Evento START de los Web Components restantes
6. Eventos REFRESH y LOAD cada uno de los Web Components y grids en el orden que aparecen
en pantalla.

En el ejemplo, si se dispara un evento del Web Component A, el orden de los eventos sería el siguiente:

1. Evento START del Web Panel


2. Lectura de variables del Web Panel
3. Evento START del Web Component A
4. Lectura de variables del Web Component A
5. Evento de usuario del Web Component A
6. Evento REFRESH del Web Panel
7. Evento START del Web Component B
8. Lectura de variables del Web Component B
9. Evento REFRESH del Web Component A y evento LOAD del grid en el Web Component A
10. Evento LOAD del grid del Web Panel
11. Evento REFRESH del Web Component B y evento LOAD del grid en el Web Component B

Disparo de un evento en el objeto web ‘padre’:

1. Evento START del objeto web ‘padre’


2. Evento de usuario del objeto web ‘padre’
3. Evento REFRESH del objeto web ‘padre’
4. Eventos START de todos los Web Components en el orden que se encuentran en pantalla
5. Eventos REFRESH y LOAD de los Web Components y grids en el orden que aparecen en
pantalla.

En el ejemplo, al dispararse un evento del Web Panel, el orden de los eventos sería el siguiente:

1. Evento START del Web Panel


2. Lectura de variables del Web Panel
3. Evento de usuario del Web Panel
4. Evento REFRESH del Web Panel
5. Evento START del Web Component A
6. Lectura de variables del Web Component A
7. Evento START del Web Component B
8. Lectura de variables del Web Component B
9. Evento REFRESH del Web Component A y evento LOAD del grid en el Web Component A
10. Evento LOAD del grid del Web Panel
11. Evento REFRESH del Web Component B y evento LOAD del grid en el Web Component B

Nota: si el objeto web tiene más de un grid, primero se ejecuta el Refresh independiente de los grids y luego
el refresh de cada uno de los grids en el orden en que aparecen en pantalla.

Web Components en grid free style

ORDEN DE EJECUCIÓN DE LOS EVENTOS


En caso de haber Web Components en grids, se ejecuta el evento Start del Web Component justo antes del
evento Refresh en vez de ejecutarse al principio.

Todos los eventos del Web Component (Start, Refresh y Load si tiene grids) se ejecutan cada vez que
aparece el Web Component.

Consideraciones de diseño para la optimización de Web


Components

A continuación se describen algunos puntos a considerar para el diseño de páginas Web con
GeneXus y Web Components para lograr una optimización del código HTML generado:

USO DE LA FUNCIÓN CREATE


Evitar el uso de la función Create y por lo tanto especificar, siempre que sea posible, el nombre del Objeto
Web Component en las propiedades del Control Web Component.

Cuando se utiliza la función Create (especificando un objeto o una variable) los generadores tienen que
incrementar el código HTML generado para saber cuál fue el nombre del Objeto Web Component que se
utilizó.

El incremento en el código HTML por utilizar Create es relativamente menor. De todas formas, en páginas con
muchos Web Components y/o con Web Components dentro de grids, puede sumar varios KBytes más a la
página.

EVITAR EL USO DE LA FUNCIÓN CREATE CON UNA VARIABLE


En algunos generadores el Create con una variable es transformado, por el especificador, en un DO CASE con
Creates "fijos" (con nombre de objeto) basándose en los parámetros especificados.

Resulta evidente que el DO CASE puede incluir Creates de Web Components que nunca van a ser llamados
(porque no son necesarios en la lógica del programa) y entonces nos encontraríamos en la misma situación
del punto anterior.

UTILIZAR TEXT BLOCKS EN LUGAR DE VARIABLES SIEMPRE QUE SEA POSIBLE


Un Text Block tiene menos funcionalidad que una variable. Sin embargo, en la medida en que la
funcionalidad adicional no sea necesaria es recomendable utilizar un Text Block en lugar de una
variable ya que el código HTML generado para un Text Block es normalmente menor (en algunos
casos la mitad) que el de una variable. Es importante notar que la cantidad de código HTML
generado depende del contenido de la variable o del valor de la propiedad Caption de un Text Block.
Un ejemplo de esto es la inclusión de código HTML escrito por el usuario en las páginas generadas. Es muy
recomendable utilizar Text Blocks en este caso.

ELIMINAR ATRIBUTOS/VARIABLES QUE NO ESTÉN SIENDO UTILIZADOS EN LA


PANTALLA

Genera menos código HTML un atributo/variable que no está en el form que uno que sí está pero
tiene la propiedad Visible en cero. Ninguno de los dos se "ve" en la página generada.

Demo: Definir un Web Component

Lo que vamos a hacer ahora es definir el Web Panel Login que tenemos desarrollado para indicar
que el mismo es un Web Component. Para esto, configuraremos la propiedad “Type” en
“Component”.

Haga clic aquí para ver la demostración

Más adelante incluiremos este componente en la Master Page.

Embedded Pages

Definición

El objetivo de las páginas embebidas o ‘Embedded Pages’ es poder incluir información externa; es
decir desplegar el contenido de cualquier URL en objetos web generados por GeneXus.

Una ‘Embedded Page’ es un control que se puede insertar en un Web Panel o Web Transaction. A
este control se le puede asociar cualquier página u objeto web GeneXus, cuyo contenido luego será
incluido en ejecución dentro del objeto.

El uso de Embedded Pages brinda a los usuarios GeneXus la siguiente posibilidad de incluir
información externa: permite que se incluyan páginas estáticas o dinámicas de la propia aplicación o
desarrolladas por terceros.

Dichas páginas pueden estar en el mismo servidor que la aplicación o en otro servidor. Esta
característica brinda gran dinamismo a las aplicaciones web desarrolladas con GeneXus.
Generación

Las Embedded Pages se generan como un ‘inline frame’ en el HTML final. Al ejecutar el objeto que
contiene una Embedded Page, el browser se encarga de realizar el requerimiento de la página
asociada y de incluirla dentro del inline frame.

Uso de Embedded Pages

Para insertar una Embedded Page en un objeto web se debe seleccionar la opción Insert /
Embedded Page, con lo cual se creará un control de tipo Embedded Page.

También es posible insertarla con un solo clic en el ícono de la barra de controles.

Orden de los eventos

Como se mencionó anteriormente la Embedded Page es una página totalmente independiente del
objeto web que la contiene, por consiguiente, si se utiliza un objeto GeneXus en una Embedded
Page, los eventos de éste y del contenedor se dispararán en forma independiente y no es posible
establecer a priori cuándo se ejecutan los de uno con relación a los del otro.

Requerimientos

Para poder visualizar objetos web que contienen Embedded Pages, se requieren browsers que
soporten el tag correspondiente al ‘inline frame’ (<IFRAME>). En consecuencia, el browser (en el
cliente) debe ser como mínimo Internet Explorer 4.0, Netscape 6.0 o versiones superiores.

Propiedades

El control Embedded Page tiene las siguientes propiedades:


 ControlName: Nombre del control.

 BorderStyle

 Scrollbars

 Source

 TooltipText

 Height
 Width

 Align

PROPIEDADES MODIFICABLES EN EJECUCIÓN


A continuación se detallan las propiedades modificables en tiempo de ejecución:

 BorderStyle
 TooltipText
 Source
 Visible
 Height
 Width
 HeightUnit
 WidthUnit

Nota: La propiedad TooltipText no funciona en Internet Explorer 6.0 o menor. Sí funciona en


Netscape 6.0 o superior.
Observaciones

Si en las propiedades del control no se especifica la propiedad Source, entonces en el evento Start o Refresh
se debe asignar algún valor a la misma.

Por ejemplo:

MyPage.Source = “http://www.genexus.com”, siendo MyPage el nombre del control Embedded Page.

Se permite la asignación dinámica de URLs.

Por ejemplo:

&url = “http://www.genexus.com”
MyPage.Source = &url

Se pueden incluir Embedded Pages dentro de grids free style.

Demo: Embedded Page

Continuemos con el desarrollo de nuestro objeto MainSearch

Vamos ahora a definir una página embebida para mostrar propaganda.

Para esto, en el objeto MainSearch agregaremos debajo de la tabla que contiene a los restantes
objetos un control Embedded Page. Para lo cual, deberemos ir al menú Insert / Embedded Page.

Una vez creado el control en la propiedad “Source” incluiremos la siguiente URL:

www.uruguaynatural.com.

Vea la demostración aquí

INTRODUCCIÓN

En este capítulo continuaremos viendo formas de reutilizar lógica en el desarrollo de las aplicaciones
Web.

La finalidad continúa siendo que la creación y el mantenimiento de páginas Web asegure


consistencia con la totalidad del sitio.
La Master Page permite centralizar el diseño y el comportamiento en un solo objeto y reutilizarlo en
otros objetos sin requerir programación.

Definiremos también en nuestra aplicación práctica una Master Page.

Definiendo una Master Page

Una Master Page es un Web Panel con la propiedad “Type” en “Master Page”. En una misma base de
conocimiento se pueden definir tantas Master Pages como se desee.

Una vez que exista al menos una Master Page en la base de conocimiento, puede ser referenciada
desde cualquier Web Panel o Transacción Web, para ser utilizada por este objeto de modo de ser
cargado con ese marco o contexto.

De esta forma, el objeto referenciado hereda todo el layout y comportamiento de su Master Page.

Para poder cargar cualquier objeto web con el marco especificado por la Master Page, se creó un
nuevo control llamado “Content Placeholder”. Este control define en qué lugar, dentro de la Master
Page, estará ubicado el contenido de las Transacciones Web y los Web Panels que la utilizarán como
su página maestra.
Tal como lo ilustra la figura anterior, se define un Web Panel para oficiar de página maestra, es decir,
de la página que contendrá el layout y comportamiento genérico del sitio.

Esa página tendrá un Web Component para cargar el Header que deseemos darle a todas las páginas
del sitio, otro para el menú, y luego tendremos el “hueco” donde querremos que cada página
particular del sitio sea cargada.

A cada una de esas páginas individuales que conforman en conjunto el contenido del sitio, habrá que
configurarles en su propiedad “MasterPage” el nombre de la página maestra que creamos antes,
para que cuando sean ejecutadas, lo sean con el “marco” dado por la Master Page.

Una Master Page es definida, especificada y generada en forma independiente. Si se desea modificar
el layout o comportamiento general del sitio, solo hay que realizar la modificación en la Master
Page, sin necesidad de modificar/regenerar los objetos web que la utilicen.

Algunos de los beneficios de esta nueva funcionalidad son:

• Menos código (se ahorra mucho código Javascript que generan los Web Components)

• Facilidad para diseñar forms de objetos web

• Algunos aspectos de seguridad y auditoría pueden ser implementados en el Web Panel


Master Page

• Mejor performance (menos código HTML)

• Desarrollo incremental (solo cambiando el Master Web Panel cambia toda la aplicación)
¿Cómo hacer que un objeto web tenga una Master Page asociada?

Contamos con la propiedad “Master Page” para objetos web (Transacciones Web o Web Panels). Sus
valores posibles son:

 (none)

 Master Pages definidas en la base de conocimiento

Y solo puede definirse para: Transacciones Web y Web Panels con la propiedad “Type” en “Web
Page” (no Component).

Si se definen varios Web Panels como Master Pages, éstos aparecerán para ser seleccionados como
“Master Page” de un objeto web, en la propiedad “Master Page” que por defecto asume el valor
“(none)”.

Solo puede asociarse una Master Page a Transacciones Web o Web Panels que no sean Web
Components.

Observaciones

EVENTOS
Cuando se ejecuta un Web Panel que tiene asociada una Master Page, la secuencia de ejecución de
los eventos de cada uno será la siguiente:

1. Evento START de la Master Page

2. Evento START del Web Panel

3. Evento REFRESH y LOAD de la Master Page (aquí la Master Page es dibujada hasta que se
encuentra el Content Placeholder)

4. Evento REFRESH y LOAD del Web panel

5. …
Restricciones

Una Master Page es un Web Panel común y corriente (incluso puede tener Web Components) pero
necesita cumplir las siguientes condiciones:

• Solo puede tener un control “Content Placeholder”

• No puede tener regla parm (en caso contrario mostrará en tiempo de especificación
“spc0092 Master Pages do not support the parm() rule”)

• No puede ser Main (si se escoge para la propiedad “Type” el valor “Master Page” para un
Web Panel, la propiedad Main desaparece)

• No puede invocarse una Master Page desde otro objeto como si fuera un simple Web Panel
(en tiempo de especificación mostrará: “spc0008 Events(6): Call to program
MasterWebPanel that cannot be generated”)

• Si un Web Panel era una Master Page y deja de serlo, los objetos que tuviesen asociada esa
Master Page mostrarán un error de especificación (“spc0093 The Master Page property
references an object that is not a Master Page).

Demo: Uso de Master Pages

Definamos en nuestra aplicación práctica una Master Page para incluir en ella el diseño del sitio.
Creemos entonces un nuevo objeto Web Panel MyMPage.

La idea sería tener un cabezal en la parte superior, el componente de login a la izquierda y un pie de
página para la aplicación.

En la parte derecha tendremos las páginas de la aplicación.

Por lo tanto definiremos una tabla de 3 x 1 para alinear las secciones. La celda del medio la
dividiremos utilizando la opción Split Cell. Para que luego en ejecución se visualice correctamente
definiremos en la property “Width” tanto de las celdas (superior e inferior) como de la Tabla en
“100%”. Mientras que en la celda que tiene el Componente Login definiremos “20%” y en la celda
Zona de datos “80%”.
El cabezal y el footer serán dos nuevos objetos definidos como componentes que serán incrustados
en esta tabla.

Entonces será así:

Componente Cabezal

Componente Login Zona de datos

Componente Pie de página

Vea la demostración aquí

Ahora, es necesario definir los Web Panels que se invocarán desde este objeto para tener el diseño
definido. Para esto siga las instrucciones que se describen en el próximo documento.

Práctico: Definición y uso de Web Components

Ahora es necesario que defina los componentes que se invocarán desde la Master Page.

Para el cabezal, crearemos un Web Panel “Header”. En el mismo incluiremos una Tabla de 1x1, en la
propiedad “Backcolor” configuraremos el color “Blue” para la celda de la primera fila. Además,
configuramos la propiedad “Width” en “100%”, para que la misma ocupe el ancho completo de la
pantalla. Luego, insertaremos el texto “Travel Agency”.Finalmente, configuraremos la propiedad
“Type” de este Web Panel en “Component”, de forma tal que luego lo podramos invocar desde la
Master Page.
Para el pie de página, crearemos un nuevo Web Panel denominado “Footer”.En el mismo
agregaremos una Tabla de 2x1. En la celda superior configuraremos la propiedad “BackColor” en el
siguiente color: “Peach” y en la celda inferior “Bone”. Agregaremos las variables &Today y &Time
respectivamente en esta celda, además en la propiedad “Align” de la misma se debe optar por
“Center”. En la propiedad “Width” de la tabla la configuramos en “100%”.

Por último, se deberá setear la propiedad “Type” de este Web Panel en “Component”, de forma tal
que luego lo podramos invocar desde la Master Page.

Luego de tener estos objetos definidos, vuelva a la Master Page para referenciarlos desde los
controles correspondientes.

Asignemos también al objeto MainSearch que estamos desarrollando esta Master Page. Para esto,
en la propiedad “Master Page” configure la Master Page definida anteriormente (MyMPage).

Especifique y genere los objetos modificados y ejecute el objeto para verlo en ejecución.

Control Content Placeholder

Para poder cargar cualquier objecto web con el marco especificado por la Master Page, se creó un
nuevo control llamado “Content Placeholder”. Este control define en qué lugar, dentro de la Master
Page, estará ubicado el contenido de las Transacciones Web y los Web Panels que la utilizarán como
su página maestra.

Para insertar un Content Placeholder se debe seleccionar la opción Insert / Content Placeholder,
con lo cual se creará un control de tipo Content Placeholder.

Propiedades

El control Content Placeholder tiene las siguientes propiedades:

 Pgmname: nombre del programa.

 Pgmdesc: descripción del programa.


Observaciones

Solo puede insertarse un Content Placeholder por Master Page.

En caso de intentar insertar un segundo control de este tipo, al grabar dará un error: “Error: Only
one Content Placeholder control is allowed”.

INTRODUCCIÓN

Destacaremos aquí algunas particularidades de las Transacciones Web que están diseñadas en la
aplicación para profundizar algunos conceptos.

Para destacar el funcionamiento de las mismas, se describirán sus diferencias con respecto al
comportamiento de las transacciones en ambiente gráfico, destacando las propiedades y métodos
específicos utilizados en ambiente Web, como ser las propiedades Rows y AddLines. Así como
también el manejo de Blobs en Web Forms.

Form web de Transacciones

Cada Transacción contiene un form (pantalla) web mediante el cual se realizarán las altas, bajas y
modificaciones en ambiente Web.

Para diseñar el form web de una Transacción, se debe abrir la Transacción y seleccionar la opción Object/
Web Form del menú GeneXus. Otra forma, es seleccionando el tab Web Form:

Este form es similar al form GUI-Windows, en el sentido que contiene a todos los atributos definidos
en la estructura, con sus respectivas descripciones (para cada descripción se creará un text block).
Sin embargo, se pueden percibir algunas diferencias:
1) Aparece un control llamado Error Viewer que se utiliza para presentar mensajes. Este
control podrá ubicarse en cualquier parte del form y se le podrán asignar propiedades (tipo
de letra, color, etc.).

2) Aparece un botón llamado Get que se utiliza para obtener un registro luego de
ingresar un valor en el/los atributo/s clave.

3) Algunos botones difieren con respecto a los botones del form GUI-Windows. En particular
los botones Close y Help tienen la misma funcionalidad en ambos forms; sin embargo el
botón Delete All del form web, no opera de la misma forma que el Delete del form GUI-
Windows; y existen otras diferencias en lo que a botones se refiere, y su funcionamiento.

Las diferencias tienen que ver con la forma de trabajo de las aplicaciones Web (HTML), donde cada
vez que el usuario selecciona un botón, hay una comunicación con el servidor Web, una conexión a
la base de datos para efectuar una consulta u operación, desconexión de la misma, y presentación
del resultado con formato HTML en el browser del usuario.

Los botones definidos automáticamente por GeneXus pueden cambiarse por imágenes a las que se
les asocian en la propiedad OnClickEvent los eventos estándar de GeneXus (por ejemplo, ‘Next’,
‘Last’, ‘Get’, etc.).

Se muestra un ejemplo a continuación:


Error Viewer

El control Error Viewer es utilizado para desplegar mensajes al usuario, utilizando la función msg().
Para insertarlo, ir por el menú de GeneXus: Insert / Error Viewer.

Si el control Error Viewer no se coloca en una posición determinada del form, y se usa la función
msg(), el mensaje aparece en la esquina superior izquierda de la pantalla, de lo contrario, aparece
donde se colocó el control.

Esto significa que los objetos Web tienen un control Error Viewer implícito que es donde se
despliega el mensaje al usar la función msg().

Propiedades del Error Viewer en diseño

Las propiedades del control Error Viewer en diseño son:


 ControlName

 Class: La propiedad Class solo se encuentra disponible si el control está en el form de un


objeto que tiene un Tema asociado.

 Display Mode

 ForeColor

 Font

 Fill
Propiedades del Error Viewer en ejecución

Además de las propiedades detalladas anteriormente, se pueden modificar las siguientes propiedades en
tiempo de ejecución:

 BackColor
 Display Mode
 ForeColor
 Class

Propiedades del control Error Viewer en los Temas

Además de las propiedades mencionadas, en la clase Error Viewer de un Tema (o alguna clase derivada de
ella), se pueden configurar otras propiedades para el control. Ver Clase ErrorViewer.
Tener en cuenta que además de la Clase ErrorViewer, están las clases: ErrorMessages y
WarningMessages (que pertenecen a la clase Messages) de un Tema y que aplican a los mensajes
(de las reglas “msg()” y/o “error()”) que se despliegan al utilizar Client Server Validation).

Demo: Transacción de un nivel

Ahora que ya vimos como funcionan las Transacciones Web, podemos definir la Transacción para
registrar un nuevo usuario que es invocada en el link que definiremos en el Web Panel MainSearch.

Para hacerlo, tenemos que editar la Transacción de Usuarios (Users), seleccionando previamente el
modelo de Diseño en la base de conocimiento.

Comenzaremos asociando la Master Page definida previamente para que tome el diseño que ya
hemos definido. Para esto, debemos asignar a la propiedad “MasterPage” el valor “MyMPage”.

La numeración de usuarios se realiza en forma automática, por lo tanto se debe asignar “Yes” a la
propiedad “Autonumber” de la Transacción para que la clave primaria de la tabla se autonumere.
Como ya existe un registro ingresado, comenzaremos a numerarla a partir del número 2. Para eso,
asignar el valor “2” a la propiedad “Autonumber Start”.

Haga clic aquí para ver la demostración

Se debe evitar que el Nickname incluya menos de 5 caracteres. El algoritmo podría ser más
complejo, por lo que en ese caso se debería invocar a un procedimiento que devuelva si hubo o no
error.

En este caso la regla será:


error(‘More characters’) if len(UserNickName)<5;

El ingreso de todos los campos (menos el número de teléfono) es “obligatorio”, por lo cual debemos
agregar reglas que hagan este control:

error(‘Password is required’) if UserPwd.IsEmpty();

error(’E-mail address is required’) if UserEmail.IsEmpty();

error(‘Country is required’) if CountryId.IsEmpty();

error(’City is required’) if CityId.IsEmpty();

msg(‘Please complete your phone number’) if UserPhone.IsEmpty();

Error(‘Please specify a Last Name’) if null(UserLastName);

Error(‘Please specify a First Name’) if null(UserName);

Error(‘Please specify an E-Mail account’) if null(UserEmail);

Error(‘Please specify a User name’) if null(UserFirstName);

Error(‘Please confirm the Password’) if null(&PswConf);

Para que la variable &PswConf sea de ingreso, se debe agregar la regla:

Accept(&PswConf);

Finalmente, se debe controlar que la contraseña concuerde con la confirmación ingresada, para eso
es necesario agregar:

Error(‘Your password entries did not match’) if UserPwd <> &PswConf;

En el evento Start, se deberá agregar el código siguiente para que los controles de ingreso de
passwords queden enmascarados:
Event Start

&PswConf.IsPassword = 1

UserPwd.IsPassword = 1

EndEvent

Haga clic aquí para ver la demostración

Ahora que ya definimos la Transacción Web, podemos modificar el link para registrar un nuevo
usuario, en la página principal, de forma de que le pase los parámetros adecuados a la Transacción
Users.

Recuerde que la página principal del sitio MainSearch tiene asociada la Master Page MyMPage la
cual contiene un Web Component ”Login”, al cual le crearemos un link para registrar un nuevo
usuario.

Veamos la ejecución de nuestra aplicación y registremos un nuevo usuario…

Haga clic aquí para ver la ejecución

Durante la ejecución pudimos visualizar claramente como es la ejecución de las reglas con Ajax.
Pudiendo ver cómo se disparan las reglas, la fórmula (en el caso del campo Full Name) y en cuando y
donde se despliegan los mensajes correspondientes a las reglas Error y Msg.

Resulta importante tener en cuenta que algunas reglas se disparan tanto en el cliente como en el
servidor, por lo que se disparan más de una vez, como se pudo observar en la ejecución anterior.

Además, al momento de grabar la password se podría haber utilizado las funciones de encriptación
que provee GeneXus.
GeneXus provee las siguientes funciones para encriptar datos: GetEncryptionKey, Encrypt64 y
Decrypt64.

Demo: Transacción de dos niveles


A continuación realizaremos las siguientes modificaciones en la Transacción Flights para poder observar los filtros automáticos que
presentan los combos. Para lo cual, modificaremos los controles correspondientes a los países y ciuades, de forma tal que cuando el usuario
seleccione un país, luego al seleccionar las ciudades únicamente se desplieguen las ciudades de dicho país.

Cuando tenemos Transacciones de más de un nivel en GeneXus y necesitamos eliminar registros


correspondientes a los subniveles, debemos entonces tener presente en el grid que representa el
subnivel (en este caso el grid Prices), la variable de GeneXus &GxRemove. Al momento de ejecutar,
el usuario deberá seleccionar el check box correspondiente a la variable &GxRemove y luego
presionar el botón Aplay Changes (que tiene asociado el evento Enter). De esta forma se estará
eliminando la/s líneas seleccionadas del grid.

Haga clic aquí para ver la demostración


Haga clic aquí para ver la ejecución

Ahora que ya vimos como funcionan las Transacciones Web de dos niveles editaremos la
Transacción CountryAttraction para registrar las diferentes atracciones de un país. Para ello el
usuario deberá seleccionar un país y una ciudad (de los respectivos dynamic combo boxes, puesto
que estos atributos fueron definidos así en la Transacción anterior) y para facilitar al usuario el
ingreso de la información en el segundo nivel, aplicaremos las propiedades InputType y Suggest, al
momento de ingresar la categoría de la atracción.

Haga clic aquí para ver la demostración


Es importante tener en cuenta que si se presiona el botón Delete All (), se eliminará el registro de
la Transacción.

Diálogo de las Transacciones en Web

El diálogo de las Transacciones en ambiente Web utiliza la tecnología Ajax para brindar una
alternativa al diálogo a pantalla completa (full screen) y proveer más interacción con el usuario.

En la medida que el usuario final vaya pasando por los campos de la pantalla y/o ingresando
información en ellos, se irán validando los datos, infiriendo los atributos de la tabla extendida, y
disparándose las reglas y fórmulas definidas. Todas estas operaciones se ejecutarán en forma
interactiva para que el usuario final pueda ir viendo resultados. De todas formas, las características
del diálogo a pantalla completa se mantendrán, en el sentido que cuando el usuario final confirme
los datos, se grabarán los de la pantalla completa, disparándose antes todas las validaciones, reglas,
y fórmulas.

Algunas funcionalidades basadas en Ajax son:


 Web Client Side Validation

 Descripciones en vez de códigos

o Propiedad InputType de atributos

o Suggest (intellitips) de atributos y variables

o Combo boxes dinámicos con filtros

Web Client Side Validation (WCSV)

En las aplicaciones .Net y Java con interfaz Web siempre se trabaja con diálogo de validación a nivel
del cliente (Web Client Side Validation). El propósito de esta funcionalidad es incrementar el nivel de
interacción de las aplicaciones Web utilizando la arquitectura Ajax, haciéndolas más atractivas sin
costo de desarrollo alguno.

GeneXus genera código para muchas de las reglas y fórmulas que el desarrollador escribe en las
transacciones, que es ejecutado en el browser del usuario final. En este sentido el usuario obtiene
un feedback temprano, ya que no es necesario someter un request de la página entera al servidor.
Este código es generado en el lenguaje Javascript, por lo que el browser debe tener habilitada la
opción de ejecutar Javascript.

Algunas reglas, por ejemplo aquellas que requieren acceso a la base de datos, deben acceder al
servidor para retornar sus resultados en tiempo real, lo que ahora es posible sin que deba viajar la
página HTML entera del servidor Web al cliente para ser desplegada por el browser. Cuando se carga
la página solicitada en el browser, el código Javascript también será enviado para:

 Disparo de reglas que no dependen de ningún evento de disparo. Esto quiere decir, reglas
que dependen del árbol natural de evaluación.

 Disparo de fórmulas relacionadas, de acuerdo al árbol de evaluación.

 Realizar chequeos de integridad referencial e inferir los correspondientes datos.

 Validación del tipo de datos de los atributos.


Por ejemplo, cuando el usuario final ingresa un valor en un campo que es clave foránea, se realizará
una invocación en Javascript al motor de Ajax (en el propio cliente) que realizará mediante
XmlHttpRequest un pedido al servidor Web de ese dato -y los que deban inferirse a través de él. El
servidor devolverá un XML con la información solicitada y en el browser se rearmará la página HTML.
Observemos que la información que viaja por la Web es mínima.

Todo lo que hace el usuario es ingresar un valor en el campo que es clave foránea, y al abandonarlo
para pasar al siguiente campo, verá que aparecen en pantalla los valores inferidos. El usuario no se
percatará que entre medio viajó información al servidor y volvió, rearmándose la página entera.

Así como ocurría en Win cuando se tenía configurada la propiedad Client Side Validation para que
reglas, fórmulas y controles de integridad referencial se ejecutaran en el cliente, éstas no dejan de
ejecutarse en el servidor. Por el contrario, son ejecutadas por partida doble: primero en el cliente, y
luego, cuando el usuario confirma, vuelven a dispararse en el servidor antes de actualizar la base de
datos.

La validación de reglas y el cálculo de fórmulas son disparados cuando se pierde el foco sobre el
control. La regla de error, al igual que en Win, no permite seguir avanzando entre los campos del
form, hasta que la condición que la produce deja de cumplirse. También al igual que en Win, al
abandonar un control, se dispara todo lo que involucre a ese control, y a todos los que le sigan
consecutivamente y que sean noaccept (o read only).

Las validaciones de los tipos de datos (por ejemplo “invalid date format”) se hacen en el browser y
para presentar el mensaje de error se utiliza el mismo control que veremos se utiliza para las
validaciones de usuario.
En ambiente Web las Transacciones implementan un diálogo muy similar al que permiten los generadores
.Net y Java para aplicaciones con interfaz Windows cuando la propiedad Client Side Validattion tiene el valor
Yes.

Diferencias entre CSV Win y Web


En ambiente Web las Transacciones implementan un diálogo muy similar al que permiten los generadores
.Net y Java para aplicaciones con interfaz Windows cuando la propiedad Client Side Validation tiene el valor
Yes. Sin embargo, presentan algunas diferencias:
 CSV: Para Web no es configurable, es decir, siempre que se genere una aplicación Java o
.Net Web, se generará con validación a nivel del cliente. En cambio, para Win es una
propiedad, configurable tanto a nivel de modelo como de objeto. Si bien por defecto una
aplicación Windows será con validación a nivel del cliente, puede deshabilitarse.

 Inferencia de modo: En Web el modo no será inferido automáticamente a partir del valor
que el usuario ingrese en los atributos que conformen la clave primaria, al contrario de lo
que sucede en Win. Es por ello que en diseño aparece automáticamente el botón “Get”,
para permitir recuperar un registro existente y poder trabajar con él. El desarrollador puede
eliminarlo si la transacción recibe clave y modo. En Win solo será incluido el botón “Get” si
se tiene configurada la propiedad CSV en “No”.

 Botón de confirmación en ejecución: En Web el botón (con texto por defecto “Apply
Changes”) no cambia su texto de acuerdo al modo en el que se esté trabajando. En cambio
en Win el botón (con texto en diseño “Confirm”) cambia su texto en ejecución de acuerdo al
modo en que se encuentre la transacción (si se está insertando, dirá “Add”, si se está
actualizando dirá “Update” y si se invocó a la transacción recibiendo modo delete, el botón
mostrará “Delete”).

 Resultado de la operación sobre la base de datos se informa en: el Error Viewer en la


transacción Web, y en la barra de estado que aparece en el extremo inferior izquierdo de la
pantalla en la transacción Win.

 Una quinta diferencia que es importante tener en cuenta tiene que ver con la UTL (Unidad
de Trabajo Lógica). No debe perderse de vista que una UTL Web NO contiene las
operaciones realizadas dentro de distintos objetos en una cadena de invocaciones. Por cada
transacción Web existirá commit en caso de que el desarrollador no lo deshabilite, pero las
operaciones de ese objeto deben commitearse ANTES de llamar a otro objeto, pues de no
hacerlo, ya habrá terminado la vida de esa UTL al invocar al otro objeto y el Commit de la
transacción no operará.
¿En dónde serán desplegados los mensajes?

El lugar dónde se desplegarán los mensajes depende del momento de disparo. Cuando un mensaje
(“msg”) o error es disparado en el servidor (como por ejemplo registro duplicado), será desplegado
como una lista en el control Error Viewer. Además, en cajas de texto sobre la pantalla,
específicamente sobre los campos que el usuario haya ingresado (al momento de perder el foco) y
en consecuencia se tengan que presentar mensajes.

El Error Viewer continuará desplegando todos los mensajes y errores que no dependen de controles
del form que el usuario se ha posicionado. Por ejemplo, las reglas stand-alone. Asimismo, cuando el
usuario envía la página al servidor, todas las reglas y fórmulas se volverán a disparar. Todos los
mensajes que fueron disparados en el cliente y aún son válidos se redesplegarán también en un Text
Box o en el Error Viewer. Las reglas asociadas a eventos de disparo (AfterValidate, AfterInsert, etc.)
serán evaluadas por primera vez, lo que generarán mensajes y errores que se desplegarán en el
Error Viewer.
Es decir, funcionarán de manera combinada el control Error Viewer junto con los mensajes
interactivos en cajas de texto.

PROPIEDADES DE LAS CAJAS DE TEXTO DE LOS MENSAJES EN LOS


TEMAS
Estas cajas de texto tienen dos clases asociadas a los Temas.

Todas las reglas “error” están asociadas a la Clase ErrorMessages y las reglas “msg” están asociadas
la Clase WarningMessages. Ambas clases pertenecen a la Clase Messages, donde se les puede
configurar sus propiedades como con las demás clases. La diferencia en este caso es que no hay
controles GeneXus asociados a dichas clases. La asociación a las clases ErrorMessages y
WarningMessages es automática (para los errores y reglas “msg” respectivamente).

Tener en cuenta que además de las mencionadas clases, está la Clase ErrorViewer que aplica a la
lista de mensajes del control Error Viewer.
En ambiente Web las Transacciones implementan un diálogo muy similar al que permiten los generadores
.Net y Java para aplicaciones con interfaz Windows cuando la propiedad Client Side Validation tiene el valor
Yes.

Modos de las Transacciones en tiempo de ejecución

Los programas que se generan correspondientes a las Transacciones –tanto para ambiente Windows
como para ambiente Web- permiten dar altas, bajas y modificaciones en forma interactiva a la base
de datos a través de los mismos.

Al ejecutar un programa correspondiente a una Transacción, se podrán distinguir los siguientes


modos, dependiendo de la operación que se realice:

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

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


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

 Modo Display : Indica que se está efectuando una consulta

Dependiendo de la plataforma o ambiente de generación, habrán algunas diferencias en lo que se


refiere a la operativa de las Transacciones en tiempo de ejecución. No obstante, más allá de la
plataforma, cada vez que se realice una operación de inserción, actualización, eliminación, o
consulta a la base de datos a través de una Transacción, habrá un modo asociado.

Además de esto, las Transacciones tienen un comportamiento diferente según reciban o no el modo
instanciado.

Transacciones Web sin Modo instanciado

Las Transacciones Web pueden invocarse sin recibir el modo instanciado. Se detalla el
comportamiento de las mismas dependiendo de la acción: inserción, modificación o eliminación de
registros.

Modo Insert

Al ingresar a una Transacción Web de este tipo, se comienza en modo Insert, y se despliega una
pantalla con la siguiente forma:
Si se quiere ingresar un registro nuevo, se digitan los datos en la pantalla y se presiona el botón
‘Apply Changes’. Esto provoca, en primera instancia, que se validen los datos ingresados en forma
similar a cuando se presiona el botón ‘Check’. En caso de que ya exista el registro va a dar un
mensaje de error que se despliega en el Error Viewer. El mensaje es ‘Record already exists’.

Además, si no se trabaja con confirmación (propiedad Confirmation del objeto), se insertarán los
datos. Si se trabaja con confirmación, se desplegará el mensaje ‘Please confirm the data’. Al
presionar nuevamente el botón ‘Apply Changes’, se insertarán los datos.

Luego de actualizada la base de datos, se despliega el mensaje ‘Data has been successfuly added’.

Modo Update

Para entrar en modo Update, se deberá poner un valor en la clave y presionar el botón ‘Get’ ( ).
Esto hace que se carguen los datos del registro.
Al cargar los datos también se traen las descripciones. Se pueden modificar los datos y presionar el
botón ‘Apply Changes’, y se actualizarán los datos con un procedimiento análogo al del modo Insert.

Modo Delete

Para eliminar un registro primero se debe ingresar en modo ‘Update’ (ingresando la clave y
presionando el botón ‘Get’), y luego presionar el botón ‘Delete All’, lo que provoca que se
deshabilite dicho botón. En el caso de trabajar con confirmación, se desplegará el mensaje ‘Confirm
deletion’.

Al presionar el botón ‘Apply Changes’, se eliminarán los datos y se desplegará el mensaje ‘Data has
been successfuly deleted’.

En el caso de que no se trabaje con confirmación, al presionar el botón ‘Delete All’ se eliminarán
directamente los datos y se desplegará el mensaje ‘Data has been successfuly deleted’, sin necesidad
de presionar ‘Apply Changes’.
Al eliminarse un registro se cargan los datos correspondientes al registro anterior, quedando en
modo ‘Actualizar’. Si se borran todos los registros, la Transacción queda en modo ‘Insert’.

Observaciones

Tener en cuenta que si la variable &mode no es recibida como parámetro puede tomar cualquier
valor. Y en el evento Start al menos, el valor es indeterminado.

Este es el comportamiento esperado ya que el valor que tiene que tener no está establecido aún.

Transacciones Web con Modo instanciado

Las Transacciones Web que se invocan instanciando el modo Insert, Update, Delete o Display,
deshabilitan los botones de movimiento entre registros y los botones ‘Get’, ‘Select’ y ‘Delete All’.

Modo Delete

Cuando se invoca una Transacción Web instanciando el modo Delete siempre se despliega el
mensaje ‘Confirm deletion’, sin importar si se está trabajando con confirmación o no. Al
presionar el botón ‘Apply Changes’, se elimina el registro.

Transacciones Web de más de un nivel

Cuando se trabaja con Transacciones Web de más de un nivel, se tienen que tener en cuenta los
siguientes puntos:

Número de niveles de una transacción

Las Transacciones Web pueden tener más de un nivel anidado. Asimismo, pueden tener varios
niveles en paralelo. Se implementa de la siguiente forma:

 El primer nivel debe ser plano


 Cada nivel de anidación previo al último debe ser un grid Free Style que contenga al nivel
siguiente

 El último nivel debe ser un grid estándar.

Por más detalles ver Grids en Transacciones Web.

Método AddLines

Se implementó el método AddLines para el tipo de control grid. El mismo aplica en Transacciones
Web. Y permite al usuario ingresar líneas en el grid una por una.

El uso es bastante simple, para el caso del ingreso de datos que necesita más líneas de las que hay
por defecto se puede agregar un botón con este método. Este método no realiza ni validaciones ni
chequeos, sólo agrega las líneas en blanco al final y mantiene los valores que ya estaban ingresados
en la Transacción.

Sintaxis

MyGrid.AddLines(N)

Agrega N líneas al grid de la Transacción.

Ejemplo

El usuario podrá presionar el botón AddLines en Modo Insert para agregar línea a línea en el grid de
la Transacción.

Event Start
if &Mode = 'INS'
MyGrid.Rows = 1
else // &Mode = UPD / DLT / DSP
MyGrid.Rows = 0
endif
EndEvent

Event 'AddLines'
MyGrid.AddLines(1)
EndEvent // 'Addlines'

Eliminación de líneas

En diseño se utiliza una variable &GxRemove definida y agregada automáticamente a los grids de la
pantalla por defecto. Esta variable es un check box que se ubica en la primera columna del grid.
Cuando se desea eliminar alguna línea del grid, se debe marcar la misma con el check box, y
presionar el botón de ‘Apply Changes’, no el botón de ‘Delete All’. Este último eliminará toda la
transacción, no las líneas marcadas.

Nota: Es importante considerar nuevamente que cuando se está en una Transacción Web se está
modificando todo el “documento” y no se está en un nivel en particular de la misma. Por eso para
eliminar líneas se debe utilizar el botón ‘Apply Changes’ porque en realidad se está actualizando el
“documento”. Lo mismo para agregar líneas, se debe utilizar el botón ‘Apply Changes’ porque se
está actualizando el “documento”.

Reglas en Transacciones Web

Las reglas, en el objeto Transacción, 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 de ejecución.

Pueden involucrar a los atributos definidos en la estructura de la Transacción , así como a


variables, constantes y funciones.

Son solo válidas dentro de la Transacción en la que están definidas, es decir, son locales.
Todas las reglas de Transacciones pueden involucrar a atributos de la(s) tabla(s) base(s)
asociada(s) a la Transacción; y la mayor parte de ellas pueden también involucrar atributos de la(s)
tabla(s) extendida(s) de la(s) tabla(s) base(s) asociada(s) a la Transacción. Para poder referenciar a un
atributo en una regla, el mismo deberá estar incluido en la estructura de la Transacción. Ya sea que
pertenezca a alguna de las tablas bases asociadas a la Transacción, o a sus tablas extendidas.

Reglas más utilizadas en Transacciones

La siguiente es una lista de las reglas más utilizadas en Transacciones:

 Default

 Error

 Msg

 Asignación

 Serial

 Subtract

 Add

 Allownulls

 Update

 Accept

 Noaccept
Recomendamos acceder al Help de GeneXus para consultar sobre otras reglas válidas para
Transacciones, o para profundizar sobre estas, de ser necesario.

Default

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 inserción por medio de la Transacción (modo Insert),
pero el usuario final podrá cambiarlo si ese valor no es el que desea.

Sintaxis

Default( att | &var, exp );

Donde:

att: es un atributo perteneciente a alguna de las tablas base asociadas a la Transacción.

var: es el nombre de una variable.

exp: es una expresión que puede involucrar constantes, funciones, variables u otros atributos. El tipo
de datos de la expresión debe coincidir con el tipo de datos del atributo o variable.

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

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

Error

Permite desplegar un mensaje de error si la condición 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 expresión cuyo tipo resultante es character y que será desplegada.

msgId: es un string (sin espacios en blanco ni comillas) que será utilizado solo si la Transacción es
definida también como business component1.

cond: es una expresión booleana (que puede contener los operadores lógicos and, or, not).

evento/momento de disparo: es uno de los eventos predefinidos de GeneXus disponibles para reglas
de Transacciones, que permiten definir el momento específico de ejecución de una regla.

Funcionalidad: Esta regla despliega el mensaje del parámetro msg, var o character expresion, si la
condición cond que se evalúa resulta verdadera. El mensaje de error se despliega en el control Error
Viewer y/o un cuadro de texto, deteniendo cualquier actualización a la base de datos. Cuando la
Transacción se ejecuta como Business Component, de dispararse el error, generará una entrada en
el SDT messages, con identificador msgId.

Msg

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

Sintaxis

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

Donde:
msg, var, character expresion, msgId, cond, evento/momento de disparo: son los mismos que para la
regla error.

Observar que la sintaxis es exactamente la misma.

Funcionalidad: Esta regla se utiliza para presentar mensajes de advertencia al usuario. Despliega el
mensaje del primer parámetro, si la condición se satisface, análogamente a la regla Error; pero a
diferencia de esta última, permite continuar con la ejecución si la condición sigue satisfaciéndose.
Del mismo modo, si la Transacción es Business Component, de dispararse la regla genera una
entrada en el SDT messages.

Los mensajes de advertencia se despliegan en el Error Viewer o cuadro de texto en ambiente Web.

Noaccept

Permite indicar que los atributos no aceptarán valores por parte del usuario (serán solo de salida). Si
bien se dispone de las propiedades ‘Visible’ o ‘Enabled’ para que los atributos no acepten valores, se
recomienda el uso de la regla Noaccept.

Sintaxis

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

Donde:

atti: es un atributo perteneciente a alguna de las tablas bases asociadas a la Transacción.

cond: es una expresión booleana (puede contener los operadores lógicos and, or, not).

Funcionalidad: En una Transacción, todos los atributos que pertenecen a las tablas base asociadas a
la Transacción, por defecto son aceptados. Si queremos que algunos atributos con estas
características no sean aceptados, entonces contamos con la regla Noaccept.
Subtract

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

Sintaxis

subtract(att1, att2) [if cond];

Donde:

att1, att2: son atributos pertenecientes a alguna de las tablas base asociadas a la Transacción, o a
sus tablas extendidas (y deben estar declarados en la estructura)

cond: es una expresión booleana (que puede contener los operadores lógicos and, or, not).

Funcionalidad: La sustracción se realiza teniendo en cuenta el modo en el que se esté trabajando en


la Transacción (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

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

Add

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

Sintaxis

add( att1, att2) [if cond];

Donde:
att1, att2: son atributos pertenecientes a alguna de las tablas base asociadas a la Transacción, o a
sus tablas extendidas (y deben estar declarados en la estructura).

cond: es una expresión booleana.

Funcionalidad: La adición se realiza teniendo en cuenta el modo en el que se esté trabajando en la


Transacción (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

Serial

Permite numerar serialmente atributos numéricos.

Sintaxis

Serial( att1, att2, step);

Donde:

att1: es un atributo perteneciente a alguna de las tablas base asociadas a la Transacción (es decir,
no inferido), que desea autonumerarse (debiendo estar declarado en la estructura).

att2: Tiene que pertenecer a una tabla directamente superordinada a la del atributo att1.

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

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

Es decir, cuando se está insertando un registro por medio de una Transacción en la cual se 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.

Accept

Permite indicar que las variables aceptarán valores por parte del usuario en un nivel dado de la
Transacción.

Sintaxis

Accept(&var [, att]);
Donde:

&var: es una variable presente en el form.

atti: es un atributo perteneciente a la Transacción.

Funcionalidad: Esta regla permite al usuario el ingreso de valores en variables en el nivel de la


Transacción indicado por los atributos att. El orden el el cual los datos son ingresados en un cierto
nivel depende en el orden en que las variables y atributos estén posicionados en la pantalla. Si no se
especifica un atributo en particular, se asume el primer nivel de la Transacción.

Update

Posibilita actualizar en el form de una Transacción atributos de la tabla extendida (inferidos).

Sintaxis

Update( att1[, atti …]);

Donde:

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

Funcionalidad: En una Transacción, todos los atributos que pertenecen a las tablas base asociadas a
la Transacción, 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.

Consideraciones para el ambiente Web

La regla Default_mode no aplica en Transacciones Web.


La regla Default (Att,&today) se dispara únicamente la primera vez que se ejecuta la Transacción
Web, en su lugar se aconseja utilizar default(Att,today()).

Lo mismo ocurre con la variable &time y la función Time() correspondiente.

Orden de Ejecución de Reglas y Fórmulas

La forma de programar el comportamiento de las Transacciones es definiendo reglas, las cuales se


escriben de forma declarativa. A su vez si hay cálculos para efectuar, se puede optar por la
alternativa de definir atributos fórmula.

El programador GeneXus en ningún momento especifica la secuencia de ejecución de las reglas y


fórmulas definidas en una Transacción, sin embargo al momento de generar, GeneXus determina las
dependencias existentes entre las reglas y fórmulas definidas.

En la mayoría de los casos el orden de ejecución de las reglas definido por GeneXus a partir de
nuestras especificaciones es el deseado. Pero en algunos casos podemos querer cambiar el
momento de disparo de una regla.

GeneXus ofrece eventos o momentos de disparo en las Transacciones, que ocurren antes o después
de determinada acción, como la grabación del cabezal, o de una línea. Las reglas de las
Transacciones pueden condicionarse de manera tal de dispararse en el preciso instante en que
ocurre alguno de esos eventos de disparo.

Eventos de disparo:

 BeforeValidate

 AfterValidate

 BeforeInsert, BeforeUpdate, BeforeDelete

 AfterInsert, AfterUpdate, AfterDelete


 AfterLevel

 BeforeComplete

 AfterComplete

Al momento de la confirmación de la Transacción, ocurre una serie de acciones que es necesario


conocer para poder programar correctamente el comportamiento de las reglas.

Para una Transacción de dos niveles, podríamos enumerarlas como sigue:

 Validación de los datos del cabezal

 Grabación física del cabezal (ya sea inserción, modificación o eliminación)

 Validación de los datos de la primera línea

 Grabación física de los datos de la primera línea

 Validación de los datos de la segunda línea

 Grabación física de los datos de la segunda línea

 …

 Validación de los datos de la n-ésima línea

 Grabación física de los datos de la n-ésima línea

 Commit

La acción de “validación de los datos del cabezal” ocurre cuando se han validado todos y cada uno
de los campos ingresados en el cabezal. Observar que en este punto ya se han disparado todas las
reglas que correspondían a atributos del cabezal y que no tenían evento de disparo asociado.
Inmediatamente después se grabará el registro correspondiente al cabezal.

Análogo es el caso de las líneas: “la validación de los datos de una línea” ocurre cuando ya se han
validado todos y cada uno de los datos de la línea, y también se han disparado todas las reglas
correspondientes según el árbol de evaluación. Inmediatamente después de esta acción de
validación, se grabará físicamente el registro correspondiente a la línea.

Cada Transacción, al terminar de trabajar con un cabezal y sus líneas, realiza un commit (es
automático); será colocado en el código generado por GeneXus, a menos que el analista especifique
lo contrario.

Los eventos de disparo de reglas permiten definir que se ejecuten antes o después de alguna de las
acciones que acabamos de enumerar. Veremos cuándo ocurre cada evento de disparo.
Evento de disparo: BeforeValidate

Este evento de disparo ocurre un instante de tiempo antes de que la información de la instancia con
la que se está trabajando (cabezal o línea x) sea validada (o confirmada). Es decir, ocurrirá un
instante de tiempo antes de la acción de “validación del cabezal” o “validación de la línea”, según
corresponda. Observar que aquí también se habrán disparado todas las reglas según el árbol de
evaluación que no estén condicionadas a evento de disparo alguno.

Eventos de disparo: AfterValidate, BeforeInsert, BeforeUdate, BeforeDelete

El evento de disparo AfterValidate permite especificar que una regla se ejecute inmediatamente
antes de que se grabe físicamente cada instancia del nivel al cual está asociada la regla, en la tabla
física correspondiente, y después de que se hayan validado los datos de esa instancia.

En otras palabras, si se le agrega el evento de disparo AfterValidate a una regla, la misma se


ejecutará para cada instancia del nivel al cual esté asociada, inmediatamente antes de que la
instancia se grabe físicamente (ya sea que se inserte, modifique o elimine) como registro en la tabla
física asociada al nivel.

Existen tres eventos de disparo que ocurren en el mismo momento que el AfterValidate, pero que ya
contienen intrínseco el modo. Ellos son: BeforeInsert, BeforeUpdate y BeforeValidate.

Observar que aquí es redundante condicionar la regla a “If Insert”. Por tanto, valen las siguientes
equivalencias:

on BeforeInsert ~ If Insert on AfterValidate

on BeforeUpdate ~ If Update on AfterValidate

on BeforeDelete ~ If Delete on AfterValidate

Si hacemos un esquema de las acciones que rodean al evento de disparo, quedarán claros los dos
sinónimos elegidos para este evento (AfterValidate y BeforeInsert para modo insert)
VALIDACIÓN DE LOS DATOS

AfterValidate – BeforeInsert – BeforeUpdate – BeforeDelete

GRABACIÓN DEL REGISTRO (insert, update, delete según corresponda)

Eventos de disparo: AfterInsert, AfterUpdate, AfterDelete

Así como existe un evento de disparo que permite definir que determinadas reglas se ejecuten
inmediatamente antes de que se produzca la grabación física de cada instancia de un nivel
(AfterValidate, BeforeInsert, BeforeUpdate, BeforeDelete), también existen eventos de disparo para
definir que ciertas reglas se ejecuten inmediantamente después de que se inserten, modifiquen o
eliminen físicamente instancias de un nivel. Estos eventos son AfterInsert, AfterUpdate y
AfterDelete.

El evento de disparo AfterInsert permite definir que una regla se ejecute inmediatamente después
de que se inserte físicamente cada instancia del nivel al cual está asociada la regla; el AfterUdate
luego de que se actualice físicamente la instancia, y el AfterDelete luego de que se elimine.

Eventos de disparo: AfterLevel, BeforeComplete

El evento de disparo AfterLevel permite definir que una regla se ejecute inmediatamente después de
terminar de iterar determinado nivel.

Si el atributo que se especifica a continuación del evento de disparo AfterLevel pertenece al


segundo nivel de la Transacción, la regla se ejecutará cuando se hayan terminado de iterar todas las
líneas del segundo nivel.
Y si el atributo que se especifica a continuación del evento de disparo AfterLevel pertenece al primer
nivel la regla se ejecutará cuando se haya terminado de iterar por todos los cabezales. Observar que
esto se da al final de todo, es decir, una vez que se hayan ingresado todos los cabezales y sus líneas y
se cierre la Transacción (en ese momento se habrán iterado todos los cabezales). Por lo tanto, si el
atributo especificado pertenece al primer nivel, la regla se disparará una vez sola antes del Evento
Exit.

El evento de BeforeComplete, se disparará después de abandonar el último nivel.

Evento de disparo: AfterComplete

Este evento corresponde al instante de tiempo que sucede al commit.

Esquema de disparo

VALIDACIÓN DE LOS DATOS CABEZAL

AfterValidate – BeforeInsert – BeforeUpdate – BeforeDelete

GRABACIÓN DEL REGISTRO (insert, update, delete según corresponda)

AfterInsert – AfterUpdate – AfterDelete

VALIDACIÓN DE LOS DATOS LÍNEA

AfterValidate – BeforeInsert – BeforeUpdate – BeforeDelete

GRABACIÓN DEL REGISTRO (insert, update, delete según corresponda)

AfterInsert – AfterUpdate – AfterDelete

ABANDONAR NIVEL 2

AfterLevel - BeforeComplete

COMMIT
AfterComplete

Observaciones

Una regla condicionada al evento de disparo AfterLevel Level atributo del 1er. nivel solo se disparará
en una Transacción Win (para una Transacción Web no tiene sentido) y lo hará una sola vez, cuando
se cierra la Transacción.

El evento Start y el evento Exit, c

omo mencionaremos luego, en una Transacción Web estos eventos se ejecutarán una vez por cada
instancia de Transacción con la que se trabaje.

Otro tema importante son las reglas que no tienen evento de disparo asociado, se ejecutarán una
vez o dos o tres, dependiendo de lo que se haya configurado en la propiedad del modelo
Confirmation.

Por ejemplo, si se trabaja en Web y con la propiedad Confirmation=No, valor por defecto, las reglas
que no tengan evento de disparo asociado se dispararán: primero en forma interactiva en la medida
que el usuario final vaya trabajando en el form, y luego nuevamente cuando el usuario final efectúe
la confirmación.

Es especialmente importante considerar esto en aquellos casos de reglas que consistan en


invocaciones a procedimientos que actualicen la base de datos.

Si se tiene una invocación a un procedimiento que actualiza la base de datos, habrá que optar por
alguna de las siguientes alternativas para evitar que se dispare más de una vez:

• asignarle evento de disparo específico a la regla


bien decidir si configurar o no la propiedad confirmation
• o estudiar bien la lógica del procedimiento y tener en cuenta la doble o triple ejecución del mismo

Por último, si se configurara la propiedad Confirmation= Yes, las reglas sin evento de disparo
asociado tendrían un triple disparo.

Esto no sucederá con reglas de GeneXus (como subtract, add) que actualizan la base de datos
porque GeneXus tiene la inteligencia para realizar el update solo al confirmar (lo mostrado en forma
interactiva se calcula en memoria).

Eventos en Transacciones Web

En las transacciones se permite la programación dirigida por eventos, que es un estilo de


programación en el cual existe código que permanece ocioso, hasta que es llamado para responder a
eventos, provocados en nuestro caso por el usuario, o por el sistema.

Los eventos son acciones que pueden suceder o no. Se escribe código asociado a cada evento
posible, y el mismo se disparará sólo si el evento se produce.

La programación dentro del evento sigue un estilo procedural.


Eventos existentes en Transacciones

Los eventos existentes en las Transacciones, son:

 Evento Start

 Evento After Trn

 Eventos de Usuario

 Evento Exit

En primera instancia explicaremos cada uno de estos eventos conceptualmente y en qué momento
exacto se ejecutan, y a lo largo del curso veremos varios ejemplos de utilización de los mismos.

Evento Start (de Transacciones Web)

El evento Start es un evento del sistema, que ocurre automáticamente.

¿En qué momento se ejecuta? Se ejecutará cada vez que se someta el form de la Transacción, es
decir cuando se presione cualquier botón del form (“Get”, “Apply Changes”, botones de navegación,
botón Select o cualquier botón con un evento de usuario asociado).

En el evento Start fundamentalmente se trabaja con variables. En cuanto a utilizar atributos en este
evento, ya sea para evaluarlos y/o usarlos de algún modo menos para actualizarlos, se debe tener en
cuenta que los únicos atributos que se tienen disponibles son los que se reciben por parámetro en la
regla parm. Ningún otro atributo tendrá valor en este evento, pues todavía no se ha editado ninguna
instancia de la Transacción.
Evento Alter Trn (de Transacciones Web)

El evento After Trn de las Transacciones ocurre inmediatamente después de la ejecución de las
reglas con evento de disparo AfterComplete. Por consiguiente, el código que se incluya en este
evento, se ejecutará luego de culminada cada iteración completa por medio de la Transacción (es
decir, luego de haberse grabado cada cabezal con sus correspondientes líneas como registros físicos
en las tablas que corresponda y de haberse efectuado COMMIT).

Existen las siguientes alternativas para programar comportamientos que se deseen ejecutar luego de
cada iteración completa por medio de una Transacción:

 Definir reglas individuales con evento de disparo AfterComplete y dejar el evento After Trn
sin código

 Definir todas las sentencias en el evento After Trn con estilo procedural, y no definir reglas
con evento de disparo AfterComplete

 Definir ambas cosas: alguna(s) regla(s) con evento de disparo AfterComplete y código en el
evento After Trn

Como venimos explicando, primero se ejecutan las reglas definidas con evento de disparo
AfterComplete, e inmediatamente después de las mismas se ejecuta el código definido en el evento
After Trn.

Un concepto que es muy importante tener claro, es que tanto en reglas con evento de disparo
AfterComplete como en el evento After Trn, se conocen los valores de los atributos del primer nivel
de la Transacción. Es decir, si bien ya se grabaron físicamente los registros correspondientes al
cabezal y las líneas de cierta iteración completa, e incluso se efectuó COMMIT, aún se tienen
disponibles los valores de los atributos del primer nivel, pudiendo estos utilizarse para pasarlos por
parámetro en una invocación, o evaluar su valor, o usarlos de algún modo menos para
actualizarlos .

Un detalle a tener en cuenta es que en el evento After Trn -como en todo evento- es posible incluir
comandos, a diferencia de en la sección de reglas de una Transacción, que no se puede.
Hay dos motivos por los cuales no es posible actualizar a atributos ni en reglas con evento de
disparo AfterComplete ni en el evento After Trn. El primer motivo es que ya se han hecho las
grabaciones pertinentes e incluso se ha efectuado COMMIT, de modo que ya es tarde para asignar
valores a atributos. Y además, en lo que respecta al evento After Trn, en los eventos no se permite
realizar asignaciones a atributos.
Eventos de usuario (de Transacciones Web)

Además de los eventos ofrecidos por GeneXus, el analista puede definir eventos creados por él, los
cuales reciben el nombre de eventos de usuario.

Cada evento de usuario debe asociarse a un control insertado en el form Web de la Transacción de
los que soportan el OnClickEvent (botones, text blocks, imágenes, atributos) y/o a una tecla de
función.

En tiempo de ejecución, el evento de usuario ocurrirá luego de que el usuario haga clic sobre el
control o la tecla de función asociado/a al mismo. Se consigue de dos maneras distintas:

1. Editando las propiedades del control, y definiendo un evento de usuario en la propiedad


OnClicEvent. De esta manera GeneXus define la siguiente sintaxis automáticamente:

Event ‘Nombre Evento de Usuario’ [key]


EndEvent

2. Dándole un nombre al control y en la sección de Eventos programando:

Event nombreControl.click

Endevent

Con esta última alternativa no tendremos que definir un evento de usuario, sino que estaremos
programando el evento clic del control.
Nota: se pueden ejecutar eventos asociados a botones con Alt+<letra>. Se logra colocando un ‘&’ en
el Caption del botón, antes de la letra con la que se desea acceder al evento.

Evento Exit (de Transacciones Web)

El evento Exit es un evento del sistema (por lo tanto ocurre automáticamente) y es lo último en
ejecutarse.

¿En qué momento se ejecuta? Ocurre una única vez, al final de cada iteración (es lo último que se
ejecuta).

Al igual que en el evento Start, en el evento Exit fundamentalmente se trabaja con variables.

En cuanto a utilizar atributos en este evento, ya sea para evaluarlos y/o usarlos de algún modo salvo
actualizarlos, se debe tener en cuenta que los únicos atributos que se tienen disponibles son los que
se reciben por parámetro en la regla parm. Ningún otro atributo tendrá valor en este evento.

Como se dispara cada vez que se dibuja la pantalla, no hace las veces de un verdadero Exit, por lo
que no suele utilizarse en este ambiente.

Orden de disparo de los eventos


Cuando se ejecuta por primera vez una Transacción, el orden de disparo de eventos y reglas es el siguiente:

1. Evento START
2. Reglas que no tienen condiciones de disparo
Al presionar el botón ‘Get’, el botón ‘Confirm’ o cualquier botón con un evento de usuario asociado, el disparo
de eventos y reglas es el siguiente:

1. Evento START
2. Lectura de los atributos/variables del form
3. Reglas

Al confirmar los datos, se ejecuta en orden todo lo siguiente:

4. Evento START

5. Lectura de los atributos/variables del form


6. Reglas y Fórmulas según árbol

7. COMMIT

8. Evento AFTER TRN

9. Evento EXIT

Propiedades de Transacciones Web

A continuación veremos las propiedades más comunes en una Transacción Web:


 Name: En dicha propiedad se especifia el nombre de la Transacción.

 Description: Permite el ingreso de una breve descripción de la Transacción. También se


utiliza como título por defecto del form, por ejemplo.

 Folder: Permite indicar en qué subcarpeta dentro de la estructura de la carpeta


Objects, estará el objeto.

 Style: Permite indicar cuál es el Style asociado a dicha Transacción.

 Theme: Permite indicar cuál es el Tema asociado a dicha Transacción.

 Type: Permite indicar si la Transacción será un WebComponent (Component) o una


página Web (Web Page).

 Master Page: Permite indicar cuál es la MasterPage en la cual está basada la


Transacción.

 Encrypt URL parameters: Permite o denega la encriptación de los parámetros enviados


en la URL.

 Business Commponent: Permite indicar si es Business Commponent o no.


 Commit on exit: Controla si se efectúa o no el commit automáticamente.

Integridad Transaccional en Transacciones Web


Por la forma de trabajo en Internet, las Transacciones Web “viven” solamente el tiempo entre que el usuario
de un browser seleccionó el link o presionó un botón y la nueva página es mostrada. Toda modificación a la
base de datos que se haga durante la “vida” debe ser confirmada o eliminada antes de que la Transacción
Web “muera” y retorne la página resultante.

Como consecuencia, una Transacción Web inicia una UTL (Unidad de Trabajo Lógica) al comenzar a ejecutar
y la cierra (ya sea por COMMIT o ROLLBACK) antes de terminar. No puede formar parte de otra UTL. Si un
programa llama a una Transacción Web, ésta iniciará una nueva UTL.

No puede definirse una UTL compuesta por varias Transacciones Web. Una Transacción Web solo
puede Commitear los registros insertados por ella misma, o por procedimientos (teniendo la
propiedad “Commit on exit” en “No”) en una cadena de invocaciones, pero no puede Commitear los
registros insertados por otra Transacción.

El objeto que “gobierna” la UTL será la Transacción y puede incluir en ella las acciones realizadas en
procedimientos invocados desde ella.

Por todo esto, no aplica la propiedad “Commit on Exit” en las Transacciones Web, es decir si se pone
“Commit on exit” en “No” nadie comiteará estos datos.

Si se necesita que las operaciones de dos o más transacciones (con o sin procedimientos incluidos)
conformen una misma UTL, se pueden emular las transacciones con Web Panels y Business
Components y utilizar el comando Commit.

Dejamos aquí presentado simplemente el tema, para volver a él luego de estudiados los Business
Components, donde nos será posible comprender esta solución.

Consideraciones Generales

Control de concurrencia

Las Transacciones Web utilizan el diálogo pseudo-conversacional. Esto implica que, mientras el usuario está
realizando modificaciones a los datos o simplemente viéndolos, no existe ningún tipo de locks en la base de
datos.
El control de cambios (es decir la validación entre la lectura inicial y la confirmación) se realiza a nivel de
cada tabla involucrada en la Transacción Web. Los valores leídos al momento de “enviar” los datos son
comparados con sus correspondientes, en cada tabla, en el momento de “recibir” las modificaciones (cuando
el usuario presiona Confirm). Si los valores no coinciden, se informa al usuario que hubo cambios y que debe
intentar nuevamente.

Es importante notar que el control de cambios se realiza sobre todos los atributos involucrados salvo aquellos
de tipo Long VarChar por su tamaño.

Prompts
Para cada Transacción Web se genera un Web Panel que será el Prompt por defecto (autoPrompt), y los
Prompts correspondientes a las claves foráneas que se tengan. Para modificar el Prompt llamado por defecto,
se puede utilizar la regla Prompt.

Propiedad del modelo: Generate Prompt Programs

En el caso que no se quiera la generación por defecto de los Prompts, se tiene la propiedad a nivel
del modelo: Generate Prompt Programs.

La cual permite o no la generación de las referencias a los Prompts.

Valores:

Yes: Crea el Prompt asociado a la Transacción que está siendo especificada así como las referencias en la
lógica interna de la Transacción.
No: Elimina las referencias a los Prompts asociados a la Transacción. La primera vez que la Transacción se
especifique con esta opción, el Prompt no se crea. De otra manera, los Prompts no son eliminados, solamente
se eliminan las referencias a ellos.

Valor por defecto = Yes

Prompts creados por el usuario

También es posible definir Web Panels como Prompts tal como se verá a continuación.

Uso de Web Panels en reglas Prompt

Existen casos en los que un usuario requiere crear un Web Panel que luego quiere utilizar como
Prompt para obtener valores de atributos/variables.
Para invocar el Web Panel, simplemente se utiliza la regla Prompt en una Transacción Web o dentro
de un Web Panel.

Al dispararse la regla Prompt (haciendo clic sobre un control) se abre una ventana con el Web Panel
y, al seleccionar un valor (nuevamente haciendo clic) se cierra la ventana y el valor se asigna a el/los
atributos/variables que corresponda.

Programación de un Web Panel como Prompt

El Web Panel que será utilizado como Prompt debe cumplir ciertas condiciones:

 Debe tener uno o más parámetros de tipo output. Puede tener de in, de inout también
pero lo importante es que tenga de output que son los que devolverá.

 Alguno de los atributos, variables, text blocks o imágenes del form debe tener la propiedad
de diseño ReturnOnClic en True. Puede tener habilitada esta propiedad en más de un
atributo/variable. En caso de ser una variable, tiene que tener la propiedad Read Only en
Trae para que la propiedad esté habilitada.

 Los valores a retornar (de los parámetros definidos como de output) no se determinan al
realizar clic, sino al desplegarse la pantalla por lo que tienen que tener el valor válido a
retornar en cada Load (si se muestra un grid, por ejemplo).

Si uno de los atributos, variables, text blocks o imágenes del form que tienen la propiedad de diseño
ReturnOnClic en True también tiene programado el evento Clic, el código que esté en dicho evento
se ignora. Simplemente al hacer clic se asignan los valores a las variables de tipo OUT y se retorna.

Uso avanzado

Esta funcionalidad puede no contemplar todos los casos. Por ello, también se implementó la función
ReturnOnClic() (sin parámetros) que puede ser asignada a la propiedad Link de cualquier control
(que tenga esta propiedad).

Ejemplos

Prompt de Cities

Un Prompt de Cities se programa así:


En las Reglas del Web Panel:

parm( out: &CityId);

En los Eventos:

Event Grid1.load

&CityId = CityId

Endevent

En el form:

Un grid que tiene CityNom y CityId, donde CityNom (por ejemplo) tiene la propiedad ReturnOnClic
en true.

Transacciones como Web Components

No solo un Web Panel puede ser un Web Component, sino también cualquier Transacción con
interfaz Web.

La posibilidad de definir una Transacción como Web Component permite tener en un Web Panel
varios componentes, algunos conteniendo Transacciones (para altas, bajas y modificaciones de
datos) y otros conteniendo Web Panels que despliegan información relacionada, menues, etc..

La definición y el uso de una Transacción como Web Component es como lo vimos en el capítulo
Web Components.

Observaciones

Es posible tener varios Web Components con Transacciones en un mismo Web Panel, pero se deben
tener en cuenta los siguientes puntos:

El estado de grabación no se mantiene por cada componente. Esto significa que si el usuario ingresa
a un componente y realiza una operación (por ejemplo modifica un atributo de la Transacción y
oprime el botón “Aplicar Cambios” por primera vez) y no reconfirma la misma, al realizar una
operación en otro componente (por ejemplo un GET), se pierden los cambios realizados en el
primero (es decir se refresca la página con el valor y estado que tenía antes de modificar el atributo).

INTRODUCCIÓN

Las aplicaciones Web necesitan un look & feel bastante más sofisticado que las aplicaciones Win y
los desarrolladores no tenemos las habilidades y el tiempo para lograr un diseño con esas
características.

Por esa razón, por lo general se opta por contratar servicios de diseño. Por lo cual, es necesario
luego integrar ese diseño con la aplicación GeneXus. Esta integración se logra a través de los
“Themes”.

Para el diseño gráfico contamos con el “Editor de Themes”, una herramienta de libre distribución
que se puede ejecutar en forma independiente de GeneXus.

Mientras que en versiones anteriores las propiedades de los controles en los “html forms” (Web
Panels y forms html de las Transacciones) debían ser configuradas en los controles, hoy mediante los
“Themes” se pueden definir “Clases” para los diferentes tipos de controles y asignarles propiedades
a esas clases.

Luego, los controles se asocian a esas clases, y éstos heredarán las propiedades allí configuradas. Por
lo tanto ya no es necesario establecer los valores de las propiedades para cada control en el form.
Las propiedades de los controles se configuran en un único lugar: en las clases del Theme.

Cualquier cambio de diseño que se requiera hacer, se realizará en el Theme (sin necesidad de
generar/compilar absolutamente nada), de esta forma se logra la uniformidad estética del sitio con
un bajo costo de mantenimiento (no es necesario cambiar cada uno de los objetos), y como
consecuencia se obtiene una mayor productividad en el desarrollo de aplicaciones Web.

Recuerde que en el capítulo 2 se dió una introducción del objeto Theme e incluso se realizaron
algunos ejercicios para comprender su funcionamiento.
Veremos a lo largo de este capítulo en forma más completa, las diferentes funcionalidades que
brinda este objeto.

Generalidades de un Theme

El editor de temas es una herramienta de libre distribución que se puede ejecutar en forma
independiente de GeneXus. Esto es para que la herramienta pueda ser usada por el diseñador
gráfico, y el desarrollo de la aplicación se independice e incluso se paralelice con su diseño.

Se despliega como una estructura jerárquica de Clases, la siguiente es una imagen del editor de
temas:

Se puede observar que descendiendo en la estructura jerárquica, se presentan un nodo “Classes” y


un nodo “HTMLNodes” (parte izquierda). Al centro, tenemos las propiedades correspondientes a
cada una de las Clases, y HTML Nodes; y a la derecha un preview que es una vista de cómo se
visualizará en ejecución un control asociado a la clase correspondiente.
Clases

A partir del nodo “Classes” se despliega un conjunto de clases predefinidas, correspondientes a


controles GeneXus (con excepción de la Clase “Messages”, la cual no se corresponde a un control
GeneXus, el significado de esta clase se explicará más adelante)

Cada clase reúne un conjunto de propiedades configurables por el diseñador, y constituye un


“diseño” para un tipo de control GeneXus.

Una clase podrá ser asignada a un control en tiempo de diseño, y en tiempo de ejecución a través de
la “Propiedad Class”.
CLASES PREDEFINIDAS

 Attribute

 Button

 Error Viewer

 FreeStyleGrid

 Grid

 HyperLink

 Image

 Table

 Textblock

 Form

CLASE “MESSAGES”
La clase “Messages” se utiliza para configurar los seteos de los mensajes desplegados en la pantalla a
consecuencia de Web Client Side Validation. La misma tiene dos clases:

ErrorMessages: todas las reglas error están asociadas a esta clase.

WarningMessages: todas las reglas messages están asociadas a esta clase.

Para utilizarlas, se configuran de igual forma que las restantes clases. La diferencia está en que no se
tiene ningún control GeneXus asociado. La asociación de estas clases es automática.
Nota 1: Existen también clases específicas de botones, correspondientes a aquellos que son
generados en forma automática por GeneXus en Web Transactions y Web Prompts.

Cuando se crean dichos objetos los botones se asocian a las clases correspondientes. Estas clases
son descendientes directas de la clase “SpecialButtons” que es hija de la clase “Button”:

 BtnCancel

 BtnCheck

 BtnDelete

 BtnEnter

 BtnFirst

 BtnGet

 BtnHelp

 BtnLast

 BtnNext

 BtnPrevious

 BtnRefresh

 BtnSelect

Nota 2: Las propiedades del form, que se definen en GeneXus se aplican al BODY del HTML. Esto es porque algunas de esas propiedades
no son soportadas por el tag FORM (por ejemplo, el background color).

Por la misma razón, la clase Form queda en runtime asociada al tag BODY.

CLASES ESPECIALES DERIVADAS DE “ATTRIBUTE”


Si se define una clase en el editor de temas (llamada X), derivada de la clase “Attribute”, cuatro clases
adicionales son creadas:

 ReadonlyX (descendiente de X)
Blobs:
 BlobContentX (descendiente de X)
 ReadonlyBlobContentX (descendiente e BlobContentX)
 BlobInputX

BlobContentX y BlobInputX son clases asignadas en tiempo de ejecución a los controles blob. Un control blob
consiste en el contenido y en lo que se carga en el control.
Si la clase X ha sido asociada al blob en diseño, la clase BlobContentX es asignada al contenido, y la clase
BlobInputX es asignada al control cargado.

Las configuraciones no se pueden hacer en diseño, solamente en tiempo de ejecución.


La clase ReadonlyBlobContentX es asignada en tiempo de ejecución a los blobs readonly, que en diseño
fueron asociados a la clase X.
Si una clase es renombrada, todas sus clases que se crearon antes, serán renombradas también. Por
ejemplo, si X es renombrada a Y, se obtendrán las siguientes clases:

 ReadonlyY
Blobs:
 BlobContentY
 ReadonlyBlobContentY
 BlobInputY

CLASES DERIVADAS
Se pueden crear clases derivadas a partir de las clases predefinidas; el proceso de definir una clase
significa para el desarrollador asignarle un nombre (hacer botón derecho en la clase padre y clic en
“New Class”) y configurar las propiedades que le corresponden a esa clase.

Las clases hijas o derivadas quedan implícitamente vinculadas en una relación de herencia con las clases de
las cuales derivan. Como consecuencia de esto, las modificaciones en las clases “padre” se verán reflejadas
en las “hijas”, con algunas excepciones. Las modificaciones consisten en cambiar los valores de alguna de las
propiedades de la clase.

La parte inferior del editor muestra el nombre de la propiedad, junto con una descripción de la
misma. Además dirá “Inherited: True” o “Inherited: False” según corresponda.
Si para una propiedad de una clase dice “Inherited: True”, significa que su valor es un reflejo del
valor de la misma propiedad del padre. Es decir, cualquier cambio en la clase padre se traduce en un
cambio en la misma propiedad en el hijo.

En cambio, "Inherited: False" implica que un cambio en la propiedad en la clase padre no se reflejará
en la clase hija. La herencia en el valor de las propiedades se pierde cuando éstas son alteradas en
las clases hijas.

CLASE POR DEFECTO


Es posible definir una clase por defecto. Lo que es más, cuando en GeneXus asociamos un “Theme” a
un objeto, una clase por defecto es asociada a cada control definido en el objeto. La clase asignada
por defecto, es la clase que fue definida en la “Set as GeneXus Default”.

Si la clase por defecto no se indica explícitamente, será la clase predefinida por GeneXus.

La clase por defecto es identificada en el editor de temas por un triángulo azul en la esquina derecha
del icono de la clase.

Propiedades de un Theme

Las propiedades de un Theme son las siguientes:


FileName: Es el nombre del archivo físico que corresponde al Theme o al Template.

Name: Nombre lógico del Theme (o Template).

BaseImagePath: Es una propiedad editable únicamente cuando se trabaja con Templates.

Si se configura la propiedad Base Image Path del modelo, y al salvar el Theme, si parte del path dado
en alguna propiedad de una clase (como ser la propiedad Background) coincide con el indicado en la
Base Image Path, la imagen se salva relativa.

Esto es porque cuando se trabaja desde dentro de GeneXus el valor de la propiedad coincide con el
Base Image Path de la base de conocimiento.

La utilidad de esta funcionalidad es la siguiente: si el usuario que está trabajando en la base de


conocimiento tiene seteada la propiedad Base Image Path (por ejemplo en el directorio: e:\images),
pero el diseñador gráfico (quien usa el editor por fuera de GeneXus) tiene las imágenes en el
directorio c:\cliente\imagenes.

Si no se setea la propiedad cuando se trabaja con el Template, es decir, se usan caminos absolutos y
no relativos, todas las imágenes quedarán apuntando a c:\cliente\imagenes que no existe en la
máquina del usuario GeneXus y por lo tanto no se va a visualizar correctamente el Theme cuando se
incorpore a la base de conocimiento (además del hecho de que el usuario seguramente tuviera que
cambiar ese path porque no será válido en producción).

Si el diseñador configura la propiedad (en el ejemplo, con el valor c:\cliente\imagenes), las imágenes
quedarán salvadas en forma relativa, luego el usuario GeneXus debe copiar las imágenes a e:\images
para poder visualizar correctamente el Theme al incorporarlo a la base de conocimiento, sin
necesidad de algún otro procedimiento (como sería ir a cambiar uno por uno las imágenes utilizadas
en el Theme para que apunten a la imágen correcta).

Notas:

 El valor por defecto de la propiedad Base Image Path es el directorio de la base de


conocimiento.

 Se crea automáticamente un folder “CSSDesign” bajo el directorio del modelo (dataXXX). En


el directorio CSSDesign se guardan los .css generados para usar en GeneXus, con paths
absolutos; en el directorio Web se generan los css con paths relativos. Por lo tanto, no es
correcto distribuir los .css que se encuentran bajo el directorio CSSDesign.

Panel de propiedades del Editor de Temas

En este panel es posible configurar las propiedades de la clase seleccionada, o del HTML Tag
seleccionado. Junto con estas propiedades, se incluyen todas las propiedades disponibles en
GeneXus, bajo la categoría: “GeneXus Attribute Control Propierties”,como se visualiza en la figura:
Nota: Además, el alcance de las propiedades disponibles dentro del Editor de Temas puede ser
ampliado. El usuario podrá definir nuevas propiedades si lo necesita (en el caso de que no existan en
el Editor).

Las propiedades en el Editor de Temas están clasificadas de la siguiente manera:

 Background Properties
 Box
 Classification
 Extensions
 GeneXus Attributes Control Properties
 Mouse and Keyboard
 Text

Esa es la clasificación estándar de las propiedades de los CSS (Cascading Style Sheets), con la excepción del
grupo “GeneXus Attributes Control Properties”, cuyo propósito es centralizar las propiedades que pueden ser
editadas en GeneXus, para el control correspondiente a la clase.
Clase Form

El control Form, se modifica según la clase Form. Las propiedades bajo el grupo “GeneXus Form
Properties” son las que pueden ser editadas en las properties del control Form en diseño, más
algunas propiedades que complementan la funcionalidad de aquellas y se encuentran en el estándar
de CSS, que son las siguientes:

 Background

 BorderColor

 BorderStyle

 BorderWidth

 Font

 TextColor

 Height

 Width

Las siguientes propiedades aún no es posible configurarlas en el Theme:


 TooltipText

 WordWrap

 Caption

Los colores de los links, se configuran agregando Tags HTML.


Clase Button

Dentro de las propiedades del grupo “GeneXus Button Control Properties”, se tienen las siguientes
propiedades:

 BackColor

 Background

 BorderColor

 BorderStyle

 BorderWidth

 Font

 ForeColor

 Height

 Width

Clase Attribute

Dentro de las propiedades del grupo “GeneXus Attribute Control Properties”, se tienen las siguientes
propiedades, que si bien pertenecen a ese grupo, no se encuentran dentro de GeneXus para los
atributos/variables:

 BackColor

 Background

 BorderColor

 BorderStyle

 BorderWidth

 Font

 ForeColor

 Height

 ImeMode
 Width

Las propiedades tienen su definición correspondiente al pie del Editor de Temas.

Clase Image

La clase Image se puede asignar tanto a controles imagen, como a variables de tipo bitmap.

Las propiedades del grupo “GeneXus Image Control Properties”, para imágenes son las siguientes:

 BackColor

 BorderColor

 BorderStyle

 BorderWidth

 Font

 ForeColor

 Height

 Width

En particular, el valor de la propiedad Margin del Editor de Themes, se suma al valor de las
propiedades Hspace y Vspace de GeneXus (caso de imágenes).

En la documentación del CSS se muestran que se maneja el siguiente concepto:

Margin

Border

Padding
Content

Las propiedades hspace y vspace son similares a border, por eso se "suman" cuando se define un
margin.

Clase Table

Las propiedades del grupo “GeneXus Table Control Properties”, para tablas son las siguientes:

 BackColor

 Background

 BorderColor

 BorderStyle

 BorderWidth

 Height

 Width

 LinesColor

 LinesFont

Clase Grid

La propiedad que se encuentra en el grupo “GeneXus Grid Control Properties”, y no está en diseño
en GeneXus, es:

 BorderStyle

Propiedades que están en diseño en GeneXus, y no están disponibles en el Editor de Themes:

 BackColorStyle : Debe ser asignada en diseño.

 CellPadding, CellSpacing: A nivel del Editor de Themes, no existe la propiedad Cellpadding y


Cellspacing, esto es porque no las soporta el CSS.

Existe la propiedad Padding, que se compone de BottomPadding, LeftPadding, RigthPadding,


TopPadding.
En Internet Explorer a la propiedad Padding, se la interpreta como cellPadding cuando se le
pone cellPadding en 0 en diseño, y se ignora si cellPadding es diferente de 0.

Clase FreeStyleGrid

Aplican las mismas observaciones que para la clase Grid.

Clase TextBlock

Las propiedades del grupo “GeneXus TextBlock Control Properties”, que no se encuentran
disponibles en diseño en GeneXus para textblocks son las siguientes:

 BackColor

 Background

 BorderColor

 BorderStyle

 BorderWidth

 Height

 Width

Clase ErrorViewer

Las propiedades del grupo “GeneXus Errorviewer Control Properties”, que no se encuentran
disponibles en diseño en GeneXus para el control ErrorViewer son las siguientes:

 Background

 BorderColor

 BorderStyle

 BorderWidth

 Height

 Width
La propiedad BorderStyle, en el Tema, tiene una gama de valores más amplia que en el caso de la
misma propiedad en GeneXus.

Los valores que la propiedad acepta en el Tema son los que admite la tecnología CSS y son los
siguientes:

 None

 Dotted

 Dashed

 Solid

 Double

 Groove

 Ridge

 Inset

 Outset

Preview del Editor de Temas


En la barra vertical derecha del editor, hay una ventana “Preview” mediante la cual se puede mostrar o no,
una vista previa de cómo se visualizaría un control asociado a dicha clase. La misma se puede ubicar en los
diferentes lugares de la pantalla (arriba, abajo, izquierda, derecha).

La vista previa del editor se puede personalizar, agregándole “Custom Views”, que son archivos
.HTML. Para eso, agregar una nueva vista a través del menú contextual del nodo Custom Views, o
presionando la tecla INS sobre el mismo.

Para eliminar una vista personalizada basta con presionar DEL/SUPR.

La vista consiste de varios tabs (HTML browser, HTML Source y CSS).

Se puede modificar el source y ver los cambios reflejados en el HTML, pero no se salvan dichos
cambios en el documento que esté activo.
La siguiente figura muestra un ejemplo en el cual se agregó una vista previa llamada “Transacción”.

Si se tienen diferentes clases form definidas (es decir, distintas clases hijas de la clase predefinida form), el
preview para el resto de los controles se ve con un aspecto de fondo correspondiente a la configuración de
aquella clase form que sea la default.

HTML Tags

Los HTML Tags complementan la funcionalidad de los Temas, en cuanto a que permiten definir las
características de un Tag HTML, en un determinado contexto. Es decir, siempre que se quiera
establecer la configuración de un determinado Tag dentro de un contexto, se puede hacer mediante
el Editor de Temas. Por ejemplo, definir las propiedades de los links dentro de una tabla.

La configuración de los Tags HTML, dada en el editor, se ve reflejada en la página Web si esos Tags
están en el HTML de la página, en el mismo contexto con el cual fueron definidos en el editor.

El contexto está determinado por la jerarquía con la cuál se definen los Tags.

Para el ejemplo que mencionábamos anteriormente, de definir las propiedades de los links dentro
de una tabla, se haría como se muestra en la figura:
Se define un Tag A hijo de un Tag TD.

Es decir, siempre que un tag A se encuentre anidado a un tag TD en el HTML generado, se tomará el
forecolor definido en el ejemplo.

Otro caso de ejemplo sería definir un tag body y la propiedad “ForeColor” del mismo, con lo cual el
texto libre de la página tomará ese color.

Demo: Temas

Cuando se hace una aplicación Web es necesario que el sitio se vea “uniforme”.

Esto implícitamente requiere de un alto costo de mantenimiento, ya que si por ejemplo hay que
cambiar el color de un grid de azul a celeste, probablemente habría que hacerlo en todas las páginas
del sitio para mantener la uniformidad del mismo. Antes, había que ir por cada uno de los controles
de cada objeto. Hoy el cambio se realiza en un solo lado: el Tema.

Todos los objetos basados en el Tema van a reflejar el cambio automáticamente.


Cuando se salva un Tema con el Editor de Temas ejecutado desde dentro de GeneXus, se obtiene un archivo
con extensión .CSS (Cascading Style Sheet) en el directorio Web del modelo.

En tiempo de ejecución, ese archivo .CSS (que contiene la definición de las clases) es referenciado en el
Header de las páginas generadas, y se transfiere al pc del cliente para almacenarse en su caché.

Por lo cual, siempre que realicemos un cambio en el Tema asociado a un objeto, basta con llevar el archivo
.CSS a producción, para que el usuario final perciba los cambios estéticos realizados (no es necesario generar
ni compilar!!).

Veamos un ejemplo con la aplicación del curso.

Observe que los objetos de la base de conocimiento del curso están asociados al Tema “Default” (a través de
la propiedad “Theme” del objeto), y los controles de cada uno de los objetos están asociados a la clase
default correspondiente (propiedad “Class” de los controles).

Realizaremos algunos cambios a las clases de Tema “Default” y veremos cómo se reflejan los cambios en
ejecución.
Note que en nuestro caso, el directorio de producción coincide con el directorio Web del modelo, por lo cuál
no es necesario copiar el .CSS a ningún lado.

Haga clic aquí para ver la demostración

Crear un nuevo Tema

Se puede crear un Tema de dos maneras:

1. Desde el Editor de Temas

2. Desde el menú de GeneXus

Para crear un nuevo Theme desde dentro de GeneXus, se debe ir a la opción Object / New
Object / Theme

Un nuevo Theme consiste de los siguientes elementos:

 Un nombre (nombre del nodo raíz)

 Un conjunto de elementos predefinidos, correspondientes a las clases, dentro del folder


“Classes”.

 Un folder “HTMLNodes”

Como ejercicio, crearemos un nuevo Tema de nombre “Agency”.

En ese Tema vamos a definir una clase “BtnLogin” para la cual definiremos algunas propiedades. En
particular, vamos a asignarle una imagen a la propiedad “Background” de la clase.

Observe que la propiedad “Base Image Path” del Tema coincide con la misma propiedad del modelo
de diseño. Entonces, dado que vamos a usar una imagen que se encuentra bajo el “Base Image
Path”, el path de la propiedad Background del Tema quedará relativo.

Al Tema “Agency” lo vamos a asociar al Web Panel Login. Debemos cambiar la clase del botón
“Login” para que sea “BtnLogin”.
Haga clic aquí para ver la demostración

Observe que en este caso sí es necesario generar/compilar antes de ejecutar, ya que cambiamos una
property del objeto y una property del control.

Herencia de las propiedades de una clase

En el caso de que una propiedad de una clase esté marcada como “Inherited:False”, es posible
revertir la situación.

Haciendo clic con el botón derecho sobre la propiedad correspondiente, aparece un menú “Inherit
Value”. Seleccionando dicha opción, la propiedad pasará a heredar el valor de la misma propiedad
del padre.

La derivación de clases, y en particular la "herencia" le brinda al usuario facilidades en la tarea de


mantenimiento de las Clases y claridad en el diseño.

Por ejemplo si se define una clase “Bullet” derivada de Texblock, con el fin de definir las propiedades
de los textos en listas con viñetas. Supongamos que ahora se quiere tener otra clase para los textos
anidados a aquellos que están asociados a la clase “Bullet”, y se desea que tengan las mismas
características que la clase “Bullet” a excepción de la indentación. Llamemos a esa clase “SubBullet”
y creémosla como hija de “Bullet”. Esta clase solo difiere con su padre en la propiedad “TextIndent”.
Por lo cual, esa es la única propiedad que no hereda, y la única propiedad que habiéndose
modificado en el padre no se refleja en la clase “SubBullet”.

Demo: Herencia de Temas

Como ejemplo del concepto de herencia en los Temas, edite el Tema “default” de la base de
conocimiento, y modifique la propiedad “BackColor” de la clase Button.

Observe que para todas las clases hijas de “Special Buttons”, que es a su vez hija de “Button”, la
propiedad “Backcolor” está indicada como inherited:True, por lo cual, las clases hijas heredan esa
propiedad del padre.

Vea en la Transaction Web Users como todos los botones cambian el “Backcolor”, siendo que cada
uno de ellos está asociado a una clase diferente derivada de “Button”.

Haga clic aquí para ver la demostración

Haga clic aquí para ver cómo se pierde la herencia de las propiedades, al ser modificadas en la clase
hija.

Uso del Editor de Temas

El editor se puede ejecutar desde GeneXus y como un programa independiente.

Dentro de la base de conocimiento es posible salvar los Themes como archivos con extensión .CSS (objeto
Theme de la base de conocimiento). Asimismo, dentro y fuera de GeneXus, el editor permite trabajar con
archivos con extensión XML.

Esta última funcionalidad (trabajar con archivos XML) permite la integración entre el editor como aplicación
independiente y como tool de GeneXus.

Nomenclatura: Llamaremos “Template” a los archivos XML que tienen el formato de Themes, pero
no son objetos GeneXus Theme. Cuando el editor es ejecutado en forma independiente de
GeneXus, siempre se trabaja con Templates.

Entonces, un usuario podrá diseñar un sitio utilizando el editor de temas independientemente de GeneXus; el
producto de su trabajo serán archivos .XML que otro usuario (posiblemente quien desarrolle la aplicación)
podrá integrar a la base de conocimiento, y salvar como objetos GeneXus Theme (archivos .CSS).
Por otro lado, también se podrá desde la base de conocimiento salvar un Theme con extensión .XML de
manera de poder editarlo y modificarlo por fuera de GeneXus.

Con esto se logra independizar el trabajo de diseño de las páginas, del desarrollo de la aplicación.

Dado un diseño en formato XML (un Template creado con el editor por fuera de GeneXus), se puede
incorporarlo a la base de conocimiento rápidamente siguiendo los siguientes pasos:

 Abrir el Template usando el editor desde dentro de GeneXus (opción File / Open Template)
 Salvar el Template como un Theme (opción File / Save As)

Opciones del Editor para el manejo de Themes y Templates

OPCIÓN SAVE AS
Cuando el Editor es ejecutado desde dentro de GeneXus, mediante la opción del menú : File / Save
As se puede:

 Salvar un Template como un objeto GeneXus Theme

 Salvar un Template como otro Template

 Salvar un Theme como otro Theme

 Salvar un Theme como un Template

Si se tiene el check “GeneXus” habilitado, se salva como un objeto Theme.

De lo contrario (si el checkbox está deshabilitado), se habilita la opción File Name, para ingresar el nombre
que se le dará al archivo XML generado.
Si el Editor se ejecuta por fuera de GeneXus la única opción del File / Save As es guardar un Template
como otro Template.
OPTIONS / CUSTOMIZE / TEMPLATES
En el Menú Options / Customize del editor de temas se presenta el siguiente diálogo:

Mediante este diálogo se incorporan archivos XML al Editor, y se determina uno de ellos como “Default
Template”. El default Template se usa para:

 Inicializar el Theme que se crea automáticamente cada vez que se crea una nueva base de
conocimiento.
 Para inicializar un Theme si se crea desde el menú de GeneXus (Object / New Theme).

Los templates “Custom” se graban en el registry de la máquina, y por lo general solo va a ser necesario
incorporar aquellos que se sepa que se van a usar habitualmente como base para crear Themes.

FILE / NEW THEME


Es posible crear un objeto GeneXus Theme desde dentro del editor de temas, cuando éste es ejecutado
dentro de GeneXus.
Mediante el siguiente diálogo (menú File / New del editor) se puede crear un nuevo Theme en base a
alguno de los Templates (incorporados mediante el diálogo “Options / Customize / Templates”.)

Por defecto el nuevo objeto se basará en el Template default.


Mediante el combo box “Based On” se puede seleccionar un Template con el cual se inicializará el nuevo
Theme creado (los Templates de esta lista son los incorporados mediante el diálogo
“Options/Customize/Templates”)

Notas:
 Se puede optar por crear un XML o un objeto Theme GeneXus. Si el check “GeneXus” está
seleccionado, se creará un objeto Theme, de lo contrario, se crea un Template.

 GeneXus distribuye nueve templates (archivos con extensión .XML) que podrán ser usados
opcionalmente como default. Estos quedan en el folder “THEMES” de la instalación de
GeneXus.

Los Templates que son incluidos con la versión son los siguientes:

 Beach.xml

 Classic.xml

 Executive.xml

 Extreme.xml

 Fancy.xml

 Fantastic.xml

 Light.xml

 PinkPanther.xml

 Safari.xml

Los cuatro primeros son “serios” y siguen las recomendaciones de "buen uso" del diseño en Internet,
el resto son divertidos y radicales.
OPTIONS / CUSTOMIZE / EDITORS
Mediante el menú del editor Options/Customize/Editors es posible seleccionar el tipo de diálogo
para los colores.

Esta configuración se guarda por usuario.

Las opciones son:

 Default

 Designer

Si se usa el diálogo "Designer", y se definen “Custom Colors” (botón “Add to Custom Colors”), estos
valores son almacenados con el Theme.
De esta forma si se define un conjunto de colores básicos para el Theme, estarán disponibles cada
vez que se quiera editar. Por ejemplo: si se crea un Theme Gold (toda una combinación de amarillos
y naranjas), en los custom colors quedan los colores definidos como custom.
El editor como aplicación independiente

Usando el editor desde fuera de GeneXus, se pueden salvar los Themes en archivos con extensión
XML.

Se puede llamar al editor desde fuera de GeneXus, haciendo doble clic en el GXThemeEditor.exe o desde
línea de comandos pasándole como parámetro opcionalmente un archivo con extensión .XML.

De forma de distinguir cuando se edita un Template de cuando se edita un Theme, la interfaz del editor
cambia en el siguiente aspecto:

 El color de fondo del Treeview es gris y no blanco como en el caso de cuando se edita un Theme
GeneXus.

Creación de un objeto Theme por defecto cuando se efectúa la creación de una


base de conocimiento en GeneXus

Cuando se crea una nueva base de conocimiento en GeneXus, se crea un objeto Theme por defecto.

Para la inicialización de este objeto se utiliza el Theme definido como Default en el editor (“Default
Template” como se vio anteriormente).
Interacción diseñador – desarrollador de la aplicación Web

Debido a las exigencias de un buen diseño estético del sitio, por lo general es necesario contratar el
servicio de un diseñador gráfico. De ahí es que surge la necesidad de una buena interacción entre el
diseñador y quien programa la aplicación, e incluso el hecho de paralelizar ambas tareas.

Veremos en un ejemplo práctico, como a través del Editor de Temas, se logra independizar el diseño
de las páginas, del desarrollo de la funcionalidad de la aplicación.

El diseñador gráfico (sin tener GeneXus instalado en su máquina), se instalará el Editor de Temas a
través de un setup de nombre GXThemeEditor.exe .

Al ejecutar el setup, aparece la siguiente ventana:

Los únicos requerimientos para instalar el Editor de Temas en un pc son:

• .NET Framework 1.1 Redistributable Package


• Internet Explorer 6.0 SP 1 o superior

Vamos a crear un Template ejecutando el editor en forma independiente a GeneXus, y luego


integraremos ese Template a la base de conocimiento del curso, para crear un Tema y asociarlo al
modelo de la aplicación que estamos desarrollando.

Lo primero, es ejecutar el GXThemeEditor.exe. Una opción es ejecutarlo desde la instalación de


GeneXus, la otra posibilidad es instalarlo en un directorio aparte corriendo el setup del editor de
temas.

Una vez abierto el editor de temas como aplicación independiente a GeneXus, “diseñaremos” un
Template y lo salvaremos en algún directorio (es un archivo con extensión XML).

Haga clic aquí para ver como creamos el Template por fuera de GeneXus.

Una vez salvado el Template en algún directorio, vamos a ejecutar esta vez el Editor de Temas desde
adentro de la aplicación GeneXus (mediante la opción “Tools / Theme Editor”).

Para editar el Template anteriormente creado, ir al menú del Editor de Temas “File / Open
Template” y seleccionar el Template del directorio donde lo hemos guardado (con extensión XML).

Para salvarlo como un Theme de la base de conocimiento, ir al menú “File / Save As”, y estando
seleccionada la opción GeneXus del diálogo, salvarlo con el nombre “Agency”.

Una vez que es un Theme de la base de conocimiento, lo podemos asociar a la propiedad “Theme”
del modelo.

Haga clic aquí para ver como integramos el Template anteriormente creado, al modelo del curso.

INTRODUCCIÓN

Los reportes definen procesos no interactivos de extracción –consulta– de datos. Son listados que
pueden emitirse por impresora, visualizarse por pantalla, o grabarse en un archivo.
Decimos que son procesos no interactivos, porque primero se extraen los datos y luego se muestran,
no habiendo interacción con el usuario durante el proceso de extracción. El proceso es solo de
extracción: no pueden actualizarse los datos leídos.

En el presente capítulo estudiaremos las particularidades de este tipo de objetos en ambientes Web.

Propiedades del objeto Report en Web

Una solución para la generación de reportes en Web es trabajar con reportes PDF.

Con este tipo de reporte, se cuenta con mayor potencialidad para el desarrollo de aplicaciones Web.
El reporte generado como PDF puede visualizarse directamente desde el browser, así como también
grabarlo en el disco del servidor para luego procesarlo.

En este capítulo profundizaremos en la generación de reportes PDF.

Invocación del reporte

El reporte se podrá llamar desde el objeto Web tanto con el comando o función LINK como con el
comando CALL. También es posible abrir el Acrobat Reader e ingresar directamente la URL.

Configuración de propiedades

Para generar reportes PDF se deben configurar las siguientes propiedades:

 Main Program = “True”

 Call Protocol = “HTTP”

 Report Output = “Only to file”


y la siguiente regla:

 output_file( ‘xx.pdf’, ‘PDF’)

Requerimientos del cliente

El cliente que vaya a ejecutar el reporte ya sea que lo va a visualizar en el browser o que lo va a
ejecutar luego de salvarlo a un archivo, tiene que tener instalado el Acrobat Reader.

Observaciones

En este tipo de reportes se debe tener en cuenta que no se pueden utilizar la regla o función msg,
así como la regla ask.

Al definir que un objeto es main (en este caso un Reporte, pero podría ser una Transacción, Web
Panel, etc.), GeneXus genera un programa ejecutable con la lógica del objeto mismo y la de todos los
objetos invocados directa o indirectamente por él.
El programa ejecutable generado se podrá compilar y ejecutar de forma independiente, es decir, al
seleccionar Build / Run se verá como programa independiente del Developer Menu y podrá
compilarse y ejecutarse.

La definición de un objeto como main se realiza editando las propiedades del objeto, y configurando
la propiedad “Main program” del mismo con valor “True”.

Demo: Reportes PDF

Lo siguiente que haremos es crear un reporte en formato PDF que pueda ser visualizado desde el
browser, y referenciado con un link desde el Web Panel Flights, de manera de poder imprimir todos
los datos con respecto al vuelo.

El nombre del objeto será Flight.

Lo primero es crear un objeto reporte con el siguiente layout:

(Puede diseñar el layout del reporte como Usted lo crea más conveniente)

Lo que haremos es navegar por la tabla FLIGHTS para el número de vuelo recibido por parámetro y
luego navegaremos por la tabla PRICES de dicho vuelo.
Es necesario configurar las siguientes propiedades al objeto reporte recién creado:

 Main

 Call Protocol = HTTP

 Report OutPut = “Only to File”

Y la siguiente rule:

output_file('Flight.pdf','PDF');

Haga clic aquí para ver la demostración

Seguidamente, pongamos en el Web Panel Flights un link a este reporte.

Para eso, agregar un textblock en el form del Web Panel, de nombre “PrintFlight”, y en el evento
Start agregar:

PrintFlight.Caption = 'Print Flight’

PrintFlight.Link = link(RFlight )

Haga clic aquí para ver la ejecución del reporte

Se necesita el Adobe Acrobat Reader en el cliente, para visualizar el reporte PDF.

INTRODUCCIÓN

Una pregunta muy importante a la hora de desarrollar una aplicación para Internet, es la siguiente:
¿Es segura nuestra aplicación en Internet?

Como la seguridad es un concepto muy amplio, la respuesta a esta pregunta no es sencilla. Sin
embargo, dependiendo del tipo de aplicación que se está desarrollando, este punto puede ser
crucial.

Se puede decir que al publicar una aplicación en Internet, se tienen 3 niveles distintos de seguridad:

 Seguridad a nivel del Servidor Web

 Seguridad a nivel de la base de datos

 Seguridad a nivel de la aplicación

A lo largo de este capítulo se va a desarrollar cada uno de los puntos mencionados anteriormente.

Seguridad a nivel del servidor Web

Cuando se habla de la seguridad a nivel del servidor Web, se están enfrentando básicamente los
siguientes riesgos:

 Intercepción de información enviada a través de la red desde el browser al servidor o


viceversa

 Errores o problemas de configuración del servidor Web, que permitan a usuarios no


autorizados:

o Acceder a información confidencial que se encuentra en el servidor

o Ejecutar comandos que afecten el comportamiento del servidor y les permita


ingresar al sistema

Intercepción de información

El protocolo TCP/IP no fue diseñado para ofrecer servicios de comunicación seguros. En


consecuencia, la información enviada desde el browser al servidor Web o viceversa puede ser
interceptada por alguien. Es por esta razón que se debe agregar tecnología adicional para resolver
problemas de seguridad.

Desde siempre, existe una única tecnología que provee los principios para resolver estos problemas:
CRIPTOGRAFIA.

Existen servidores Web, que pueden trabajar como servidores seguros. Un servidor seguro es un
servidor Web, al cual se le habilitó la posibilidad de encriptar los datos que se envían al browser, así
como desencriptar la información recibida del mismo.

El standard más conocido de autenticación y encriptación de datos para el Web es el SSL. Este
standard fue propuesto por Netscape Communications Corporation y es el que soportan la mayoría
de los browsers (Internet Explorer, Netscape).

Para habilitar la encriptación de datos se necesita obtener un certificado de una autoridad


certificadora (por Ej.: Verisign, El Correo (en Uruguay)), este certificado es instalado en el servidor
Web, quedando habilitada la encriptación de datos. Finalmente, para activar la encriptación de los
datos a transferir, todo lo que el usuario debe hacer es realizar la solicitud del recurso a través del
protocolo HTTPS: en lugar de HTTP.

La seguridad ofrecida por el servidor Web, depende en parte también del largo del certificado
soportado. Cuanto más largo sea el mismo más segura es la comunicación de los datos. Hay que
destacar que los servidores seguros protegen “únicamente” la información confidencial de ser
interceptada por terceros, pero sin seguridad a nivel del sistema el servidor Web sigue siendo
vulnerable a ataques.

La property “Protocol Specification” aplica a la generación automática de links entre Web Panels, y
el objetivo es identificar el protocolo por defecto a usar cuando se construyen los links (HTTP,
HTTPS).

Acceso de usuarios no autorizados

La mayor parte de los riesgos que se presentan al tener un servidor Web público son asumidos por el
administrador del sitio. Desde el momento que se instala un servidor Web en un sitio, se abre para la
comunidad Internet una “ventana” a la red de área local. La mayor parte de los usuarios únicamente
visitan el sitio, otros, sin embargo intentarán entrar por la “ventana” abierta. Los resultados pueden
ser variados, desde el simple descubrimiento que la página principal del sitio Web fue cambiada,
hasta el robo de la base de datos que contiene la información de sus clientes.

Es entonces importante que el administrador del sistema defina políticas de seguridad, así como
tome las medidas necesarias para evitar el acceso de usuarios no deseados. Estas medidas pueden
ser a nivel del sistema operativo (restringir las operaciones que se pueden realizar, limitar los
permisos sobre documentos y directorios, deshabilitar servicios no utilizados, etc.), como a nivel del
servidor (aislamiento de la red, instalación de firewall).

Existe abundante documentación sobre el tema, que es recomendable leer, para saber que pasos
debería seguir al publicar documentos, o aplicaciones en su sitio Web.

Bibliografía

Verisign:

http://www.verisign.com/products/site/faq/40-bit.html#6

El correo:

http://www.correo.com.uy/CorreoCert/sitio_seguro.htm

Microsoft:

Internet Information Services (IIS) 6.0 security overview

http://www.microsoft.com/resources/documentation/WindowsServ/2003/enterprise/proddocs/en-
us/Default.asp?url=/resources/documentation/WindowsServ/2003/enterprise/proddocs/en-
us/iis_security.asp

Hardening Systems and Servers:

Checklists and Guides

http://www.microsoft.com/technet/security/topics/hardsys/default.mspx#XSLTfullModule1221211
20120

Apache Web Server:


Securing Apache: Step-by-Step

http://www.securityfocus.com/infocus/1694

Seguridad a nivel de la Base de datos

La seguridad a nivel de la base de datos es también un punto sensible a la hora de publicar una
aplicación en Internet. Es de fundamental importancia evitar que usuarios no autorizados puedan
acceder a los datos corporativos, así como que un usuario autorizado realice operaciones que le
deberían estar negadas.

Desde el punto de vista de la configuración del modelo de GeneXus, no se deben realizar


configuraciones específicas para mejorar la seguridad de la base de datos.

Seguridad a nivel de la aplicación

A nivel de la aplicación, la seguridad depende del tipo de aplicación que se esté desarrollando. La
implementación de controles de seguridad, es importante en aplicaciones en las cuales los usuarios
acceden a información confidencial, como por ejemplo sus datos personales. La razón por la cual son
necesarios dichos controles, es que los parámetros que se pasan entre objetos Web (y entre páginas
dinámicas en general) viajan visibles al usuario, como por ejemplo:

http://www.artech.com.uy/cgibin/hmyapp.exe?1,’NOMBRE’.
Por lo tanto, por más que se disponga de una página de login, donde se valida el usuario y su
contraseña para ingresar al sistema, el usuario eventualmente podría saltearse la misma, ingresando
en el navegador la URL de la siguiente página con un código de usuario válido.

Para evitar que se burle el control de acceso y permitir que se acceda a información confidencial, es
que se debe agregar algún tipo de control adicional de seguridad.

A continuación, se van a discutir diferentes posibilidades que se encuentran disponibles.

Manejo de sesiones

Una de las posibles alternativas para solucionar el problema de seguridad mencionado


anteriormente, es el uso de sesiones.

El uso de sesiones se compone de una Transacción “Security” que almacena el usuario logueado, un número
randómico de sesión y la fecha y hora del comienzo de la misma. Mediante este número de sesión se controla
que un usuario no pueda acceder a los datos de otro usuario.
Cada vez que el usuario ingresa a una página del sistema, se chequea el número de usuario y el
número de sesión. Si estos no se corresponden con los datos almacenados en la tabla SECURITY, se
muestra una pantalla indicando el error y se vuelve al usuario a la página donde se pide login y
password nuevamente. Este número de sesión es válido por un tiempo determinado que se
configura en el procedimiento. Si el usuario está logueado por más de dicha cantidad de tiempo, se
muestra la misma pantalla de error.

A continuación se presenta un ejemplo del funcionamiento de las sesiones. La página principal de la


aplicación es Login, donde se controla la validez del usuario y su contraseña.

La primera vez que un usuario ingresa al sitio debe registrarse al mismo, creando un nuevo usuario
(navegando a través del link “Click here to complete a brief registration form”, el cual lo lleva a la
Transacción “Users”). De esa forma se da de alta el usuario, y se crea un registro en la tabla
SECURITY con el identificador del usuario, el número randómico de sesión, la fecha y hora de la
registración.

Luego se llama a la página donde se muestra la información a la cual únicamente los usuarios
registrados pueden acceder, en este caso, ingresar al Web Panel “MainSearch” para hacer consultas
sobre los vuelos.
En el evento Start del Web Panel “MainSearch”, se llama al procedimiento “Checksesion”. Este
procedimiento verifica que el número de sesión del usuario recibido se corresponda con el que se
encuentra almacenado, así como su validez. Si alguna de las condiciones anteriores no se cumple, se
llama a una página de error, donde se explica al usuario la causa del mismo. Hay que darse cuenta
que en ese caso nunca llegaría a visualizarse la página “MainSearch”.

El otro caso que queda por analizar, es cuando el usuario ya está registrado. En este caso en el
evento que valida el usuario se realiza una llamada al procedimiento “GenSesNum” que actualiza en
la tabla SECURITY el número de sesión asignado al usuario, así como la fecha y hora de generación
del mismo. Igualmente que en el caso anterior, en el Web Panel “MainSearch” se invoca al
procedimiento “CheckSession” para validar la sesión.

Funciones de cookies

El objetivo es proveer funciones que permitan leer y grabar cookies desde objetos Web generados
por GeneXus.

¿Qué son las cookies?

Las cookies son archivos pequeños que se graban desde un Web site en las máquinas de los clientes.
Los programas CGI o cualquier aplicación que corre en un servidor, puede leer o grabar las cookies
en el cliente.

El uso más común de las cookies es la identificación de usuarios. Cuando un usuario se registra en un
Web site (Portal o E-Store), el sitio graba una cookie en la máquina del cliente con la identificación
del cliente. De este modo la próxima vez que el cliente visite este sitio, intenta leer la cookie y si la
misma existe usa el valor de la cookie para identificar el usuario y recuperar sus preferencias desde
una base de datos.

También existen otros usos de las cookies, como rotación de contenido (especialmente avisos),
mantener estado de una aplicación, etc. Incluso se pueden usar como método de almacenar el
“carrito de compras” de modo que la información del mismo quede en la máquina cliente y se
mantiene entre conexiones.

Como se menciona anteriormente, generalmente se usa una cookie para identificar el usuario (en
algunos casos, una para la sesión, en otros para el usuario), aunque se podrían poner todos los
valores de las preferencias en cookies. Lo ideal es tener una clave que viaje y con esta clave leer la
información del usuario. De este modo la información del usuario no viaja hacia el cliente, ni está en
la URL. (Ej. tarjetas de crédito, nombre, dirección) simplemente permanece en el servidor.

Hay que tener en cuenta que existe un límite en cuanto a la cantidad de cookies que el cliente puede
aceptar. El máximo son 300 cookies en total por cliente (para todos los servidores juntos por cada
browser/cliente) y 20 cookies por servidor o dominio lo cual quiere decir que si una aplicación graba
más de 20 cookies las últimas van a borrar los valores de las primeras. Además existe un límite de
tamaño de 4K por cookie, si una cookie supera ese límite es truncada.

El usuario puede preferir no grabar la cookie permanentemente (por Ej. si está accediendo desde
una máquina pública como podría ser un cybercafe) o incluso puede deshabilitar el uso de cookies,
por lo cual esta no debe ser la única manera de identificar al usuario, sino que se debe poder usar un
método alternativo en caso de que el browser no soporte o no tenga habilitado el manejo de
cookies.

Otra particularidad es que el lugar donde se almacenan las cookies (al menos en Windows) depende
del browser, por lo que si un usuario tiene más de un browser, cada uno tendrá un conjunto
independiente de cookies.

El ciclo de vida de una cookie es como sigue:

1. El usuario se conecta a un servidor que por alguna razón quiere grabar una cookie.

2. En la respuesta (HTML Headers), se indica el nombre y valor de la cookie a grabar, así como
otros valores (el más relevante es la fecha de expiración).

3. El browser recibe la respuesta y, si el valor de la fecha de expiración es en el futuro, la graba;


en caso contrario busca una con ese nombre y la borra.

4. Cada vez que el usuario se conecte a una URL de este dominio el browser enviará al servidor
las cookies que se hayan grabado desde el dominio y no hayan expirado.

5. Una vez pasada la fecha de expiración, las cookies se borran.

Para obtener más información técnica sobre cookies y su uso :


http://www.cookiecentral.com
Descripción

Se dispone de las siguientes funciones, las que pueden ser utilizadas en cualquier objeto GeneXus, el
resultado tiene sentido únicamente si dicho objeto fue llamado en forma directa o indirecta por un
objeto Web o está ejecutando en un ambiente Web.

GETCOOKIE
Permite leer una cookie, devolviendo un string con el valor. Si no encuentra la cookie (o no la puede leer por
estar deshabilitada) devuelve el string vacío.

Sintaxis

&var_char = GetCookie(NombreCookie)

NombreCookie: carácter

&var_char: carácter

SETCOOKIE
Permite grabar una cookie. Devuelve 0 (cero) si el resultado es correcto, otro valor si hubo algún
error.

Sintaxis

&var_num = SetCookie(NombreCookie, Valor, [path], [exp-date], [domain-name], [secure])

Los parámetros entre paréntesis rectos son opcionales. Si alguno de los parámetros va nulo se
asume el default.

&var_num: variable numérica

NombreCookie: Carácter. Indica el nombre de la cookie.

Valor: Carácter. Valor a almacenar.


Path: Carácter. Camino que indica para qué Web Panels la cookie es válida. Si no se especifica, la
cookie es válida para los Web Panels que están en el mismo directorio que el que la grabó, o en
directorios subordinados. Si se indica “/” la cookie será válida para todo el dominio.

Exp-date: Date/Datetime. Indica la fecha de expiración de la cookie. Si no se especifica, la misma


expirará cuando se cierre la sesión en el browser.

Domain-name: Carácter. Dominio donde es válida la cookie. Por defecto es el dominio desde donde
se creó.

Secure:Numérico. Si está en 1 la cookie se trasmite solamente si la conexión es segura (HTTPS). Si


está en 0 se trasmite siempre.

Nota: Si se activa el trace para el generador C/SQL, y se pone TraceLevel=4 o mayor se verá en el
trace todas las cookies que llegan al programa. Se imprimen una por cada línea precedidos por la
palabra cookie.

Observaciones

Las funciones mencionadas anteriormente siempre devuelven 0. La única forma de detectar si una
cookie fue almacenada es leerla. En consecuencia no se puede obtener la configuración del browser.

Ejemplos

Algunos ejemplos sencillos sobre cómo grabar una cookie son:

&Op= SetCookie(“ID_USER”, Str(UsrId), “/”, CTOD(“01/01/2002”) )

Aquí se está grabando una cookie -válida para todo el dominio- de nombre ID_USER con el valor
correspondiente al atributo UsrId y que expirará el 1° de Enero de 2002.

&OK= SetCookie(“SESSION_ID_GX”, &StrSession, “”, Nullvalue(&Fecha) )

Aquí se está grabando una cookie -válida para los Web Panels de la misma aplicación -de nombre
SESSION_ID_GX- con el valor correspondiente a la variable &Strsession. La cookie expirará al cerrar
la sesión del browser.
&Op= SetCookie(“USR_PAIS”, “UY”, “/”, ADDYR(&Today, 1), “otrodom.artech.com.uy”, 1)

Aquí se está grabando una cookie -válida para todo el dominio ‘otrodom’- de nombre USER_PAIS con
el valor UY y que expirará exactamente dentro de un año.

Tipo de Datos WebSession

WebSession es un tipo de datos de GeneXus que permite almacenar datos en una sesión de usuario
del servidor Web. De esta manera se pueden tener variables globales, accesibles mientras la sesión
esté activa. Los mismos aplican a los siguientes objetos: Transacciones, Web Panels, Procedimientos;
para el lenguaje Java.

Descripción

Los servidores Web permiten manejar el concepto de sesión. Una sesión se identifica por una clave
única, que se mantiene mientras el usuario continúe en el sitio Web. El objeto WebSession permite
almacenar información que será visible desde cualquier objeto Web dentro de la sesión activa como
si fueran variables globales al sitio.

Para utilizar el objeto WebSession, se debe definir una variable de este mismo tipo y aplicarles los
métodos y propiedades adecuados.

Propiedades

Id

Esta propiedad retorna un String que es el identificador de la sesión.

Ejemplo:

&Iden = &Session.Id

Métodos

Set(key, value)
Permite hacer una entrada en la sesión activa. Key y value deben ser del tipo String.

Ejemplo:
&Session.set(“user”, &User)

Get(key)

Retorna un String correspondiente a la entrada key de la sesiones. En caso de que la clave no exista retorna
el String nulo.

Ejemplo:
&User = &session.get(“user”)

Remove(key)

Permite remover un valor de una sesión.

Ejemplo:
&Session.remove(“user”)

Destroy()

Detruye el contenido de la sesión. Es recomendable utilizarlo cuando el usuario hace un “logout”, si es que
existe este concepto en la misma.

Ejemplo:
&Session.destroy()
Consideraciones Generales

El ID de la sesión se guarda en una cookie en el cliente, aunque esto es transparente para el


programador.

La validez de la Websession es similar a la validez de las cookies que solo valen por la sesión. Esto
quiere decir que si se abre una instancia nueva del browser, se pierde la sesión, pero si se abre en
una ventana nueva se mantiene.

Los datos y el ID de una sesión son diferentes para cada generador. Esto implica que no puedo hacer
un link de un Web Panel .NET a un Web Panel Java y mantener los valores de la sesión

Si no se ejecuta el “destroy()”, el servidor Web destruye la sesión cuando ha pasado un determinado


tiempo desde la última vez que se utilizó. Esto depende del servidor Web/plataforma, y se configura
de forma nativa en cada una.

La forma en que se almacena la información de la sesión también depende de la plataforma, y


condiciona la capacidad de tener la aplicación en más de un servidor Web. Básicamente, si la sesión
se almacena de forma local al servidor Web, solo es visible en ese servidor Web, por lo que si el
siguiente request del cliente va a parar a otro servidor Web, no va a tener disponible los valores de
sesión.

Encriptación de Parámetros

Los objetos Web generados con GeneXus, permiten visualizar los parámetros que se pasan entre los
objetos en la barra de dirección del browser. Esto hace que, si se pasa información reservada como
parámetro entre objetos Web (Número de cliente, por ejemplo), las aplicaciones no sean muy
confiables en cuanto a la seguridad, porque un usuario podría simplemente cambiar el valor de
dicho parámetro en la URL y disponer de información sobre la que no debería tener acceso. No
sucede lo mismo si se utilizan cookies, en este caso no hay problemas de seguridad.

Es por eso que se hace necesario pasar los parámetros sin que el usuario de la aplicación los conozca
o sea encriptar los parámetros.

En GeneXus se implementa la encriptación de los parámetros de los objetos Web que van en la URL
en forma automática y transparente para el usuario. Esto aplica a los siguientes objetos Web: Web
Panels, Transacciones Web.

Descripción

Para poder realizar la encriptación de parámetros en objetos Web se implementaron funciones


estándar que contienen las funciones básicas de encriptación y algunas funciones adicionales (las
que requieren manejo de parámetros y cookies).
Con respecto al diseño de los objetos la encriptación de parámetros no implica ningún cambio, se
programan de la misma forma que hasta el momento.

Las ventajas del uso de la encriptación de parámetros son:

 Que los usuarios finales no sepan el o los datos que van en los parámetros

 Que los usuarios finales no puedan modificar el o los datos que van en los parámetros

Se agrega la propiedad “Encrypt URL Parameters” a nivel de modelo, en el grupo “Web Information”
y también a nivel de objeto.

Para la propiedad a nivel de modelo los valores posibles son:

No: Indica que No se van a encriptar los parámetros que van en la URL de los objetos Web, siendo
éste el valor por defecto.

Session Key: Indica que se van a encriptar los parámetros que van en la URL, utilizando una clave
diferente para cada sesión. La encriptación se realiza a través del uso de cookies locales.Este valor
ofrece un nivel de seguridad mayor, pero no permite compartir URLs. Esto significa que no es posible
para un usuario X enviar una URL que tenga parámetros a otro usuario Y, ya que en este caso la URL
no va a funcionar porque se necesita la cookie correspondiente para la desencriptación.

Site Key: Se encriptan los parámetros que van en la URL de los objetos Web, pero la clave de
encriptación va a ser la misma para todo el sitio. En este caso no se utilizan cookies. Esto da un nivel
de seguridad menor pero facilita el traspaso de links.

La propiedad a nivel de objeto, además de los valores mencionados tiene el valor “Use model’s
property value”. Este valor indica que se va a tomar el valor de la propiedad del modelo para realizar
la encriptación de ese objeto. Este es el valor por defecto.

Consideraciones Generales

SESIONES DEL BROWSER


Una sesión del browser queda determinada por una instancia del mismo. Por ejemplo, si en un
máquina se ejecuta el browser de Internet y a partir de ese browser se abre otra sesión (a partir de
la opción de menú File/New/Window o a partir de un link), ambas sesiones pertenecen a la misma
instancia del browser.

En cambio, si se abre una sesión del browser, y luego se ejecuta nuevamente el exe del browser para
abrir una nueva ventana, las dos ventanas no pertencen a la misma instancia.

Con esto, si se ejecutan objetos Web, y se configuró la propiedad del modelo (o la propiedad a nivel
de objeto) con el valor “Session Key”, la cookie que se defina para guardar este valor va a funcionar
en las sesiones del browser que compartan la misma instancia.

PREFERENCIA A NIVEL DE MODELO VS. PROPIEDAD A NIVEL DE OBJETO


Los valores “Session Key” y “Site Key” a nivel de la propiedad del modelo, determinan que todos los
llamados entre objetos Web se harán con parámetros encriptados. Para tener únicamente las
llamadas entre algunos objetos con parámetros encriptados se debe indicar el valor “No” en la
propiedad a nivel de modelo y el valor “Session Key” o “Site Key” en el objeto Web que lo requiera.

Si se tienen valores configurados para la propiedad a nivel de modelo y la propiedad a nivel de


objeto para encriptar parámetros, ésta última tiene prioridad sobre la primera.

Cuando se utiliza la propiedad a nivel de objeto para encriptar parámetros, y se realizan varios
llamados entre objetos Web, se debe tener en cuenta que los valores utilizados por todos lo objetos
involucrados debe ser el mismo. Por ejemplo: Si se tiene un Web Panel que llama a otro pasándole
parámetros, y se quieren visualizar estos parámetros encriptados, en ambos Web Panels se debe
configurar el mismo valor para la propiedad “Encrypt URL Parameters”. Lo mismo sucede si el árbol
de llamadas involucra a más objetos Web, todos (los llamados y los llamadores) deben tener
configurada la propiedad “Encrypt URL Parameters” y todos deben tener el mismo valor en dicha
propiedad.

PROPIEDAD “ENCRYPT URL PARAMETERS” EN PROMPTS


Los parámetros de los prompts asociados a las Transacciones Web no es posible encriptarlos. Esto es
porque el llamado a los prompts se realiza desde el cliente y para realizar la encriptación se debe ir
al servidor.

Ejemplos

Si se tiene un Web Panel que recibe parámetros y no se utiliza la encriptación de parámetros, la URL
correspondiente al Web Panel será del estilo:
http://localhost/HINGRESO_WebObj/hdospar.asp?2,3

Si, en cambio se utiliza encriptación de parámetros (propiedad “Encrypt URL Parameters” en


“Session Key” ó “Site Key”), la misma URL se generará de la siguiente forma:

http://localhost/HINGRESO_WebObj/hdospar.asp?lQ/tK1lefxCZMVoXrnmrTQ==

Comparación de alternativas de seguridad en la aplicación

A continuación se realiza una comparación entre las soluciones disponibles para agregar seguridad
a una aplicación Web.

Cookies

Ventajas

 No es necesario el pasaje de parámetros entre Web Panels, ya que los valores se graban en la
cookie.

 Si las cookies no son temporales, se puede saber si el usuario ya accedió anteriormente a la


aplicación.

Desventajas

 Tienen limitaciones en cuanto al tamaño máximo, cantidad de cookies que se pueden grabar.
Se tiene dependencia de la configuración del browser.

Manejo de sesiones

Ventajas

 Es independiente de la configuración del browser del PC del cliente.

Desventajas
 Mayor complejidad de programación

 Pérdida de información: si el usuario pasa a una página estática, y luego vuelve a ingresar la
URL en el browser, debe volver a loguearse.

Tipo de datos Web Session

Ventajas

 Presenta las mismas ventajas que el uso de cookies.

Desventajas

 Depende de la configuración del browser. No permite compartir datos si los objetos son
generados en diferentes lenguajes. Por el momento no es soportado por C/SQL.

 No es posible compartir la información de sesión entre diferentes servidores, ya que es local al


servidor Web.

 La destrucción de los datos depende del browser utilizado.

Encriptación de la URL

Ventajas

 No se requiere programación alguna, simplemente se modifica el valor de una propiedad.

Desventajas

 El tamaño de la URL aumenta al ser encriptada, por lo tanto si el pasaje de parámetros es


importante, se puede llegar al máximo aceptado por el browser. Requieren del uso de cookies
en el caso de “Session Key”.

Características por Generador

Además de los temas vistos anteriormente, existen algunas características particulares para cada
generador que permiten brindar mayor seguridad a las aplicaciones.

Generador .NET

Para el Generador .NET existen las siguientes propiedades a nivel del modelo:
 Generate strong named assemblies

 SessionState

La primera, determina que los objetos main y/o dlls (assemblies) generados tengan un nombre único
o no. Esto permite acceder a un conjunto de ventajas importantes que provee el Framework .NET,
como ser la configuración de seguridad para el assembly.

En cuanto a la propiedad SessionState, se refiere a la implementación del manejo de sesiones (Tipo


de dato Websession) el generador utiliza el HttpSessionState provisto por el Framework. Por lo que
existen diversos modos de almacenar la session state. Con lo cual es posible configurar por ejemplo,
el tiempo que viven las variables de sesión. Por más información:

http://www.gxtechnical.com/gxdlsp/pub/iehelp.htm?genexus/csharp/docum/manuals/9.0/manualn
et90.htm

Generador Java

Con el Generador Java existe la posibilidad de conectar un servidor Web al motor de servlets, de
forma de que los requerimientos vayan directamente al servidor Web (al puerto 80). Luego éste los
redirecciona al motor de servlets (puerto 8080 por defecto), quien es que los resuelve, y manda la
respuesta al servidor Web. El motor de servlets ejecuta los servlets, y es quien establece la conexión
a la base de datos. El servidor Web solo sirve de "intermediario" como una capa más de seguridad,
pero allí no se ejecuta nada. Este servidor puede estar en el DMZ entre dos firewalls, uno que lo une
a Internet, y otro a la red local.

Por más detalles técnicos de este tema, se recomienda acceder al siguiente link:

http://www2.gxtechnical.com/portal/hgxpp001.aspx?15,4,61,O,S,0,,17187;S;0;A;0;0;;;;;;;;;;;;;;;;;A;%2
0%20/%20%20/%20%20;;0;9;;17187;;99;;0;1;%200;N;N;S;B;B

Demo: Uso de Cookies

Como hemos visto hasta el momento, si bien el Web Panel MainSearch permite realizar consultas
para que pueda ver los detalles de un vuelo se exige que el usuario ya se haya identificado y que sea
por supuesto un usuario válido.
En caso de ser un usuario registrado y haberse identificado, se mostrarán los detalles del vuelo y
precios del mismo, pero en caso contrario se le dará al usuario un mensaje diciéndole que "Debe
identificarse antes de realizar alguna compra".

Todo esto es lo que tenemos que implementar en el Web Panel MainSearch. Es decir, que a partir
del link asociado al atributo FlightDsc se requiere que la aplicación sea segura.

Utilizaremos cookies “temporales” para evitar que todo usuario que se registre al sitio desde el
mismo computador utilice la misma información de conexión.

Disponemos de un Business Object (security.xpz) que brinda los objetos necesarios para definir la
“seguridad” en las aplicaciones Internet utilizando cookies.

Implementación de la seguridad en nuestra aplicación

El control de la seguridad lo implementaremos utilizando:

 Una tabla denominada Security donde se almacena para cada nuevo usuario el número
generado en forma aleatoria para su sesión, así como la fecha y hora de la última sesión
activa.

La estructura de la tabla sería entonces la siguiente:

SecId*
SecRnd (Número de sesión randómico)
SecDate (Fecha de Inicio de Sesión)
SecHour (Hora de Inicio de Sesión)

 Una cookie denominada SECURITY que concatena (separados por una coma) el número
identificador del usuario (atributo UserId), así como un número generado en forma
aleatoria de la sesión de este usuario (atributo SecRnd).

Descripción de Objetos del archivo security.xpz

A los efectos de una buena comprensión del xpz, se describen los objetos que lo integran y
utilizaremos.
SECURITY
Es la Transacción que define la tabla de SECURITY.

INSERTSEC
Este Procedimiento da de alta en la tabla SECURITY la primera vez que el usuario inicia una sesión en
el Web.

CHECKSESSION
Este procedimiento valida el número de sesión recibido con el usuario que está logueado, y devuelve
el código de validación resultante. A la sesión se le da una validez de 1 día.

Se distinguen tres casos: cuando el usuario tiene iniciada una sesión vigente (valor S), cuando el
usuario tiene una sesión vencida (valor V) y cuando el usuario tiene una sesión, pero no coincide el
número randómico de sesión (valor I).

GENSESNUM
Este procedimiento actualiza el número randómico de sesión del usuario, junto con la fecha y hora
en que se logueó por última vez.

RETSTR
Este procedimiento devuelve los dos valores almacenados en la cookie: el número de usuario y el
número de sesión.

ERROR
Este Web Panel se invoca siempre que sea necesario cancelar la ejecución de la aplicación (por
ejemplo: cuando la sesión ya no está vigente se invoca automáticamente a este Web Panel,
desplegándole al usuario el mensaje correspondiente).

Lo primero a hacer entonces es consolidar en la base de conocimiento del curso el archivo


security.xpz.

¿Dónde dentro de la aplicación tenemos que grabar las cookies? o lo que es lo


mismo ¿dónde dentro de la aplicación tenemos que invocar a la función
SetCookie?

La cookie se debe grabar cuando el usuario se registra en el sitio por primera vez (en la Transacción TUsers) y cada vez que se identifique.

1) Cuando el usuario se identifica,luego de chequear que el usuario y password ingresados son válidos, tenemos que grabar una cookie (con
la función SetCookie), y luego en el evento Start del Web Panel Flights de “acceso limitado a usuarios registrados” tenemos que leer la
cookie (con la función GetCookie). Como definimos anteriormente un web component para encapsular el procedimiento de login,
simplemente debemos editar el evento “Enter” del Web Panel definido como web component y realizar la siguiente modificación:
Event Enter

For each

where UserNickName = &UserNickName

&UserId = UserId

If UserPwd = &UserPwd

&SecRnd = Udp(PGenSesNum,UserId)
&CookieVal = Concat(trim(Str(UserId)),trim(Str(&SecRnd)),',')
&result = SetCookie('SECURITY',&CookieVal)

Msg( 'Welcome')

Else

Msg('Invalid Password')

EndIf

when none

Msg( 'Invalid User')

Endfor

2) El otro lugar donde tenemos que grabar una cookie es cuando se da de alta un usuario nuevo. Es decir, que en la Transacción Users
(TUsers), luego de dar de alta el usuario, tenemos que grabar una cookie en el PC Usuario con el UserId del usuario nuevo y el número de
sesión randómico. Para esto vamos a crear un procedimiento Login con el siguiente código:

&SecRnd = Udp(PGenSesNum,&UserId)

&CookieVal = Concat(trim(Str(&UserId)),trim(Str(&SecRnd)),',')

&result = SetCookie('SECURITY',&CookieVal)

Este procedimiento debería recibir como parámetro la variable &UserId. En la Transacción TUsers, deberíamos agregar en las reglas:

Call(Plogin,UserId) on AfterComplete;

Hagamos entonces estas modificaciones necesarias

¿Dónde tenemos que leer las Cookies? Es decir ¿dónde debemos invocar a la
función GetCookie?

Como ya dijimos antes, todos los Web Panels del sitio de “acceso limitado a usuarios registrados”, deben realizar el control de la seguridad
leyendo la cookie y comparando los valores obtenidos con los valores almacenados en la tabla de SECURITY. En nuestro caso, en el link
asociado al atributo FlightDsc.

Hagamos el control en el Web Panel “FLIGHTS” de que el usuario tiene que ser un usuario
“registrado” para poder VER DETALLES Y PRECIOS ...

El evento asociado al link del atributo FlightDsc quedaría entonces:

Event Flights.Load

&interesting = Loadbitmap("int_unsel.bmp")
&CookieVal = GetCookie('SECURITY')

Call(PRetStr,&CookieVal,&UsrStr,&SecStr)

&UserId = Val(&UsrStr)

&SecRnd = Val(&SecStr)

&result = Udp(PCheckSession,&UserId,&SecRnd)

If &result = 'S' // si la sesión de dicho usuario está vigente

FlightDsc.Link = Link(Hflights, FlightId)

Else // si la sesión de dicho usuario no está vigente

Call(HError)

Endif

EndEvent

Haga clic aquí para ver la demostración

Notas:

 Observe que para el usuario de prueba que se estaba usando en los ejercicios anteriores, al
momento de creado no se tenía en cuenta la seguridad del sistema, por lo cual no fue dado
de alta en la tabla de seguridad, y cualquier intento de realizar una compra con él va a dar
error. Entonces, para probar el ejercicio hecho en este capítulo, dé de alta un nuevo usuario
a través de la Transacción Users.

 El Web Component Login, es el que tiene la lógica de seguridad y es importante que el


usuario en cualquier parte del sitio se pueda logear, y navegar por toda la aplicación hasta
que opte por ver detalles y precios de los vuelos. Por tal motivo, el Web Component Login
está presente en la Master Page y por lo tanto está en todos los objetos del sitio.
INTRODUCCIÓN

Patterns es una herramienta, que se puede utilizar tanto desde GeneXus como en forma
independiente. Permitiendo aplicar a una base de conocimiento cierto patrón (pattern), y que se
generen todos los objetos GeneXus necesarios para implementar el patrón, para aquellas instancias
que se hayan seleccionado.

En este capítulo profundizaremos en los patterns y las formas de utilizar dicha herramienta como
medio para obtener una mayor productividad en el desarrollo de las aplicaciones Web.

Aplicaremos la herramienta en nuestra base de conocimiento para definir nuevos objetos.

Generalidades

Es común sentir al desarrollar aplicaciones que algunas partes son muy similares pero no
exactamente iguales.

Por ejemplo, si se tienen clientes y productos, si bien los actores de la realidad (clientes y productos)
son totalmente diferentes, los “Trabajar con” para cada uno de ellos tienen muchas cosas en común:

 grid en el form

 un conjunto de variables para utilizar en filtros

 ordenamiento de los datos que se muestran

 acciones que se ofrecen de actualización de la base de datos, consultas, etc.

Esta situación es llamada “Pattern” (patrón) y ha sido un tema muy popular en la industria del
software recientemente.

Dado que con GeneXus trabajamos a nivel de conocimiento y no de código, aplicamos el concepto
de patrones a reusar conocimiento.
Hemos desarrollado un marco de trabajo con las siguientes características:

• Activo: Se generan objetos GeneXus que implementan cierto patrón para una o varias
instancias elegidas.

• Reutilización de conocimiento: Se trata de un nuevo nivel de reutilización de conocimiento,


ya que el mismo conocimiento puede utilizarse para diferentes situaciones.

• Abierto: Cualquier persona puede crear un patrón o modicar uno existente.

• De fácil uso: (A excepción de la creación de nuevos patrones).

Descripción de la herramienta

Patterns es una herramienta que es parte de GeneXus 9.0 (Tools / Patterns), que puede ejecutarse
también como aplicación independiente.

El objetivo de esta herramienta es el incremento de la productividad y calidad en las aplicaciones.

Básicamente la herramienta Patterns permite aplicar a una base de conocimiento cierto patrón
(Pattern), y generar todos los objetos GeneXus que implementen el Pattern para aquellas instancias
que se hayan seleccionado. Es importante tener en cuenta que la base de conocimiento debe estar
en diseño para poder utilizarla.

Existe un conjunto de Patterns muy útiles ya definidos (al instalar la herramienta se instalan) para
que el desarrollador pueda comenzar a usar dichos patrones rápidamente.

A su vez la herramienta permite crear Patterns nuevos, siendo esta una tarea un poco más compleja.
Requerimientos

Esta herramienta se puede utilizar únicamente con los generadores .NET y Java. Para obtener más
detalles de los requerimientos de software de instalaciónla ver la siguiente página:

http://wiki.gxtechnical.com/wiki/tiki-index.php?page=PatternsInstallation

Patterns existentes

Hasta ahora los Patterns con los que contamos son:

Work With: “Trabajar con” en Web; genera a partir de una Transacción (o para todas aquellas
Transacciones que se deseen), todos los objetos necesarios para tener una aplicación Web: trabajar
con, views, seguridad, etc..

Bill of materials: Permite generar a partir de una Transacción, otra que representa la relación
compuesto–componente.

OAV: Objeto-Atributo-Valor; genera a partir de una Transacción otras dos Transacciones que
permiten extender la original, con el objetivo de permitir definir atributos en tiempo de ejecución.

Además, seguimos trabajando en la definición de nuevos Patterns. Tenemos un catálogo con una
lista de Patterns, algunos de los cuales ya están implementados y otros sugeridos para una futura
implementación. Para acceder al catálogo:

http://wiki.gxtechnical.com/wiki/tiki-index.php?page=Business+Patterns+Catalog

Demo: Configuración de Patterns y definición de instancias

Una vez abierta la base de conocimiento en GeneXus, en el modelo de diseño, se dispone de la


opción Tools / Patterns para acceder a la herramienta. Una vez ubicados en la herramienta veremos
los pasos a seguir para aplicar el Pattern Work With.
1) Tools / Change Pattern Configuration. Desde esta ventana vamos a modificar algunas de las
propiedades del archivo WorkWith.config, de forma tal que al momento de aplicar el Pattern ya
tome en cuenta dichos cambios en el patrón. Para ello haremos los siguientes cambios:

 Template / Update transaction = Apply WW Style

 Grid / SaveGridState = True

 Grid / EnableDisablePaging = True

 MasterPage = MyMPage

 Standar Actions / Export = False

Haga clic para ver la demostración

2) A continuación, mostraremos cómo hacer para modificar los “Instance File”. En este caso
quitaremos algunos atributos del grid de los Work With.

Haga clic aquí para ver la demostración

3) Build / Configure GeneXus Integration. Desde esta pantalla configuraremos las opciones de la
integración del resultado de aplicar el pattern Work With en nuestra base de conocimiento.

Haga clic para ver la demostración

4) Procederemos a aplicar y generar los objetos resultantes de aplicar el pattern. Para ello,
marcaremos todas las Transacciones y con el botón derecho seleccionamos “Generate, Apply and
Consolidate”, como se muestra aquí.

Uso de la herramienta

A continuación veremos los distintos pasos a seguir para el uso de la herramienta Patterns y como
obtener rápidamente una aplicación Web ejecutando en este caso el Pattern Work With. Donde
los objetos generados estarán basados en la definición que se realizó para ese patrón y a su vez
quedarán generados con código de calidad, y con lo cual se podrá visualizar el aumento de
productividad que se obtiene al utilizar la herramienta.

Paso 1

Una vez abierta la base de conocimiento en GeneXus, en el modelo de diseño, se dispone de la


opción Tools / Patterns para acceder a la herramienta.

Cuando se trabaja con la herramienta Patterns con una base de conocimiento por primera vez, se
presenta un diálogo cuyo título es “Workspace Configuration”. Este diálogo permite configurar
algunas opciones relacionadas a la base de conocimiento, otras opciones relacionadas al pattern a
ser aplicado, y otras opciones relacionadas a operaciones de GeneXus (impactar, especificar, etc.)
que pueden ejecutarse utilizando la herramienta Patterns. En este punto inicial puede cerrarse este
diálogo si se desea, y posteriormente es posible ingresar al mismo, mediante el ítem Build /
Configure GX Integration (ver paso 8).

Paso 2

Se despliega información de la base de conocimiento utilizando GXPublic . Dado que muchos


Patterns usan Transacciones, se muestra una lista de las Transacciones disponibles en el tab KB
Explorer:
GxPublic es el componente de GeneXus que permite acceder a la información de la base de
conocimiento programáticamente.
Paso 3

Se debe seleccionar en el combo box mostrado en la barra de herramientas, el pattern que se desea
aplicar:

Se ofrece por defecto la lista de patterns predefinidos.

Paso 4

Debemos obtener un “Instance File” por cada caso al cual queramos aplicar el pattern. El “Instance
file” es un archivo XML con los datos propios de la instancia.

Si bien es posible crear cada “Instance File” de cero, los patterns suelen proveer una funcionalidad
para crear “Instance Files” por defecto, y luego poder modificarlos fácilmente.

Esto se puede lograr de dos formas posibles en el tab KB Explorer:

 Teniendo una Transacción (o varias) seleccionada(s) se presiona botón


derecho opción Generate Instance File.
 Doble clic en una Transacción.

Llamamos proceso de instanciación de un patrón al proceso de aplicar un patrón a una o varias


situaciones (instancias).

En el proceso de instanciación de un patrón las entradas son:

• Instance files: por cada situación o instancia a la cual se quiera aplicar el patrón, habrá que
crear un instance file con la información propia de esa instancia en particular (atributos a
mostrar, etc.). Cada instance file es en definitiva un archivo XML con los datos propios de la
instancia.

• Template files: contienen la implementación del patrón y de su aplicación a las instancias.

El resultado que se obtiene del proceso de instanciación de un patrón (procesando los instance files
y template files) es: un conjunto de objetos GeneXus para ser consolidados en la base de
conocimiento.
Paso 5

Cada “Instance File” es un archivo XML con estructura jerárquica, conteniendo cada uno de sus
nodos un conjunto de propiedades. La herramienta Patterns ofrece dos editores, para editar cada
“Instance File” en el panel derecho: el editor XML View y el editor Tree View.

El editor XML View permite editar los instance file directamente en su formato XML. Por su parte el
editor Tree View es mucho más amigable, sencillo de usar, y con interfaz en alto nivel que provee
mayor funcionalidad para ayudar en el proceso de edición. Por todo esto el editor Tree View es el
más usado y recomendado para usuarios no avanzados.

Paso 6

Los “Instance Files” se deben grabar. Para ello, bajo el ítem Instance se ofrecen las opciones Save
(salva el “Instance File” con el que se esté trabajando) y Save All (salva todos los “Instance Files” en
el caso que ya existan, pregunta si se desea reemplazar).
Los “Instance Files” que no se han salvado aún se visualizan con el nombre: <Transaction
Name.Pattern>*. Una vez salvados se visualizan con el nombre: Transaction Name.Pattern (ej:
Country.WorkWith).

¿Dónde se almacenan físicamente los “Instance Files”? En el subdirectorio Templates bajo el


directorio de la base de conocimiento.
Seleccionando el tab Folder Explorer se pueden visualizar estos archivos:

Es importante tener en cuenta que si se generan los “Instance Files” por defecto nuevamente a
partir de las Transacciones, serán sobrescritos.

Paso 7

Una vez creados y editados los “Instance Files”, el siguiente paso es que la herramienta genere los
objetos GeneXus que implementan el pattern para las instancias. Para lo cual se cuenta con las
siguientes opciones :

 Build / Apply Pattern

 Build / Apply and Consolidate (posibilita que se consoliden a continuación)

 Estando posicionado en el tab Folder Explorer, luego de haber


seleccionado los “Instance Files” (.workwith files), con botón derecho, se
pueden ejecutar las opciones Apply Pattern o Apply and Consolidate.

A su vez es importante tener en cuenta que si se selecciona la opción Apply and Consolidate se
efectuarán también las siguientes acciones:
 Se configurará como Tema por defecto de la aplicación al Tema Fantastic.

 El directorio Images será copiado automáticamente bajo el directorio KBPath\Templates.

 La propiedad del modelo de diseño "Base image path" se configurará con el valor anterior.

También es posible seleccionar una Transacción o un grupo de Transacciones estando posicionado


en el tab KB Explorer, y ejecutar la opción Generate, Build and Import. Pero es importante entender
que seleccionando esta opción, se generarán los “Instance Files” por defecto nuevamente para las
Transacciones seleccionadas, y luego de ello, se generarán los archivos <TransactionName>.xpz.xml
correspondientes y se consolidarán en la base de conocimiento. Si se está seguro de que los
“Instance Files” por defecto no necesitan ser editados, es posible seleccionar esta opción
directamente.

Paso 8

Para hacer más fácil todo el proceso, desde la herramienta Patterns, es posible ejecutar las acciones
que se realizan con GeneXus: impactar el modelo, especificar, generar, compilar y ejecutar.

Estas acciones se configuran en el diálogo “Workspace Configuration” que se abre en el momento de


abrir la base de conocimiento con la herramienta Patterns, o seleccionando luego la opción Build /
Configure GX Integration.
OPCIONES DISPONIBLES EN EL DIÁLOGO
Model: Muestra los modelos definidos en la base de conocimiento, y permite seleccionar uno de
ellos. Se requiere tener los modelos generados.

Apply and Consolidate: Al seleccionar dicha opción, es posible ejecutar más acciones además de la
generación de objetos y consolidación. Este combo ofrece las siguientes posibilidades:

 Consolidate Only (Apply and Consolidate)

 Impact Model (Apply and Consolidate + Impact Model)

 Impact, Specify (Apply and Consolidate + Impact + Specify)

 Impact, Specify, Compile (Apply and Consolidate + Impact + Specify + Compile)

 Impact, Specify, Compile, Run (Apply and Consolidate + Impact + Specify + Compile + Run)
GeneXus Version: La versión de GeneXus correspondiente a la base de conocimiento se detecta
automáticamente (puede ser 8.0 o 9.0). El modelo se especificará / generará con dicha versión.
Build Actions: Permite seleccionar qué objetos deben especificarse y generarse al seleccionar
Specify and Generate. Las opciones disponibles son:

 Build All

 Build Pending (updated since last specification)

 Specify Consolidated Objects

Specification: Permite seleccionar el tipo de especificación / generación a ser ejecutado al


seleccionar.

Specify and Generate: Las opciones disponibles son:

 Full Specification

 Check Specification

 Force Generation

Run Command: En esta opción se debe indicar la URL que se ejecutará si se seleccionó la opción
Impact, Specify, Compile, Run. Por ejemplo, se debe escribir:
“http://localhost/services/hwwsocios.aspx”. La URL debe incluir todo el camino, incluyendo el
objeto que se va a ejecutar.

La herramienta Patterns genera un Web Panel homepage y un Procedimiento para listar todos los
objetos del pattern Work With usados. Para ejecutar la homepage, se debe configurar la propiedad
“Run Command” de la siguiente manera:

 para aplicaciones .NET la propiedad “Run Command” en


“http://localhost/services/hhome.aspx”

 para aplicaciones Java la propiedad “Run Command” en


“http://localhost:8080/servlet/hhome”
¿Cómo modificar los objetos?

En muchas oportunidades surge la necesidad de modificar los objetos resultantes de la aplicación de


cierto pattern. A continuación veremos las formas posibles de realizar las modificaciones.

Mediante GeneXus

Modificando los objetos GeneXus generados. Esta solución presenta la siguiente desventaja: en caso
de querer volver a generarlos con Patterns, se regeneran los objetos, perdiendo los cambios hechos
a los mismos.

Mediante la herramienta Patterns

 Modificando las propiedades de las instancias (en la medida que ofrezcan lo que se
desea).

 Modificando el pattern, personalizándolo para que ofrezca configurar propiedades que


implementen las necesidades.

¿CÓMO MODIFICAR LAS PROPIEDADES DE LAS INSTANCIAS?


Tomando como ejemplo del pattern Work With, veremos cómo se pueden modificar las propiedades
de una instancia.
Son muchas las propiedades que se ofrecen en los archivos de instancia correspondientes al pattern
Work With para personalizar el comportamiento de los objetos que se generarán. A continuación
describimos algunas de ellas.

Nodo Selection
El nodo “Selection” ofrece las propiedades relacionadas al Web Panel Work With que se generará
para la instancia. Sus sub-nodos son:

Modes
Este nodo permite definir en cuáles modos se ofrecerá invocar a la Transacción. Las posibilidades y
sus valores por defecto son:

Insert: True

Update: True

Delete: True

Display: False

Export: True (exportación a planilla Excel)


Para cada modo podrá especificarse una condición. Se proveen las siguientes propiedades para ese
propósito:

Insert Condition

Update Condition

Delete Condition

Display Condition

Si se define una condición asociada a un modo, la invocación para ese modo sólo se habilitará si la
evaluación de la condición es verdadera (Ejemplo: CountryId=10).

Attributes
Este nodo permite definir cuáles atributos se desean mostrar en el grid (y para cada atributo, se
pueden personalizar varias propiedades).

Orders
Permite ofrecer al usuario final varios órdenes posibles para ver el resultado de la consulta (es decir,
las líneas mostrando los datos en el grid). Utilizando el botón derecho del mouse se puede definir un
nuevo orden (su nombre y composición). Cada orden puede estar compuesto por varios atributos
(pudiendo indicar para cada uno de ellos si se desea orden ascendente o descendente). Se
presentará un combobox en el Web Panel Work With ofreciendo todos los órdenes posibles de
seleccionar, para que el usuario final elija uno y los datos se presenten en el grid ordenados por el
mismo.

Filters
Permiten definir condiciones de filtro, para que se muestren en el grid sólo los registros que
cumplan con las mismas.

Nodo View
El nodo “View” por su parte, ofrece las propiedades relacionadas al Web Panel View que se generará
para la instancia. El Web Panel View muestra toda la información de un registro, que fue
seleccionado en el grid del Web Panel Work With (la información del registro es mostrada en una
solapa de un tab control, y además hay una solapa con un grid por cada tabla directamente
subordinada, para mostrar la información relacionada).

Nodo Prompt
El nodo “Prompt” permite modificar las propiedades realcionadas a cada Prompt que es generado
por cada Transaccion de cada Work With. Este Prompt contiene toda la información necesaria para
permitir la ejecución del mismo desde la Transacción y mantiene el mismo estilo que los objetos
generados. Para invocar este objeto, se debe agregar la regla prompt(…) a la correspondiente
Transacción.

Archivos de Configuración

Al crear cada “Instance File” por defecto, podemos observar que las distintas propiedades del
“Instance File” se inicializan con valores por defecto. Dichos valores por defecto para las
propiedades, se especifican en un archivo denominado NombrePattern.config (en nuestro caso
WorkWith.config).

El archivo NombrePattern.config se encuentra donde está instalada la herramienta Patterns, bajo el


subdirectorio del pattern particular que se esté utilizando. Para el caso del pattern Work With estará
bajo: Patterns\WorkWith (recordar que bajo el directorio de la herramienta Patterns, existe un
subdirectorio por cada patrón predefinido (Work With, Bill of Materials, OAV) así como deberá
haber un subdirectorio por cada patrón definido por el usuario.

Si deseamos tener un archivo de configuración NombrePattern.config por cada base de


conocimiento, debemos copiar este archivo al directorio Templates que se crea bajo la base de
conocimiento al usar la herramienta Patterns; así la herramienta Patterns utilizará dicho archivo
ubicado en la base de conocimiento para inicializar las propiedades de los “Instance Files” que se
creen. Si la herramienta Patterns no encuentra el directorio Templates con este archivo bajo la base
de conocimiento, utilizará el archivo NombrePattern.Config (en nuestro ejemplo WorkWith.config)
ubicado en el directorio Patterns\WorkWith.

El archivo WorkWith.Config permite configurar algunos aspectos generales que aplicarán a todos los
objetos. Por ejemplo, las Master Pages a ser utilizadas por los objetos Web, los Web Components
utilizados como header y footer, etc..

Para editar este archivo de configuración, la herramienta Patterns ofrece el ítem: Tools/Change
Pattern Configuration, tal como se muestra a continuación:
En este archive se pueden configurar diversas propiedades tales como:

WW Configuration

THEMECLASSES
Esta opción indica las clases a ser utilizadas por el tema por defecto. Se puede utilizar cualquier otra
clase ya definida.

GRID
Page = Page.Rows – Indica cuantas filas se visualizarán en el grid.

SaveGridState – Indica si los Orders, Current Page y Filtros se guardarán para los Web Panels Work
With o no.

EnableDisablePaging – Indica si los botones de paginado serán deshabilitados o no, cuando la


correspondiente acción no está habilitada (por ejemplo, el botón “Next” cuando se está visualizando
la última página).

TAB
MaxTabs – Indica cuantos Tabs serán visualizados en un View. Si hay más Tabs que los indicados en
MaxTabs, se generará un Scroll para permitir navegar a través de los mismos.
StandardActions

DefaultMode – Indica cuando incluir la acción en un grid por defecto. Aplica a las acciones insert,
update, delete y display.

Context

Esta propiedad implementa el manejo del contexto. Por defecto, la implementación incluye una
variable llamada &Context basada en el SDT Context y un procedimiento llamado LoadContext, que
es invocado en el evento Stara e cada Web Panel. Esta característica puede ser usada, por ejemplo,
para mantener información sobre el usuario conectado a la aplicación (especialmente para la
autenticación/autorización), la empresa corriente para sistemas multi-empresa, etc.. Se puede
modificar la variable y el procedimiento invocado, modificando la sección Context en el archivo
WorkWith.Config. Por ejemplo, se puede usar la variable Context para definir un filtro: EmpCod =
&Context.CurrentEmpCod.

Security

Esta propiedad implementa la seguridad a nivel del objeto. Por defecto, la implementación incluye
un procedimiento llamado IsAuthorized, que es invocado en el evento Start de cada Web Panel, para
controlar la autorzación del acceso a dicho recurso. Si el procedimiento retorna false, significa que el
usuario no tiene autorización para ejecutar la aplicación, y por lo tanto el Web Panel de usuario no
autorizado (NotAutorized) es invocado. En a implementación de ejemplo, este procedure siempre
retorna True, se debería modificar según las necesidades del caso. Es posible modificar el objeto
invocado,modificando la sección Security en el archivo WorkWith.Config.

Demo: Patterns y Seguridad

Después de haber aplicado el pattern Work With seguiremos avanzando en cuanto a la seguidad de
la aplicación. Para lo cual, reutilizaremos el procedure IsAuthorized para mostrar como se
programaría el acceso a los distintos objetos:

Call(PLoadContext, &Context)

If (&GxObject = 'TUsers' and &Context.Profile <> 'ADMINISTRATOR' )

&Authorized = Boolean.False

Endif. Veamos entonces como quedaría dicho procedimiento:


Además de la siguiente regla:

parm(in:&GxObject, out:&Authorized);

Haga clic aqui para ver la demostración

INTRODUCCIÓN

Cada vez más, el uso masivo de Internet propicia el desarrollo de aplicaciones de mayor versatilidad
y complejidad para el ambiente Web. Es por esto que está surgiendo la necesidad de aplicar una
reingeniería a las aplicaciones existentes y también, en muchos casos, la necesidad de desarrollar
nuevas aplicaciones para Internet.

Existen varias diferencias entre los ambientes GUI (aplicaciones con Interfaz de Usuario Gráfica) y
Web, las que deberán evaluarse al momento de determinar la conveniencia del tipo de aplicación a
desarrollar. La migración no debería verse como una conversión objeto a objeto sino que
normalmente es una modernización de la aplicación usando otras herramientas tales como Patterns,
GXPortal, GXFlow, Reporting, etc..

En este capítulo veremos los principales aspectos a ser tenidos en cuenta por los usuarios GeneXus.

INTRODUCCIÓN

En el desarrollo de una aplicación Web, la calidad de la interfaz con la que interactúa el usuario
determina el éxito de la aplicación. La calidad de la misma está definida por una serie de pautas y
técnicas. A este conocimiento se le llama “Usabilidad”.

La interfaz de una aplicación Web está determinada a grandes rasgos por la estructura de la
aplicación, el diseño de la misma y de su contenido.
Con estructura de la aplicación nos referimos a la ubicación de los diferentes elementos para que
sean encontrados de forma intuitiva por el usuario y utilizados de forma correcta. Hay que tener
esta estructura bien definida antes de aplicar un diseño.

El diseño de la aplicación es la parte gráfica de la misma, el conjunto de imágenes, colores, formas


que va a tener la aplicación.

El diseño del contenido permite que el mismo sea cómodamente leído y correctamente
interpretado.

A lo largo de este capítulo desarrollaremos cada uno de estos puntos para lograr aplicaciones Web
exitosas y fáciles de usar.

 Estructura de la aplicación

 Diseño de la aplicación

 Diseño del contenido

Estructura de la Aplicación

Con estructura de la aplicación nos referimos a la ubicación de los diferentes elementos para que
sean encontrados de forma intuitiva por el usuario y utilizados de forma correcta. Hay que tener
esta estructura bien definida antes de aplicar un diseño.

Es importante que la estructura del sitio esté reflejada en todas las páginas en forma consistente.

A la hora de definir la estructura en sitios corporativos, en general es recomendable no reflejar el organigrama


de la empresa, sino reflejar una estructura de acciones a realizar o de información a encontrar. Siempre que
pueda aprenda de sitios exitosos de su misma área para realizar una estructura similar, que resulte intuitiva
para el mismo público objetivo.

Es recomendable:

 Mostrar las barras de navegación en todas las páginas.


 No cambiar la ubicación de las opciones de los menúes según cambien las páginas (mantener
consistencia).
 Aplicar los mismos conceptos para las mismas acciones (links, botones, bullets, etc.).
 No poner links a la misma página en la que me encuentro.
 Permitir que el usuario siempre controle la navegación: no deshabilitar botones estándares de los
navegadores ni botones del mouse.
 Si usa un mapa del sitio (Sitemap) brinde la información de donde está el usuario en cada momento.
Puede incluir una pequeña descripción de qué ofrece cada opción del menú.

Navegación

La navegación de una aplicación permite ir a las distintas partes, sectores, páginas de la aplicación
rápidamente y en forma intuitiva. La estructura del sitio se debe reflejar en la navegación permitiendo
contestar las siguientes interrogantes:

¿Dónde estoy?

Dentro del universo de sitios/ aplicaciones Web: Esto se logra mostrando el logo del sitio/ aplicación Web
en todas las páginas. La ubicación habitual del mismo, y por lo tanto el lugar donde el usuario lo irá a buscar,
es la esquina superior izquierda. Esta imagen debe tener siempre un enlace a la página de inicio de la
aplicación o la página principal del sitio.

Dentro de la estructura de la aplicación Web. Para ello se recomienda:


 Marcar la opción seleccionada en la barra de navegación.

 Usar títulos en cada una de las páginas, dentro del área de contenido de forma
que el usuario sepa dónde se encuentra.

 Nombrar las páginas en el cabezal de las mismas para que se identifiquen en el


grupo de páginas que tiene abiertas el usuario. En GeneXus esto se hace usando
la propiedad “Caption” del Form (Form.Caption). Para mostrar el nombre de la
aplicación y de la página se puede usar un formato como los siguientes:

 Sitio: página (Ej: GeneXus: Capacitación)

 Sitio – página

 Sitio > página

 Usar nombres cortos para las páginas igual que para los sitios de modo que se
puedan visualizar bien en el cabezal de la página.

¿Dónde estaba?

Para indicar las páginas que el usuario ya visitó, conviene dejar los colores de los enlaces con los colores por
defecto del navegador.

¿A dónde puedo ir?

Mostrar todas las opciones a donde puede ir el usuario desde la página actual, sin marearlo con demasiadas
opciones. Si las opciones son muchas, conviene agruparlas por áreas o sectores y dentro de los mismos
mostrar submenúes.

Herramientas de búsquedas (search)

Si usa una herramienta de búsqueda, ésta debe de estar en todas las páginas del sitio, en un lugar siempre
visible sin tener que usar las barras de desplazamiento. El lugar más intuitivo es el cabezal superior derecho, o
la columna del menú izquierdo.

Se recomienda hacer esta funcionalidad lo más simple posible de manera que sea fácil de usar. Lo más sencillo
es tener una caja de texto y un botón que diga buscar. El uso de iconos, etiquetas, etc. necesita que el usuario
las interprete y por lo tanto demore unos segundos en entender su uso.
El resultado de la búsqueda debe ser claro, debe mostrar la cantidad de instancias encontradas, el texto usado
para realizar la búsqueda, el título de cada página que contiene el texto buscado y un enlace en ese título a la
página correspondiente.

Menúes

MENÚ SUPERIOR
Tanto en sitios corporativos como en Intranets y Extranets se usa comúnmente un menú superior
que contiene por lo general las siguientes opciones:

1. Página de Inicio

Si bien hay un enlace en el logo de cada página, nunca está de más repetirlo ya que la página inicial es a
la que se retorna con más asiduidad.

2. Acerca de, Acerca de Nosotros, Acerca de La Empresa, La Empresa, Quiénes somos, etc.

Siempre es válido un enlace a información sobre la empresa que representa ese sitio, el producto que se
vende a través del sitio, etc. que respalde la seriedad y veracidad del contenido presentado en el
mismo.

3. Mapa del sitio, Mapa, etc.

En la zona superior derecha se ubican las herramientas para encontrar páginas y contenido
dentro del sitio, la ubicación de la herramienta de búsqueda y del mapa del sitio.

4. Contacto, Contáctenos, Contáctese, etc.

Este enlace debe conducir a una página que contenga información para contactar a la empresa a
través de teléfonos, emails y direcciones físicas. Esta opción del menú no debe ser un enlace a
un correo electrónico, ya que incomoda al usuario porque ejecuta su aplicación de manejo de
emails.

En aplicaciones Web, este menú generalmente contiene:

 Enlace a la página de inicio de la aplicación.


 Enlaces a información importante, no relativa a la aplicación en particular o a la parte de la aplicación
desplegada en la página, pero que sirva para la aplicación entera, que sirva de respaldo, etc..
Ejemplo: información de registro del usuario (a la izquierda), idiomas de la aplicación, área de ayuda,
contacto con soporte, página de la información de la empresa, etc..

MENÚ DE ÁREAS
Muchas veces se usa el área de cabezal para ubicar un menú de áreas o categorías dentro de la aplicación o
del sitio. Generalmente se utiliza cuando hay demasiadas opciones para ubicar en el menú izquierdo (más de
10). Categorizar los enlaces y agruparlos en áreas simplifica la navegación haciéndola más intuitiva.

MENÚ IZQUIERDO
Este menú contiene las opciones de navegación del sitio, todos los lugares del sitio a donde se puede acceder.
En muchos sitios el menú izquierdo cambia según el área en la que el usuario se encuentre.
Se debe mantener el mismo diseño del menú, independientemente de las opciones, para que al usuario sepa
cómo usarlo ya que aprendió su uso en otras áreas del sitio.

Links

Hay tres tipos de links:

 Links estructurales (de navegación)


 Links asociativos. Los clásicos links que se asocian a una palabra para ver más información
relacionada a la misma.
 Links de información relacionada (Related links)

Algunas recomendaciones para la definición de links:

 Cuando se definen links subrayar las palabras importantes y brindar información suficiente
para que el usuario se sienta atraído a seguir el link.
 Relacionar la información con links del tipo "más sobre tal tema", o sobre el autor, etc..
 Usar “link title” siempre que no sea obvio a donde va el link, para que aparezcan los tooltips:

o Si el link es externo, el nombre del sitio


o Si es interno, el nombre del subsitio
o Información adicional que se aplique
o El tooltip debe tener menos de 60 caracteres
 Mantener siempre el color predeterminado para los diferentes links.
 Siempre usar los mismos nombres para acceder al mismo contenido.

Diseño de las páginas de la aplicación

El diseño de la aplicación es la parte gráfica de la misma, el conjunto de imágenes, colores, formas


que va a tener la aplicación.

Se debe diseñar pensando en:

 Velocidad de carga

 Público objetivo

 Uso de la aplicación

 Máximo aprovechamiento de los temas


Velocidad de carga

El tiempo que demora en cargarse la totalidad de una página determina la percepción que va a tener
el usuario de ese sitio o aplicación. Si la aplicación demora en cargarse, el usuario pensará que no es
buena, que no le solucionará sus problemas de forma correcta. Si la demora es excesiva, el usuario
puede llegar a pensar que la empresa no es fiable.

Para mejorar los tiempos de carga se recomienda:

 Usar texto en vez de imágenes siempre que se pueda (Ej.: para los menúes)
 El formato de las imágenes siempre debe de ser .gif o .jpg, nunca .bmp, ya que este formato pesa
mucho más que los anteriores.
 Usar herramientas para disminuir el peso de las imágenes. Ej:
http://www.netmechanic.com/GIFBot/optimize-graphic.htm
 No usar imágenes animadas.
 No usar flash, ya que no sólo demora más la carga de la página, sino que muchas veces requiere que
el usuario instale la tecnología.
 No hacer páginas que requieran el uso excesivo de las barras de desplazamiento horizontal. Esto no
sólo ahuyenta al usuario por el tiempo que le consume, sino también por la cantidad de contenido que
se le presenta. Es mejor hacer páginas más cortas, con la información suficiente, o armar más
páginas a partir de una.

Público objetivo

Debe tener en cuenta quién será el público objetivo –a quién se dirige, quiénes serán los usuarios- a
la hora de diseñar y elegir los colores, los tamaños de las letras y tamaños de las pantallas.

Por ejemplo, si el público objetivo está integrado por desarrolladores, se puede hacer un sitio o una
aplicación con letras de tamaño 8 puntos, pero no se recomienda usar este tamaño para un público
masivo.

Uso de la aplicación

Cuando está diseñando también debe considerar cuál es la finalidad de la aplicación para no
entorpecer el uso del servicio que se desea brindar.

Si se trata de un sitio Web donde se ofrece bastante texto para leer no es recomendable que las
páginas tengan sectores que llamen más la atención que el contenido principal de la página. Por
ejemplo, las imágenes animadas son centros de atención. Es realmente molesto tener imágenes
moviéndose en distintas partes de la página cuando se tiene que leer. Se pueden usar imágenes
animadas si su movimiento se detiene una vez presentada la animación. De esta forma, se logra
captar la atención del usuario que ingresa a la página para transmitir el mensaje que se desea con
esas imágenes, y luego, se facilita al usuario la concentración para la lectura del texto principal.
Si el sitio Web es un portal, donde se espera encontrar muchos focos de atención (textos cortos,
muchos links) es más adecuado usar imágenes animadas.
Máximo aprovechamiento de los temas (Themes)

Maximizar el uso de los temas permite ajustar el diseño en tiempo de ejecución. Es recomendable
que cada ítem que se use esté definido en el tema, de forma por ejemplo, que todos los títulos
tengan la misma apariencia y si más tarde se quiere agregar espacio entre el título y el contenido se
pueda modificar automáticamente en todos los títulos de la aplicación. Esto es válido para cada
tabla usada en la aplicación, desde la que contiene las opciones del menú hasta la que contiene el
contenido, los grids, las etiquetas de los formularios, etc..

Diseño del contenido

La forma de escribir en Internet difiere a la usada en publicaciones físicas, principalmente porque es


más difícil leer en la pantalla y el público es más exigente con el tiempo que le consume obtener una
información. Debido a esto hay que escribir para Internet teniendo en cuenta las siguientes pautas:

 Escribir lo más corto y conciso posible. Se dice que en Internet hay que escribir entre un
50% y un 25% menos de lo que se escribiría en papel.
 Poner las conclusiones al principio y una opción para ver el detalle de esa conclusión.

Tipo de letras

Se deben tener las siguientes consideraciones a la hora de elegir el tipo de letra a utilizar en una
aplicación Web:

 El tipo de fuente debe estar instalada en las máquinas destino

 El tamaño debe ser adecuado para el público objetivo y para la resolución más usada

 Elegir un estilo de letra (Serif o Sans Serif) y no mezclar estilos

Los tipos de fuentes que en general se encuentran instaladas en todas las máquinas son Arial, Verdana y Times New Roman.

Legibilidad

Definición de Legibilidad: f. Capacidad o posibilidad de ser leído, por su claridad.

La buena tipografía depende -entre muchas otras variables- del contraste visual entre una fuente y
otra, y entre los bloques de texto, los títulos, y el espacio en blanco alrededor. Lo que más atrae al
ojo es el contraste fuerte con patrones distintivos.
Seguir patrones que conserven la forma de organizar el texto y las imágenes en las distintas páginas
de un sitio o una aplicación permite entender la organización de la información, intuir la ubicación
de más información y se aumenta la legibilidad de la misma.

La lectura va a ser más cómoda cuanto mayor sea el contraste de los colores. El mayor contraste se
logra con fondo blanco y letras negras. Se pueden establecer las combinaciones de colores en el
editor de temas, en la clase "Form" y jugar con las mismas sin tener que cambiar ni una línea de
código.

Márgenes

Los márgenes definen el área de lectura de una página, separando el texto principal de lo que lo
rodea.

Los márgenes y el espacio en blanco se usan para delinear el texto principal de otros elementos de
una página, y usados de igual manera en todas las páginas proveen uniformidad a través del sitio
creando una estructura consistente y una identidad visual.

Es recomendable que los textos principales tengan un margen de 5 a 10 píxeles. Esto se logra en
GeneXus poniendo el texto dentro de una tabla con “BorderWidht” en “0” y “Cellpadding” en “10”.

La propiedad “Cellpadding”: especifica la distancia en píxeles entre el contenido y los bordes de la


celda.

La propiedad “Cellspacing”: especifica el ancho en píxeles de los bordes de la celda.

Alineación de los textos

La alineación izquierda de títulos y contenidos es la más recomendable para el público occidental.

Los usuarios en Internet en general no leen los textos palabra a palabra, sino que escanean las
páginas tomando algunas palabras de cada párrafo para entender la idea general de la página. La
alineación izquierda facilita este tipo de lectura.
Links de interés

Usabilidad

Sitios con artículos sobre usabilidad y temas relacionados con mejora en los sitios Web:

EN ESPAÑOL
http://usalo.es/

http://www.ciw.cl/

http://www.masterdisseny.com/

http://www.alzado.org/

http://www.cadius.org/

http://accesibilidadweb.blogspot.com/

http://www.proyectoweb.org/

http://www.microsoft.com/spain/empresas/guias/usabilidad/experiencia_usuario.mspx

http://www.pdaexpertos.com/tutoriales/internet_movil/10_puntos_de_usabilidad_y_diseno_web_
para_pdas.shtml

EN INGLÉS
http://www.useit.com/

http://www.usabilitynet.org/

http://usableweb.com

http://www.w3.org/TR/WCAG20/

http://www.handheldusability.info/

http://www.usability.gov/guidelines/

http://www.webusability.com/

http://www.userfocus.co.uk/resources/index.html

http://www.humanfactors.com/downloads/10tips.asp

http://www.htmlcenter.com/
Herramientas

HERRAMIENTAS PARA REDUCIR EL PESO DE LAS IMÁGENES


http://www.netmechanic.com/GIFBot/optimize-graphic.htm

http://www.creatingonline.com/

http://www.gifworks.com/

TOOLBAR DE USABILIDAD
http://www.southbourne.com/accessibility-toolbar.htm

http://www.microsoft.com/downloads/details.aspx?FamilyID=e59c3964-672d-4511-bb3e-
2d5e1db91038&DisplayLang=en

HERRAMIENTAS DE CHEQUEO DE LINKS ACTIVOS


http://validator.w3.org/checklink

http://www.anybrowser.com/linkchecker.html

HERRAMIENTAS QUE MUESTRAN EL SITIO EN DISTINTOS


NAVEGADORES
http://www.anybrowser.com/siteviewer.html

HERRAMIENTA PARA MEDIR LA VELOCIDAD DE CARGA DEL SITIO


http://www.webperf.org/breakdown.html http://zing.ncsl.nist.gov/WebTools/

HERRAMIENTAS PARA TESTEAR LA USABILIDAD


http://zing.ncsl.nist.gov/WebTools/

HERRAMIENTAS PARA CHEQUEAR EL CÓDIGO HTML Y MÁS


http://zing.ncsl.nist.gov/WebTools/tech.html
INTRODUCCIÓN

Muchos años atrás visualizamos que las soluciones Web serían la respuesta a muchos problemas
(distribución, disponibilidad, accesibilidad, escalabilidad, etc). Por eso a partir de la versión 6.1 de
GeneXus incluimos generadores para esta plataforma.

La evolución de la plataforma y el acompañamiento que GeneXus hizo de la misma, permitió que


dejara de ser una plataforma para "páginas estáticas" y se convirtiera en una plataforma para
soluciones de negocio reales tanto Internet como intranets.

En la versión 9.0, además de los generadores para esta plataforma con los cuales se cuenta desde
hace años, se incluyen tecnologías de punta (como Ajax) viabilizando funcionalidades nuevas para el
ambiente Web, muchas de ellas "implícitas" en la versión (sin costo de desarrollo) y
extremadamente complejas de desarrollar "a mano".

El proceso de conversión de una aplicación GUI (Interfaz de Usuario Gráfica) a Web implica conocer
algunas características de esta última plataforma y su relación con las funcionalidades y
características de las soluciones GUI.

Muchas veces no se trata de "convertir" la aplicación o parte de la misma, sino del desarrollo de un
nuevo módulo en esa plataforma. En cualquier caso existe un "paralelismo" entre lo conocido por el
desarrollador (ambiente GUI) y la plataforma nueva a la cual se está enfrentando (Web), lo cual
requiere considerar las diferencias.

En este capítulo profundizaremos tanto en las diferencias como en la conversión de GUI a Web.

Comparación GUI – Web

Objetivo

El objetivo de este documento es brindar una herramienta de referencia, para asistir en la decisión
de migrar o desarrollar una aplicación GUI, o una aplicación Web. Para analizar las diferencias entre
los dos tipos de aplicaciones se compararán las ventajas y desventajas de las aplicaciones Web
frente a las aplicaciones GUI.
Existe otro artículo (Conversión de Aplicaciones GUI a Web) sobre esta misma temática en donde se
dan los detalles técnicos de cómo realizar esta tarea, por lo que aquí no se mencionarán esos
detalles.

Introducción

APLICACIONES CON INTERFAZ DE USUARIO GRÁFICA


Las aplicaciones con Interfaz de Usuario Grafica (GUI) están compuestas por uno o varios programas
GeneXus que utilizan objetos de tipo: Transacción, Work Panel, Procedimientos y Reportes.

APLICACIONES WEB
Se entenderá por aplicaciones Full Web a aquellas aplicaciones en las que la interfaz del usuario es
únicamente realizada utilizando el lenguaje HTML y son accedidas desde un browser. En GeneXus
estas aplicaciones se implementan con objetos Web como ser: Web Panels o Transacciones Web.

El lenguaje HTML es un lenguaje de marcas (tags) para la estructuración de un documento. Si bien el


lenguaje es estándar, en la práctica, cada browser toma algunas partes de la especificación, agrega e
ignora otras. Como consecuencia de esto una aplicación Web puede quedar levemente distinta
según el browser que se utilice.

Características de las aplicaciones Web

VENTAJAS DE LAS APLICACIONES WEB


Una aplicación Web tiene diversas ventajas frente a las aplicaciones GUI.

Instalación
Las aplicaciones Web presentan varias ventajas tanto en la instalación y actualización como en los
requerimientos necesarios para utilizarlas.

Cliente ‘fino’. Para utilizar la aplicación Web solo se necesita un browser. Los browsers son
distribuidos por Internet y no tienen costo. Generalmente vienen incluidos al instalar el sistema
operativo. Adicionalmente se pueden instalar plugs-in, que son programas que agregan
funcionalidades adicionales al browser. Un ejemplo muy común es el plug-in de Acrobat, utilizado
para visualizar archivos en formato PDF o plugs-in para video o sonido.

Flexibilidad en software y hardware en el cliente. En las aplicaciones Web, el cliente puede tener
instalado cualquier sistema operativo en cualquier versión. Las aplicaciones Web no utilizan tantos
recursos de hardware por lo que el costo de las computadoras clientes es menor y no necesita
actualizaciones frecuentes.
La aplicación solo se instala en el servidor. Generalmente la instalación y actualización de
aplicaciones GUI en arquitecturas cliente / servidor implica, alguna instalación en las computadoras
cliente. En el caso de aplicaciones Java GUI, esta instalación es automática, pero también existe ya
que es necesario bajar la aplicación.

En el caso de una aplicación Web no se requiere ninguna instalación adicional a la del browser, para
poder accederla o acceder a otras aplicaciones Web.

Escalabilidad
Las aplicaciones Web utilizan una arquitectura de tres capas compuesta por la capa cliente, donde
está únicamente el browser, la capa del Servidor Web donde está la aplicación y la capa de datos
donde se encuentra la base de datos.

BD

Arquitectura en tres capas.

Esta arquitectura presenta varias ventajas en cuanto a la escalabilidad.

Escalabilidad de usuarios. En la concepción de la aplicación, no se tiene en cuenta la cantidad de


usuarios que van a utilizarla. Es decir que la misma aplicación puede ser utilizada por algunos pocos
usuarios o varios cientos. El límite estará determinado por el desempeño de la aplicación, que
depende principalmente de la potencia de los servidores y de las características de la red.
Una ventaja de la arquitectura en tres capas es que no es necesario pagar nuevas licencias por cada
nuevo usuario que accede a la aplicación (por ejemplo los drivers de acceso a la base de datos se
pagan por cantidad de usuarios concurrentes).

Escalabilidad de servidores. El desempeño de la aplicación depende directamente de la potencia de


los servidores en la que este instalada. Se puede migrar la aplicación a servidores más potentes, sin
necesidad de que los usuarios cambien el modo en que acceden a la aplicación.

Independencia
Acceso. La aplicación puede ser accedida desde cualquier lugar que cuente con acceso a Internet.
Esto puede tener un fuerte impacto en el modo de trabajo ya que se pueden acceder a las
aplicaciones desde la oficina, el hogar o incluso desde otros países.

Hosting Services Provider (HSP). La aplicación puede ser instalada en un centro de cómputos propio
o puede contratarse un Hosting Service Provider (son empresas que proveen un centro de cómputos
para aplicaciones Web) e instalarla en los servidores del HSP. Para los usuarios, el acceso a la
aplicación es independiente de donde esté instalada.

Interfaz gráfica
Uniformidad. La forma de navegar por la aplicación Web será siguiendo links o presionando botones
y si bien hay más opciones, estas son las más comunes y se mantendrán por toda la aplicación. Si
bien este modo de interacción es limitado con respecto a las aplicaciones GUI, al ser tan simple y
uniforme en toda la aplicación, al usuario final le resultará sencillo e intuitivo aprender a utilizar
nuevas funcionalidades.

El diseño gráfico es realizado por expertos. Un aspecto sumamente importante en la interfaz grafica
de una aplicación Web es el diseño grafico. Este aspecto sumamente delicado se deja a cargo de
diseñadores gráficos especializados, que hacen que las aplicaciones tengan aspectos atractivos y
funcionales.

El trabajo con los diseñadores gráficos sigue pautas similares a la metodología de prototipación
utilizada en el desarrollo de aplicaciones GeneXus. Cuando los diseñadores tienen listo un prototipo,
es conveniente que los desarrolladores lo evalúen para validarlo desde el punto de vista del
desarrollo.

Para esto se cuenta a partir de la versión 8.0 de GeneXus, con el Editor de Temas, herramienta que
puede ser usada tanto desde GeneXus como en forma independiente, por lo cual flexibiliza
notablemente la interacción con el diseñador gráfico, además de todas las ventajas adicionales que
trae el uso de Temas en el diseño de la aplicación Web. Por detalles sobre Temas ver el documento
Themes.

Al evaluar un diseño hay que tener en cuenta ciertos aspectos:

 Impacto del diseño de las páginas Web finales. Si se utilizan demasiadas imágenes, con
muchos botones, el tamaño final de la página, puede ser excesivamente grande, por lo que
se demorará mucho el acceso. La recomendación es cuidar de que las imágenes sean de
pocos Kbytes. Los links de texto son muy livianos, en el caso de una aplicación muy accedida,
puede ser conveniente utilizarlos. Los sitios Web de Amazon y Yahoo, son buenos ejemplos
de interfaces livianas, con pocas imágenes y muchos links de texto.

 El diseño debe ser consistente. Por ejemplo la tipografía, los colores, la ubicación de
botones, etc. debe seguir una pauta bien definida, que los desarrolladores deben respetar al
máximo.

 El diseño debe ser simple y sencillo. El exceso de detalles gráficos, puede complicar el
desarrollo y evolución del sitio.

 El diseño debe ser robusto de modo de poder soportar evoluciones, y nuevos


requerimientos.

 Componentización. Es muy importante que la estructura de las páginas pueda ser separado
en componentes, de modo de poder reutilizar los mismos objetos para simplificarle al
usuario el conocimiento del sitio. En GeneXus esto, se implementa utilizando Web
Components.

Mantenimiento. La posibilidad de desarrollar una página dividida en Web Components, permite


tratar cada componente en forma independiente. Esto no solo hace las interfaces más robustas
frente a cambios y extensiones, sino que además al cambiar un componente, se reflejan los cambios
en todas las páginas que lo incluyen. O sea que no es necesario reprogramar todas las páginas, solo
el componente adecuado, haciendo del mantenimiento de la aplicación sencillo.

Integración de nuevas aplicaciones. La interfaz con el usuario se puede personalizar dinámicamente,


de acuerdo a las características del usuario. Por ejemplo con menúes donde las opciones se cargan
dinámicamente, según las aplicaciones a las que puede acceder el usuario. De este modo se logran
aplicaciones más integradas y donde es más sencillo incorporar nuevas aplicaciones.

Interfaz multimedia. Es muy sencillo incluir en las aplicaciones Web características multimedia como
audio, video, imágenes, etc.
Application Service Providers y servicios Web
Los Application Service Providers (ASP), son empresas que brindan servicios y soluciones, basadas en
software, a través de Internet. Ejemplos muy comunes de ASP en portales de Internet son los
proveedores de noticias, banners, clima, etc.. Tener aplicaciones Web habilita a la empresa a
funcionar como ASP, brindando como servicio el uso de las aplicaciones Web desarrolladas.

También habilita a contratar a otros ASP para potenciar las aplicaciones propias.

Integración de aplicaciones Internet e Intranet


Las aplicaciones Web desarrolladas pueden ser utilizadas en Internet o en una Intranet, para uso
interno. Además las aplicaciones Web ya existentes, utilizadas en la Intranet pueden ser integradas a
las nuevas aplicaciones Web desarrolladas.

Extensiones con Java y JavaScript


En las aplicaciones Web se pueden incorporar extensiones en lenguajes como Java y JavaScript. Para
controlar distintos aspectos de la interacción con páginas Web se utiliza el lenguaje JavaScript. El
código escrito en este lenguaje es incorporado en el HTML e interpretado por el browser. Java es un
lenguaje de programación muy potente, entre sus propiedades, se destaca la de ser
multiplataforma. Esto quiere decir que las aplicaciones desarrolladas en Java pueden ejecutarse en
cualquier sistema operativo y cualquier plataforma de hardware. Esta propiedad lo hace
especialmente atractivo para aplicaciones que ejecutan a través de Internet. Por lo tanto se pueden
incorporar aplicaciones GUI desarrolladas en Java, para potenciar la aplicación Web.

Múltiples formas de acceso


Múltiples tecnologías como computadores de bolsillo y teléfonos celulares están teniendo un fuerte
desarrollo, principalmente como formas alternativas de acceso a Internet. Las características de
hardware de estos dispositivos hacen que las aplicaciones Web sean las más adecuadas. La principal
diferencia con las aplicaciones Web para estos dispositivos es el tamaño reducido de la pantalla. Si
bien es necesario crear una versión particular para el dispositivo, se puede reutilizar mucho
conocimiento de una aplicación Web ya desarrollada.

INCONVENIENTES DE LAS APLICACIONES WEB


En la siguiente sección se discuten las desventajas que presentan las aplicaciones Web frente a las
aplicaciones GUI.
Es necesaria una reingeniería de la aplicación. El lenguaje HTML presenta ciertas limitaciones que
implica que migrar aplicaciones GUI a aplicaciones Web no sea una tarea automática. Entre los
puntos que deben tenerse en cuenta al realizar la reingeniería de la aplicación se destacan los
siguientes:

Seguridad. Es imprescindible tener un esquema de seguridad en la aplicación, de modo de restringir


el acceso a determinadas aplicaciones. Este puede basarse en definir roles con determinados
accesos o un esquema en el cual a cada usuario se le asignan permisos particulares. Por otro lado la
aplicación puede requerir que algunas aplicaciones particulares necesiten un esquema más fuerte de
seguridad y requieran páginas Web seguras y servidores seguros.

Transacciones e Integridad transaccional. Las Transacciones Web utilizan la misma arquitectura que
los Web Panels. En la figura se ve la secuencia de acciones que ocurren al someter las Transacciones
Web al servidor.

Funcionamiento de las Transacciones Web y Web Panels.

El tiempo de vida de las UTLs (Unidades de Trabajo Lógicas) en los objetos Web, se mantiene
únicamente durante la ejecución del objeto. Cuando la ejecución termina se deben hacer commit o
roll back. Por lo tanto no es posible definir una UTL a través de varias Transacciones Web. Sin
embargo, es posible mantener la UTL a través de varios procedimientos que se invoquen unos a
otros, siempre que se mantengan dentro de la misma ejecución. En las aplicaciones GUI es común
encontrar que durante varias transacciones se van ingresando datos y luego en la última transacción
se hace el commit de todos los datos ingresados, por lo que se deben contemplar estos casos en la
reingeniería de la aplicación. Las alternativas posibles a esta situación son:
 Unificar todas las Transacciones GUI en una sola Transacción Web.

 Dividir el proceso de ingreso en varias etapas y utilizar múltiples Transacciones Web. Al


finalizar el ingreso podría tenerse un procedimiento que valide que el ingreso en varias
etapas es consistente.

 Ingresar toda la información en tablas temporales y luego ingresar la información a la base


de datos mediante procedimientos.
Limitación entre la interacción de objetos GeneXus. La interacción entre objetos GeneXus, en
aplicaciones Web es más limitada que la interacción en aplicaciones GUI. Las Transacciones Web y
los Web Panels pueden ser invocados entre sí, y ambos pueden invocar a procedimientos. Desde
objetos Web no es posible invocar objetos no Web como Transacciones, Work Panels y Reportes,
aunque para los reportes existe la posibilidad de generarlos en formato PDF. Este tipo de
comportamiento que puede encontrarse en una aplicación GUI, debe ser tratado en la reingeniería
de la aplicación.

Diferencias en los Web Panels “Trabajar con”. En las aplicaciones Web, los Web Panels de tipo
“Trabajar con” presentan algunas diferencias que en las aplicaciones GUI.

El alto de la pantalla cambia, dependiendo de la cantidad de líneas del grid. En las aplicaciones GUI,
el tamaño de los formularios se determina en el diseño de este y queda fijo en el momento de
ejecución. En las aplicaciones Web, el tamaño de la página Web se puede extender (horizontal o
verticalmente) si se presentan muchas líneas en los grids.

La selección de líneas es diferente. En las aplicaciones GUI, las líneas se seleccionan al hacer clic en
ellas, además se puede seleccionar un rango de líneas, continuo o con líneas salteadas, todo esto sin
necesidad de programación extra. En las aplicaciones Web, la selección múltiple de líneas debe
programarse mediante campos de chequeo.

Una posibilidad es permitir la selección de múltiples líneas y utilizar el carrito de compras (se
describe más adelante).

Se puede usar la propiedad “AllowSelection” de los grids para que sea posible seleccionar de a una
línea.

El modelo del carrito de compras. El carrito de compras, es muy utilizado en los sitios Web con e-
commerce y permite “recordar” los objetos que compran los usuarios. En el carrito de compras se
van seleccionando distintos ítems que se desean comprar. El carrito mantiene almacenado el
contenido hasta que el dueño decide comprar alguno o todos los ítems. Esta idea resulta práctica en
casos como este: Factura de compras. La factura se va armando seleccionando los elementos que la
componen: lista de productos disponibles, lista de clientes, formas de pago, monedas, etc. Cuando
se termino de armar, se construye la factura con toda la información del carrito.

Si se quiere realizar alguna acción a una serie de líneas en un “Trabajar con”, se pueden ingresar en
el carrito y luego automáticamente se van presentando una a una las páginas adecuadas para la
acción determinada, hasta vaciar el carrito.
Ejecución en el servidor. En Web con el uso de la tecnología Ajax las aplicaciones cada vez se
asemejan más a Win, ya que se ejecutan acciones tanto en el cliente como en el servidor. Por más
detalles ver Tipos de diálogo.

Infraestructura de hardware. La performance de una aplicación Web depende en gran medida de la


cantidad de usuarios concurrentes accediendo a la aplicación, el ancho de banda de la conexión y la
potencia de los servidores. Por lo tanto los servidores (Web y de base de datos) y el ancho de banda
de “salida” debe ser adecuado a la cantidad de usuarios esperada. También es imprescindible un
esquema fuerte de seguridad principalmente de la base de datos.

Una aplicación Web debe estar disponible los 7 días de la semana, durante las 24 horas del día. Esto
implica un servicio de alta disponibilidad en el cual posiblemente se maneje redundancia de
servidores y de información.
Conclusiones

Las aplicaciones Web son una nueva alternativa a las aplicaciones de interfaz gráfica. Ambos tipos de
aplicación tienen sus características propias por lo que en cada aplicación se debe evaluar si
conviene realizarla como Web o GUI. Los puntos discutidos en este artículo pueden ser considerados
como una guía para tomar esta decisión. Como requisito para tomar una decisión correcta se debe
comprender:

 El funcionamiento de la interfaz Web y las limitaciones que ello trae como consecuencia.

 Las limitaciones en la integridad transaccional.

Algunos puntos a tener en cuenta para evaluar la creación o migración a aplicaciones Web son:

 Requerimientos y proceso de instalación de la aplicación final.

 Ambiente en donde se ejecute la aplicación.

 Requerimientos en el acceso.

 Interfaz gráfica en cuanto a facilidad de uso, diseño gráfico atractivo y capacidades


multimedia.

 Acceso desde múltiples plataformas como computadoras de bolsillo, etc..

 Requerimientos de seguridad en la aplicación.

 Tipo de diálogo en las Transacciones GeneXus, especialmente en la validación de datos y


disparo de reglas, considerar las acciones que se dispararán en el cliente y cuales en el
servidor.

 Restricciones en la interacción de objetos GeneXus. Debe ser evaluado cuidadosamente en


el caso de migrar una aplicación GUI a Web.

Como punto final hay que tener en cuenta la evolución de la aplicación en cuanto a la creación de
nuevos módulos, cantidad de usuarios y mantenimiento.

Conversión de aplicaciones GUI a Web

Objetivo

El objetivo de este documento es describir los principales aspectos técnicos a tener en cuenta al
momento de convertir una aplicación GeneXus de tipo GUI-Windows a una aplicación Web.
Introducción

APLICACIÓN GUI
Entendemos como aplicación GUI (Graphic User Interface) a toda aquella que tiene interfaz gráfica
Windows, compuesta básicamente por los objetos Transacciones, Work Panels, Procedimientos y
Reportes, generadas con los generadores GeneXus Visual Basic, Visual Fox, Java y .Net.

APLICACIÓN WEB
Una aplicación Full Web tiene una interfaz HTML (HyperText Markup Language) y se ejecuta dentro
de un browser. Este tipo de aplicaciones se desarrolla básicamente con los objetos Web de GeneXus:
Web Panels y Web Transactions. Se generan con cualquiera de los generadores Web: Java, .Net.

Reingeniería de la aplicación

La premisa fundamental para convertir una aplicación Win a Web es que los ambientes implicados
(gráfico, html) son diferentes y por lo tanto la conversión implicará algo más que la mera conversión
de los objetos. Deberá programarse con “estilo Web”.

En este documento centralizamos consideraciones a tener en cuenta para los diferentes objetos y
modalidades de programación.

La conversión de los objetos implica:

1. Conversión de Work Panels

2. Conversión de Transacciones

3. Conversión de Reportes

1. CONVERSIÓN DE WORK PANELS A WEB PANELS


Una posibilidad para realizar la conversión de los Work Panels a Web Panels es utilizar la facilidad de
SAVE AS que brinda GeneXus. De esta forma, se convierte en forma automática el form gráfico al
form HTML y se mantiene toda la lógica del objeto. Algunos controles Win no son soportados en
Web (por ejemplo el tab control), con lo cual no siempre es automática la conversión de un form a
otro.
Otra posibilidad es crear un nuevo objeto (Web Panel) y copiar la lógica del Work Panel hacia el Web
Panel. Observe que se debe revisar la lógica ya que existen ciertas diferencias en la interfaz que
obligan a cambios en la programación.

Se recomienda leer el documento Comparación entre Web Panels y Work Panels donde se comparan
generalidades de ambos tipos de objetos.

Luego de convertir el objeto, se debe editar el código HTML del mismo y quitar los tags <pre> y
</pre> que quedan al principio y al final respectivamente del mismo. Hay que tener en cuenta que la
conversión no crea una tabla con los controles dentro, por lo tanto al quitar los tags mencionados
anteriormente la pantalla se “desarma” y quedan todos los controles juntos. Se aconseja por lo
tanto, crear primero una tabla donde se pueda “arrastrar” los controles y finalmente quitar los tags
<pre> y </pre>.
2. CONVERSIÓN DE TRANSACCIONES A TRANSACCIONES WEB
Se cuenta con un form HTML default por cada Transacción Web (con los atributos de la Transacción,
así como los controles propios de Transacciones Web, como ser el Error Viewer). Luego ese form se
puede modificar a gusto del programador. En algunos aspectos, el comportamiento de las
Transacciones Web es diferente al de las Transacciones con interfaz gráfica por lo tanto se
recomienda la lectura del documento Transacciones Web.

3. CONVERSIÓN DE REPORTES
Una posibilidad para manejar reportes es programar un Web Panel, de forma que el usuario final
pueda imprimirlo con las opciones de impresión del browser.

Otra posibilidad como solución a la necesidad de implementar un reporte en ambiente Web es


generar un reporte con salida PDF.

Diferencias entre los ambientes y como manejarlas

WORK PANEL “TRABAJAR CON”


Es muy común el uso de Web Panels del estilo “Trabajar con” donde se despliega un grid con
registros y una cantidad de opciones aplicables a cada una de las líneas del mismo. Por ejemplo: 2 –
Modificar, 3 – Visualizar, etc..

Manejo de opciones
En el objeto Web Panel, existen algunas alternativas para implementarlo:

1. Agregar en el grid una variable de tipo Combobox y programar las diferentes acciones en el
evento Clic de la misma.

2. Definir una imagen o un text block en el grid por cada una de las opciones y programar la
acción en el evento clic.

3. Si se utiliza un grid Free Style, puede utilizarse en lugar de una imagen con el evento clic, un
botón para cada una de las opciones.

4. Configurar la propiedad AllowSelection del grid.

Filtros
Si un Web Panel “Trabajar con” tiene variables que se aplican como filtro a los registros desplegados
en el grid, al seleccionar un registro y llamar a otro objeto (por ej. Transacción Web) que tiene un
Return, se vuelve al Web Panel “Trabajar con” pero se pierden los valores ingresados en los filtros.
Para poder mantener el comportamiento de los Work Panels “Trabajar con” se deberían utilizar
cookies que almacenen los filtros ingresados.

Refresh
En Work Panels “Trabajar con”, es común tener un comando Refresh o Refresh keep dentro de un
evento, luego de llamar a una Transacción. Cuando estos se convierten a Web Panels “Trabajar con”
el Refresh no es necesario, ya que al ejecutar el comando Return hay un Refresh implícito del Web
Panel. Por lo tanto, los comandos Refresh y Refresh keep deben ser eliminados de los eventos
mencionados anteriormente.

PROCESAMIENTO DE VARIAS FILAS EN GRID - FOR EACH LINE


SELECTED
En Web Panels, no existe la forma de seleccionar con el mouse varias líneas del grid ya que no existe
posicionamiento en ninguna parte del form. Para implementar la selección múltiple, se debe definir
una variable en el grid y asignarle un valor a cada una de las líneas que se quieren procesar. Luego,
se debe usar el comando For each line para procesar cada una de las líneas y filtrar por las que estén
seleccionadas (&valor = X).

Debe considerarse que se puede utilizar únicamente para invocar a objetos sin interfaz. Si se invoca
a otro Web Panel, solamente se ejecuta para el último registro del grid.

Para la selección de una línea se cuenta con la propiedad “AllowSelection”.

CALL DE UN OBJETO SIN INTERFAZ A OTRO CON INTERFAZ


En las aplicaciones GUI puede definirse una cadena de llamadas entre objetos del estilo: Work Panel
-> call Procedure -> call Work Panel.

En las aplicaciones HTML esto no puede usarse. Las llamadas a un Web Panel solamente pueden
realizarse desde otro Web Panel (mediante el call o el link).

Por lo tanto, deberá modificarse la programación a algo del estilo:

Web panel -> call Procedure

-> Call Web Panel


INTEGRIDAD TRANSACCIONAL: MANEJO DE UTLS
Las Transacciones Web siempre hacen commit, por lo que el manejo de Transacciones anidadas, con
la propiedad “Commit on exit” en “No” no se puede lograr. En muchos casos la alternativa es utilizar
la lógica del modelo del “Carrito de Compras”

USO DE TAB DIALOGS


En las aplicaciones GUI, se pueden definir tab dialogs para organizar los datos del form en varias
secciones. En las aplicaciones HTML no se tiene este control por lo que será necesario rediseñar el
form.

Una alternativa puede ser definir un objeto por cada Tab Dialog.

Otra alternativa es usar código HTML externo que permite simular estos tabs.

MASTER PAGE
En las aplicaciones Web se recomienda la utilización de Master Pages, de forma que permita
centralizar el diseño y el comportamiento de la aplicación en un solo objeto y reutilizarlo en otros
objetos sin requerir programación.

Para profundizar en los temas de conversión de aplicaciones GUI-Windows a aplicaciones Web se


recomienda acceder a la dirección:
http://www.gxopen.com/commwiki/servlet/hwiki?ConversionWinWeb

INTRODUCCIÓN

En este capítulo veremos GXportal, herramienta que permite diseñar, administrar y mantener
portales escalables, sin necesidad de programar. Por lo tanto el usuario de GXportal no necesita
tener conocimientos específicos de programación o diseño.

GXportal brinda una interfaz Web amigable desde la cual el usuario, en pocos pasos, construye y
publica la información en el portal.
La practicidad de GXportal asegura la reducción de los costos de desarrollo y mantenimiento, así
como también de los tiempos en llevar las nuevas ideas al mercado (time-to-market).

GXportal ofrece un marco de trabajo para la integración de conocimiento, información y aplicaciones


a través de un portal, buscando unir los distintos actores de la organización y las comunidades.

GXportal

GXportal permite la integración de su personal, clientes y socios de negocios a través de la Web,


compartiendo información y aplicaciones en forma interactiva y segura.

GXportal es la herramienta para construir portales para organizaciones que necesitan conectar a sus
miembros, socios, y clientes a través de Internet en forma rápida, segura y eficiente. Construido
utilizando la tecnología GeneXus, GXportal incorpora vistas de diseño y gestión de contenido
independientes, y funciones de gestión automática del contenido y del diseño que lo hacen único
dentro de las herramientas de colaboración.

GXportal le permite a su organización integrar fácilmente conocimiento, contenido, y aplicaciones,


brindando una solución integral para la gestión de su Front End y Back End en la Web.
Principales Características

SIMPLE
La administración de la información del portal puede ser realizada por personal no especializado,
accediendo al Back End del portal desde cualquier PC conectado a Internet. El proceso de
administración de contenido guía al usuario en el ingreso y mantenimiento de la información.
Permite definir dónde y cuándo se publicará el contenido y cuáles son los roles para cada tarea, lo
que asegura el manejo confiable de la información.

DISEÑO Y CONTENIDO INDEPENDIENTES


El contenido y el diseño del sitio se gestionan en forma independiente. El proceso de diseño se basa
en plantillas de publicación que se administran en forma independiente del proceso de ingreso y
publicación del contenido. Las plantillas son estilos de páginas pre-definidas o definidas por el
usuario que se aplican a las páginas del portal. Cuando se modifica una plantilla, en forma
automática se modifican las páginas que están basadas en ella. El uso de las plantillas reduce el
mantenimiento y tiempo de desarrollo de las páginas del sitio.

GESTIÓN AUTOMÁTICA DEL CAMBIO


El uso de plantillas y componentes Web hace que la tarea de diseño se concentre en pocas páginas,
ya que al modificar una plantilla los cambios se propagan automáticamente a todas las páginas
creadas en base a ella.

SINGLE SIGN ON
El módulo Single Sign On permite la unificación del control de usuarios de GXportal y aplicaciones
externas.

ARQUITECTURA ESCALABLE
GXportal le permite implementar soluciones que van desde un servidor único para base de datos y
servidor Web, hasta configuraciones con múltiples servidores en diversas ubicaciones.

ADMINISTRACIÓN DE COMUNIDADES
GXportal cuenta con las siguientes herramientas para lograr un ámbito de interacción entre los
distintos integrantes de las comunidades:

• Encuestas

• Foros
• Listas de noticias

• Preguntas Frecuentes

SEGURIDAD
La seguridad está basada en roles, dependiendo de los roles que tenga asignado el usuario se le
presentarán las funcionalidades del Back End a las cuales puede acceder para realizar tareas de
administración.

Figura 2: Seguridad Gxportal. El acceso a la información dependerá de los roles que se le asignen, es
posible restringir el acceso de los usuarios Web a contenidos, menúes, páginas o canales. De esta
forma se logra controlar y segmentar el público del portal.
Principales Beneficios

DISEÑO WEB
El primer paso en la creación de un sitio Web efectivo es la creación de páginas visualmente
atractivas. El diseño de las páginas Web en GXportal se realiza en forma independiente del
contenido y de la funcionalidad del sitio. Los diseñadores Web no necesitan tener conocimientos de
programación ni limitaciones funcionales a la hora de diseñar el “look & feel” de su sitio.

El diseño se realiza en base a plantillas que pueden ser actualizadas en cualquier momento. Las
plantillas son estilos de páginas pre-definidas o definidas por el usuario que se aplican a las páginas
del portal. Cuando se modifica una plantilla, el diseño de las páginas que se basan en ella se actualiza
en forma automática.

El diseño independiente del contenido y el uso de plantillas posibilita la creación sitios cuyo “look &
feel” puede evolucionar junto con las necesidades de sus visitantes, al tiempo que reduce
drásticamente los costos y tiempos de desarrollo y mantenimiento del sitio.

GESTIÓN DE CONTENIDOS
El segundo paso en la creación de un sitio efectivo es asegurar que la información que contiene sea
correcta, esté actualizada, y sea pertinente para sus visitantes. Las funcionalidades de gestión de
contenido de GXportal permiten delegar las tareas de generación de contenido a sus creadores.

Para ello, incorpora workflows para gestionar el proceso de creación, edición, y traducción de
contenidos, y mecanismos de publicación por fecha, de segmentación de contenidos, y de
personalización del sitio por parte de sus visitantes.

La gestión de contenidos de GXportal permite obtener un portal totalmente actualizado, sin


intervención de técnicos ni procesos de subida de información en los servidores.

GESTIÓN DE COMUNIDADES
El tercer componente fundamental en la creación de un sitio efectivo es la interacción con sus
visitantes. GXportal cuenta con herramientas para lograr un ámbito de interacción óptimo entre los
miembros de su comunidad como newsletters, foros de discusión, encuestas, preguntas frecuentes,
etc..

Las herramientas de gestión de comunidades de GXportal le permiten interactuar con sus visitantes
en forma óptima.
INTEGRACIÓN DE APLICACIONES
El grado máximo de desarrollo de los sitios es el acceso cualquier aplicación en forma remota y
segura a la vez.

Los conectores habilitan la integración a sus páginas de componentes externos tales como código
HTML, Flash, Javascript, XML, aplicaciones o páginas Web externas y Web services.

Descripción del Producto

Figura 3: Descripción de GXportal

CONTENIDO
El módulo de contenido permite administrar y gestionar de forma ágil, segura y ordenada los
contenidos que serán publicados en el portal. Guía al usuario en el proceso de ciclo de vida de la
información mediante un workflow asegurando la consistencia de los datos en el momento de su
publicación.

Toda la gestión del contenido se realiza a través de una interfaz Web permitiendo al usuario tener
una visión organizada y centralizada de la información independientemente de donde será
publicada.
DISEÑO
GXportal ofrece a través del módulo de diseño una interfaz amigable e intuitiva mediante la cual el
usuario, sin necesidad de programar, puede diseñar las páginas del portal. Esta tarea se realiza
personalizando cada página, pudiendo reutilizar los diseños de otras.

El usuario puede definir sus propias plantillas y asociarle un conjunto de páginas. De esta manera se
obtiene una reducción en los costos de mantenimiento y permite que los cambios se hagan de
manera rápida, pues los cambios en la plantilla impactan en forma automática en todas las páginas
asociadas.

COMUNIDAD
Las comunidades surgen a partir de los intereses en común que tienen las personas que navegan un
sitio. Por lo tanto, el sitio deberá proveer de las herramientas que hacen posible la creación y
funcionamiento de las comunidades, como ser: foros de discusión, lista de noticias, preguntas
frecuentes, encuestas, etcétera.

GXportal cuenta con las herramientas necesarias para lograr un ámbito de interacción entre los
distintos integrantes de las comunidades.

SEGURIDAD
Contar con herramientas de segmentación permite controlar a que tipo de información puede
acceder cada usuario y controlar el acceso a determinadas áreas del portal que son privadas y
destinadas a determinados usuarios. La seguridad definida por GXportal le permite contar con la
definición de roles que desee de manera de poder segmentar el público objetivo de la mejor manera
posible y además de contar con el soporte de protocolo seguro que le dé la tranquilidad al usuario
de que la información se envía de manera totalmente privada y segura.

Tecnologías Soportadas

• Plataformas de ejecución: Java, Microsoft .NET

• Sistemas Operativos: LINUX, UNIX, Windows 2000/2003 Servers, Windows 2000/XP

• Sistemas de Administración de Bases de Datos (DBMS): IBM DB2 UDB, Microsoft SQL Server,
Oracle, MySQL

• Servidores Web: Microsoft IIS, Apache, WebSphere, etc.

Ver la lista actualizada de plataformas soportadas en http://www.gxportal.com/technologies


Utilizando GXportal

1. DISEÑO
En esta etapa se realiza un análisis con el fin de determinar objetivos del portal, público o
comunidades a las cuales se dirigirá el portal, que información se quiere publicar y de que forma se
segmentará dicha información. De este análisis se debe obtener lo siguiente:

• Visión del portal (modelo de negocio)

• Mapa de navegación del portal

• Diseño gráfico del portal

• Gestión de contenido (workflow)

• Arquitectura (hardware y software)

2. CONSTRUCCIÓN
Durante esta etapa se trabaja directamente desde el Back End de GXportal definiendo las plantillas
de diseño que surgieron del diseño gráfico de la etapa anterior. Luego en base a estas plantillas se
crean las páginas del portal basándolas en las plantillas definidas. Además se realiza el ingreso de los
contenidos del portal mediante los grupos de usuarios que se definieron y utilizando las
herramientas de workflow provistas por GXportal para este cometido.

3. PUESTA EN PRODUCCIÓN DEL PORTAL


Una vez que se tiene todo el diseño de las páginas del portal y todo el contenido que se quiere
publicar en el portal aprobado se puede realizar la publicación del portal. Para esto simplemente se
debe utilizar la herramienta de publicación del portal que permite a través de la acción de un clic
publicar todo los componentes de diseño del portal. El contenido debe haber sido autorizado y
publicado anteriormente para que el portal muestre toda la información.

4. MANTENIMIENTO DEL PORTAL


Cuando una organización comienza a operar el Portal, es necesario hacer un seguimiento
postinstalación para asegurarse que el mismo esté siendo bien asimilado.

En esta etapa se debe culminar con la capacitación de los usuarios involucrados en la administración
del contenido. Y se debe hacer un seguimiento de la evolución del contenido y de los usuarios en el
portal para analizar cuales son los cambios a realizar en el portal de manera de estar en constante
evolución y poder dar un mejor servicio a través de él.
INTRODUCCIÓN

Existen otras características interesantes para el desarrollo de aplicaciones Web, que presentamos
en este capítulo.

 Menú de Opciones
 Funciones de acceso al header de un objeto Web
 Manejo HTTP
 WAP
 Web Services
 WebWrapper

Menú de Opciones

A la hora de crear los menúes de opciones en las aplicaciones Web, básicamente surgen dos formas
de implementarlos desde GeneXus. Una de las soluciones posibles es implementarlo con JavaScripts
y otra solución es con grids FreeStyle. Siendo la primera la más utilizada hasta el momento.

En la siguiente URL www.gxopen.com.uy se pueden bajar proyectos con menúes ya implementados


a modo de ejemplo para cualquiera de las dos soluciones.

Como otra alternativa se puede contar con Gxportal, herramienta que brinda soluciones para los
menúes e incluso Patterns aunque no genera menúes, si genera una serie de links que permiten
navegar por toda la aplicación (tanto en el header y como los recents links).

Tipo de Datos HttpClient, HttpResponse y HttpRequest

Introducción

Esta funcionalidad provee a los usuarios GeneXus una forma de poder utilizar el protocolo HTTP en
sus programas. Para ello se crearon los tipos de datos HttpClient, HttpResponse y HttpRequest.

Descripción

Los tres tipos de datos que se definen para interactuar con http son:

HttpClient

Permite armar un request, enviarlo a una URL y leer los resultados.


HttpResponse y HttpRequest

Permiten leer los datos del request y grabar el response. Son objetos disponibles sólo en
Procedimientos Web.

HTTPCLIENT
Este objeto refleja una conexión http. Puede usarse desde cualquier objeto GeneXus.

Propiedades
A continuación se detalla la lista de propiedades:

Host
Define el nombre del host.
Tipo- String

Port
Define el puerto del host.
Tipo- String

Secure
Indica si el protocolo es http o https.
Tipo- Boolean

Timeout
Determina el Timeout de la conexión.
Tipo- Integer

BaseURL
Indica la URL base de los request que se hagan al host.
Tipo- String

StatusCode
Retorna el código de error HTTP.
Tipo- Integer

ReasonLine
Retorna el texto del error HTTP.
Tipo- String

ErrCode
Retorna si ocurrió algún error en algún comando, en cuyo caso retorna un valor distinto de cero.
Tipo- Integer

ErrDescription
Retorna el mensaje del error si ocurrió alguno en algún comando.
Tipo- String

Basic y Digest
Son constantes que determinan un tipo de autenticación. Se utilizan en el método AddAuthentication.
Basic=0 : Para autentificar se envía el usuario y password sin encriptar.
Digest=1: Para autentificar se envía el usuario y password encriptados.

ProxyHost y ProxyPort
Permiten especificar un proxy http. En ambiente windows se utiliza automáticamente el que esta configurado
en la máquina.
ProxyHost- String
ProxyPort- Integer
Métodos
AddHeader(<Name>, <Value>)
Agrega un header con el valor dado.
Ejemplo: AddHeader(“User-Agent”, “GeneXus”)
<Name>- String
<Value>- String

AddVariable(<Name>,<Value>)
Agrega una variable al ‘form’.

Ejemplo: AddVariable(“CliCod”, &CliCod)

<Name>- String
<Value>- String

AddString(<Value>)
Agrega el contenido del string al buffer de datos a enviar.
<Value>- String

AddFile(<Value>)
Agrega el contenido del archivo al buffer de datos a enviar.
<Value>- String

Execute(<Method>,<URL>)
Ejecuta un método en la URL definida. Se pondría solo la parte final de la URL
Ejemplo: execute("POST", "/servlet/awebproc")
<Method>- String
<URL>- String

ToString()
Retorna un String con todo el “cuerpo” del response.

ToFile(<FileName>)
Graba en un archivo el contenido del stream.
<FileName>- String

GetHeader(<Name>,<Value>)
Retorna en <Value> el valor del header convertido al tipo de la variable.
<Name>- String
<Value>- Anytype

AddAuthentication(<Method>, <Realm>, <User>, <Password>)


Se autentifica con <User> y <Password> al dominio <Realm> utilizando el tipo de autenticación <Method>.
<Method>- Integer (Pueden utilizarse las propiedades Basic y Digest)
<Realm>- String
<User>- String
<Password>- String
HTTPREQUEST
Este objeto permite leer el request http. Puede instanciarse solo en el contexto de un WebProc.

Propiedades
Method
Retorna el método HTTP.
Tipo- String

ServerHost
Retorna el nombre del servidor

Tipo- String

ServerPort
Retorna el puerto en el servidor
Tipo- Integer

Secure
Indica si se esta utilizando HTTPS. Si el valor retornado es 1, se está utilizando HTTPS; si es 0, se está
utilizando http.
Tipo- Integer

ScriptPath
Retorna la porción de URL correspondiente el nombre del directorio virtual.
Tipo- String

ScriptName
Retorna el nombre del objeto con la extensión correspondiente que se esta ejecutando, tal como aparece en
la URL.
Tipo- String

Referrer
Retorna la URL del llamador.
Tipo-String

QueryString
Retorna la porción de la URL que está después del signo “?”; o sea los parámetros.
Tipo- String

RemoteAddress
Devuelve la dirección del cliente.
Tipo- String

ErrCode
Retorna si ocurrió algún error en algún comando, en cuyo caso retorna un valor distinto de cero.
Tipo- Integer

ErrDescrption
Retorna el menaje del error si ocurrió alguno en algún comando.
Tipo- String

Métodos
GetVariable(<Variable>)

Retorna en un String el valor con el que viene cargada la <Variable> en el post.


<Variable>- String

GetHeader(<Header>)
Retorna un String con el valor del header <Header>.
<Header>- String

ToString()
Retorna un String con todo el ‘cuerpo’ del request.

ToFile(<FileName>)
Graba en un archivo el contenido del stream.
<FileName>- String

HTTPRESPONSE
Este objeto permite escribir el response http. Puede instanciarse sólo en el contexto de un
Procedimiento Web.

Propiedades
ErrCode
Retorna si ocurrió algún error en algún comando, en cuyo caso retorna un valor distinto de cero.
Tipo- Integer

ErrDescrption
Retorna el menaje del error si ocurrió alguno en algún comando.
Tipo- String

Métodos
AddHeader(<Name>,<Value>)
Agrega un header con el valor dado.
Ejemplo: AddHeader(“User-Agent”, “GeneXus”)
<Name>- String
<Value>- String

AddString(<Value>)
Agrega el contenido del string al buffer de datos a enviar.
<Value>- String

AddFile(<Value>)
Agrega el contenido del archivo al buffer de datos a enviar.
<Value>- String

INTERACCIÓN CON XML


Estos objetos permiten la interacción con los objetos XMLReader y XMLWriter. Para ello existen los
siguientes métodos:

XMLReader.openRequest(HttpRequest)

Se utiliza en un WebProc para leer un xml que viene en el body del http request.

XMLReader.openResponse(HttpClient)

Se utiliza en cualquier objeto para leer como XML lo que devolvió un request.

XMLWriter.openRequest(HttpClient)
Se utiliza para enviar un XML en el body de un http request.

XMLWriter.openResponse(HttpResponse)

Se utiliza en un Procedimiento Web para escribir un XML que se retornara en el body del http
response.

Ejemplo

Este ejemplo muestra como un objeto GeneXus llama a otro vía http, pasándole parámetros en un
XML y recibiendo los mismos también en un XML. El XML a enviar tiene la forma:

<parameters>

<a>valor</a>

<b>valor</b>

</parameters>

El XML que se devuelve es igual, con los valores de ‘a’ y ‘b’ modificados.

El programa “cliente” sería:

&Client de tipo HttpClient

&Writer de tipo XMLWriter

&Reader de tipo XMLReader

// Determino el host y el puerto a donde hacer el request

&client.host = "localhost"

&client.port = 88

// Agrego el XML al request

&writer.openRequest(&client)
&writer.WriteStartElement("parameters")

&writer.WriteElement("a", &A)

&writer.WriteElement("b", &B)

&writer.WriteEndElement()

&writer.close()

// Hago el POST al webproc

&client.execute("POST", "/servlet/awebproc")

// Leo el XML que devuelve y lo cargo en las variables internas

&reader.openResponse(&client)

&reader.read()

&reader.read()

&a = val(&reader.value)

&reader.read()

&b = val(&reader.value)

&reader.close()

El programa “servidor” sería el siguiente Procedimiento Web:

&Request de tipo HttpRequest

&Response de tipo HttpResponse


&Writer de tipo XMLWriter

&Reader de tipo XMLReader

// Leo los parámetros del XML

&reader.openRequest(&Request)

&reader.read()

&reader.read()

&a = val(&reader.value)

&reader.read()

&b = val(&reader.value)

&reader.close()

// Le sumo uno a cada valor

&a = &a + 1

&b = &b + 1

// Grabo los parámetros en el response

&writer.openResponse(&Response)

&writer.WriteStartElement("parameters")

&writer.WriteElement("a", &A)

&writer.WriteElement("b", &B)

&writer.WriteEndElement()

&writer.close()
Consideraciones para el generador Java

En el caso de que se ejecute el motor de servlet en Windows, la aplicación obtendrá


automáticamente la configuración del proxy http y la lista de hosts para los que no se debe utilizar el
proxy.

En caso de que se ejecute en otra plataforma, es necesario especificar el proxy como una ‘System
Property’ desde la línea de comandos del intérprete, por Ej.:

java -Dhttp.proxyHost=your.proxy.com -Dhttp.proxyPort=XX <mainclass>

Internet Móvil (WAP)

Introducción

En los últimos años tanto Internet como la telefonía celular han tenido un gran crecimiento y se han
hecho accesibles a millones de personas. Es posible ahora unir estas dos tecnologías accediendo de
forma fácil y rápida a la información que brinda Internet desde los teléfonos celulares (ó móviles).

GeneXus permite generar salidas para Internet móvil, generando objetos con contenido WML. Esto
aplica a Web Panels, generando tanto para Java como .NET.

Algunas definiciones

WAP (WIRELESS APLICATION PROTOCOL)


Es el protocolo más común de Internet Móvil.

Internet móvil es el término comercial para acceder a información de Internet a través de


dispositivos móviles. Los dispositivos móviles más comunes son los teléfonos celulares con
“microbrowser” pero también entran en esta categoría, los dispositivos de tipo palm y cualquier
dispositivo de información portátil, que pueda disponer de una conexión inalámbrica.
Este protocolo consiste en un modelo de capas que incluyen un IP inalámbrico, capas de seguridad
(WSL) y lenguajes de descripción de contenidos entre ellos WML.

WML
Lenguaje de Tags basado en XML. Es interpretado por los celulares WAP compatibles. Es parecido al
HTML, pero tiene menos potencia y soporta algunas cosas que el HTML no y es bastante más estricto
en la sintaxis.

WML VS HTML
Por el tamaño de la pantalla, es imposible traducir o ver de forma satisfactoria una página de Web
normal (HTML) en un celular. El tamaño, los tipos de letra, las imágenes y la cantidad de información
que se soporta en el Web no se puede soportar en un microbrowser y no es práctico hacerlo.

La navegación, además, es diferente, el usuario no tiene mouse, ni teclado por lo que el ingreso de
datos debe ser limitado y la navegación, mucho más simple.

MICROBROWSER
Es un software instalado en el teléfono o dispositivo inalámbrico que interpreta el WML (y el
WMLScript, WTAI, etc.) y despliega la información en la pantalla. Es posible acceder a emuladores de
celulares y sus microbrowser. Algunos de los más conocidos son UP Browser (Unwired Planet) de
Phone.com, RS380 Ericsson, Nokia, etc..

Arquitectura

La arquitectura es similar a Internet. El cliente es el teléfono celular con MicroBrowser y en el


servidor se encuentra la lógica en objetos (ejecutables o ASP) con contenido WML o sea que al ser
interpretados por los browsers generan WML.

Descripción

Para generar Web Panels con contenido WML, se implementó una nueva propiedad (a nivel de
objeto) denominada “Tag Language”.

Los valores de la propiedad son:

 HTML

 WML
El valor por defecto es HTML para cualquier objeto Internet. Con el valor WML es posible generar
objetos con contenido WML, estos podrán ser vistos desde un browser WAP.

Requerimientos

Para testear esta característica directamente en la máquina de desarrollo es necesario tener


instalado el emulador de microbrowser.

Recomendamos el UP Browser (UP.SDK version 4.0) que es posible bajarlo de:

http://www.openwave.com/products/developer_products/sdk/

El producto es sin cargo, para acceder al mismo se debe realizar la registración en dicha página.

El archivo ocupa aproximadamente 7 MB.

Diseño

Se deben definir los Web Panels como hasta el momento y configurar la propiedad “Tag Language”
en “WML”.

En el diseño del objeto se deben tener en cuenta las siguientes limitaciones del lenguaje generado
(WML):

 Los objetos WML están limitados en el tipo y cantidad de controles que se soportan así
como en el tamaño de las páginas debido a la cantidad de memoria de los móviles y el
tamaño de la pantalla.

 Las pantallas permiten entre 4 a 8 líneas de texto, dependiendo del móvil, por lo que no se
recomienda que las pantallas superen estos tamaños. No es conveniente que se tenga scroll
en una pantalla de teléfono celular.

 Sólo se soportan los siguientes controles:

o Edit

o Textblocks

o Texto libre

o Tablas simples

o Grids Free Style simples

 No se soportan:

o Variables dentro de tablas

o Ninguna anidación de tablas y/o grids Free Style


o Grids estándar

o Campos LongVarchar

o La letra ñ

o Tag <BR>

o Botones

o Cookies

o Encriptación de parámetros

 Las propiedades de runtime soportados son:

o Link

o Ispassword

o Visible

o Enabled

 El softbutton del teléfono (botón que se encuentra en la parte superior izquierda), se asocia
al Evento Enter.

Ejecución

Luego de generado el objeto se debe ejecutar desde el emulador celular, esto se realiza escribiendo
la dirección donde se encuentra el Web Panel en la barra de direcciones del mismo.
Ejemplo

Se desea desplegar un texto de prueba en un teléfono celular, los pasos a seguir son los siguientes:

1. Insertar el texto en un textblock en el form de un Web Panel.

Es aconsejable verificar el código generado, en el Tab “Source”, teniendo en cuenta las


consideraciones.

2. Especificar, generar y compilar el Web Panel desde GeneXus.

3. Ejecutar el UP.Simulator.

4. Escribir la dirección donde se encuentra el objeto (por ej. http://localhost/cgi-


bin/hPrueba.exe) en “Go”, y presionar Enter o el Softbutton.
5. En el teléfono celular se visualizará el texto ingresado en el Web Panel.

6. Si se producen errores en la pantalla del teléfono celular siempre se despliega el


siguiente mensaje:

“Compile error: See info windows for details.”

El texto completo del error se debe visualizar en el “Phone information’” (ventana DOS
que se ejecuta detrás del emulador).

Hay un ejemplo disponible en :

http://www.gxtechnical.com/main/Hdcenter.aspx?2,5,36,408
Errores comunes

Error Síntoma

“Error : Invalid element ‘PCDATA’ in contents Se debe a la ausencia de <P> en textblock o


of card.” variable.

“Error : Invalid element ‘br’ in contents of Se debe a un tag <BR> en el Source del objeto
card.”

“Error : Uncompiled data from http <head>.” La página no es WML es HTML, se debe
configurar la preference ‘Tag Language=WML’

“Error : Invalid element ‘textarea’” Se esta usando un longvarchar o un char de


varias líneas.

“Error : Missing entity “ntilde” Hay algún dato con la letra ñ y el microbrowser
no lo puede interpretar.

“Error : Invalid element ‘P’ in content of ‘p’. Se introdujo algun tag <P> anidado, esto no es
excpectde PCDATA | em | b …” válido en WML

Consideraciones

Consideraciones a tener en cuenta con el editor:

 El editor no toma en cuenta algunas restricciones necesarias para WML y puede generarse
código no válido, es preciso en estos casos modificar el source en el editor de diseño de
GeneXus.

 No es posible hacer cut & paste de controles y/o del Source.

 Existen algunos Tags HTML (no válidos en WML) generados por el editor. Por ejemplo el Tag
<BR> es generado por la combinación de teclas Shift+Enter en el editor.

 Textblock y variables deben generarse entre <P> y </P>. La generación de estos Tags se da
con un enter al final del edit o modificando Código en el Tab “Source”.

 Grids o tablas no deben limitarse por tags <P>. Es posible generar este código con algunas
combinaciones de teclas.
 Igualmente no es recomendable modificar el código WML (bajo el tab “HTML Source” )
pues pueden dar errores en ejecución.

 No se reciben correctamente variables por parámetro en los llamados realizados mediante


“call”.

INTRODUCCIÓN

Cada vez se escucha más el concepto de “Web Services”, fundamentalmente relacionado con
Internet y el futuro de una arquitectura orientada a servicios. Es por esta razón, que GeneXus incluye
la posibilidad de desarrollar y consumir Web Services.

Comenzaremos con una introducción al concepto de Web Services para luego realizar ejercicios
prácticos que permitan profundizar los conocimientos adquiridos.

Web Services

En los últimos tiempos ha surgido con mucha fuerza el concepto de Web Services, incluso
afirmándose que el mismo cambiaría la forma de programar las aplicaciones orientadas a Internet
hacia una arquitectura orientada a servicios. Todo esto se ha visto potenciado luego del anuncio de
Microsoft de su nueva estrategia .NET que está basada en el modelo de Web Services.

Este documento describe qué son los Web Services y cómo es la arquitectura general del modelo,
adicionalmente se provee una introducción de los estándares en los cuales se basa este modelo
como ser SOAP, WSDL y UDDI.
¿Qué es un Web Service?

Un Web Service es una aplicación que puede ser descripta, publicada, localizada e invocada a través
de una red, generalmente Internet. Combinan los mejores aspectos del desarrollo basado en
componentes y la Web.

Al igual que los componentes, los Web Services son funcionalidades que se encuentran dentro de
una caja negra, que pueden ser reutilizados sin preocuparse de cómo fueron implementados. A
diferencia de la actual tecnología de componentes, no son accedidos por medio de protocolos
específicos del modelo de objetos como ser RMI, DCOM o IIOP; sino que son accedidos utilizando
protocolos Web como ser HTTP y XML.

La interface de los Web Services está definida en términos de los mensajes que el mismo acepta y
retorna, por lo cual los consumidores de los Web Services pueden ser implementados en cualquier
plataforma y en cualquier lenguaje de programación, sólo tiene que poder crear y consumir los
mensajes definidos por la interface de los Web Services.

El modelo de Web Services

La arquitectura básica del modelo de Web Services describe a un consumidor, un proveedor y


ocasionalmente un corredor (broker). Relacionados con estos agentes están las operaciones de
publicar, encontrar y enlazar.

La idea básica consiste en que un proveedor publica su servicio en un corredor, luego un consumidor
se conecta al corredor para encontrar los servicios deseados y una vez que lo hace se realiza un lazo
entre el consumidor y el proveedor.

Cada entidad puede jugar alguno o todos los roles.


Por todo lo anterior hay ciertos requerimientos a la hora de desarrollar o consumir un Web Service:

 Una forma estándar de representar los datos

XML es la opción obvia para este requerimiento.

 Un formato común y extensible de mensajes

SOAP es el elegido en este caso; SOAP es un protocolo liviano para el intercambio de información.
Más adelante en este documento lo veremos con más detalle.
 Un lenguaje común y extensible para describir los servicios

La opción en este caso es WSDL. Es un lenguaje basado en XML desarrollado en forma conjunta por
IBM y Microsoft. Lo veremos con más detalle más adelante en este documento.
 Una forma de descubrir los servicios en Internet

UDDI se utiliza en este caso; el mismo especifica un mecanismo para publicar y localizar los
servicios por parte de los proveedores y consumidores respectivamente. Se verá con más
detalle más adelante en este documento.

Ventajas y retos

Los Web Services apuntan a ser la piedra fundamental de la nueva generación de sistemas
distribuidos. Estos son algunos puntos para fundamentar esta afirmación:

 Interoperabilidad

Cualquier Web Service puede interactuar con otro Web Service. Como los Web Services pueden ser
implementados en cualquier lenguaje, los desarrolladores no necesitan cambiar sus ambientes de
desarrollo para producir o consumir Web Services.
 Ubicuidad

Los Web Services se comunican utilizando HTTP y XML. Por lo tanto cualquier dispositivo que
soporte estas tecnologías puede implementar o acceder Web Services. Muy pronto estarán
presentes en teléfonos, autos e incluso máquinas expendedoras, las que avisarán a la central
cuando el stock sea menor al indicado.

 Encapsular reduce la comlejidad


Todos los componentes en un modelo de Web Services son Web Services. Lo importante es la
interface que el servicio provee y no cómo está implementado, por lo cuál la complejidad se reduce.
 Fácil de utilizar

El concepto detrás de los Web Services es fácil de entender, incluso existen toolkits de vendedores
como IBM o Microsoft que permiten a los desarrolladores crear Web Services en forma rápida y fácil.
 Soporte de la Industria

Todas las empresas de software importantes soportan SOAP, e incluso están impulsando el
desarrollo de Web Services. Por ejemplo la nueva plataforma de Microsoft .NET está basada en Web
Services, haciendo muy simple el desarrollo de los mismos que luego podrían ser consumidos por un
Web Service desarrollado utilizando VisualAge de IBM y viceversa.

A la vez hay ciertos retos técnicos que los Web Services tienen que sortear para poder tener éxito. Muchos
de estos retos están relacionados con el ambiente abierto en el que tienen que sobrevivir. Estos son algunos
de esos puntos:

 Descubrimiento
¿Cómo se anuncia un Web Service para ser descubierto por otro servicio? ¿Qué pasa si el servicio se
cambió o se movió luego de ser anunciado?
WSDL y UDDI son dos nuevos estándares que manejan este punto.
 Confiabilidad
Algunos Web Services son más confiables que otros. ¿Cómo puede ser medida esa confiabilidad y
comunicada? ¿Qué pasa cuando un Web Service está off-line en forma temporaria? ¿Localizamos y
utilizamos un servicio alternativo brindado por otra empresa o esperamos a que el servicio esté de nuevo
on-line?
 Seguridad
Muchos Web Services son publicados para ser utilizados sin ninguna restricción, pero muchos otros van a
necesitar autenticación para que los utilicen sólo los usuarios autorizados. ¿Cómo autentifica a los
usuarios un Web Service? ¿Lo hace a nivel del método que lo implementa o utiliza otro Web Service para
realizar la autenticación?
 Responsabilidad
En caso de que el Web Service no sea de acceso libre, ¿Cómo puedo definir cuántas veces un
consumidor puede acceder al Web Service una vez contratado? ¿Cómo se cobra su uso? ¿Cómo se indica
que un servicio ya no está más en línea?
Tecnologías asociadas

El modelo de Web Services está basado en ciertas tecnologías emergentes que es el resultado del
trabajo de varias compañías y organizaciones entre las cuales se destacan IBM y Microsoft. Estas
tecnologías son SOAP, WSDL y UUDI.

SOAP (SIMPLE OBJECT ACCESS PROTOCOL)


SOAP es un protocolo para el intercambio de información en un ambiente descentralizado y
distribuido. Es el protocolo más utilizado para realizar el intercambio de información en el modelo
de Web Services.

Está basado en XML y potencialmente puede ser utilizado en combinación con una variedad de
protocolos de comunicación, siendo el más utilizado HTTP. Por lo tanto se utiliza HTTP para
transportar la información, y XML para representar la misma.

El protocolo completo se puede encontrar en http://www.w3.org/TR/soap

El modelo de comunicación de SOAP


El modelo de comunicación de SOAP es muy similar al de HTTP. Un cliente hace un requerimiento
(request), el servidor que está escuchando los requerimientos lo atiende y responde (response)
brindando la información solicitada o enviando un mensaje de error en caso de que el requerimiento
no haya sido válido.

El mensaje SOAP consiste en un elemento envelope SOAP obligatorio, un cabezal SOAP opcional y un
cuerpo SOAP obligatorio como un documento XML. El cabezal SOAP es utilizado para definir
información acerca del requerimiento, mientras que el cuerpo SOAP contiene el método llamado y
los parámetros con los que se llama al mismo.

Todo esto es un modelo de mensajes request/response con una forma de describir un conjunto de
métodos y pasarle a los mismos parámetros. Esto parece la base del protocolo RPC y de hecho es el
uso más común de SOAP. El potencial es entregar esto sobre Internet utilizando HTTP para realizar
comunicaciones entre organizaciones permitiendo realizar comunicaciones entre aplicaciones con
diferente plataforma, sistema operativo y lenguaje de programación.
A continuación se muestra un mensaje SOAP embebido en un request HTTP:

Este ejemplo invoca al servicio StockQuote llamando al método GetLastTradePrice con el símbolo
DIS por parámetro.

Esta es la respuesta al requerimiento anterior, el cual retorna el precio de la acción solicitada:

Si usted quedó asustado por la aparente complejidad del protocolo SOAP pensando lo engorroso
que sería armar los mensajes de requerimiento y parsear los mensajes de respuesta despreocúpese;
la mayoría de los lenguajes de programación proveen o proveerán soporte para realizar esto. La idea
fundamental consiste en utilizar algún objeto al cual se le brinda un WSDL y se le indica qué método
se quiere llamar y con qué parámetros. Esto arma en tiempo de ejecución el mensaje SOAP, lo
manda y parsea el resultado adjudicándoselo a alguna variable en forma trasparente para el usuario
como si hubiera hecho un call común.

WSDL: WEB SERVICES DESCRIPTION LANGUAGE


WSDL es un lenguaje basado en XML que se utiliza para describir un Web Service. Ha sido
suministrado por la W3C por estandarización.
Un archivo con formato WSDL provee información de los distintos métodos (operaciones) que el
Web Service brinda, muestra cómo accederlos y qué formatos deben de tener los mensajes que se
envían y se reciben. Es como un contrato entre el proveedor del servicio y el cliente, en el cual el
proveedor se compromete a brindar ciertos servicios sólo si el cliente envía un requerimiento con
determinado formato. Es el documento principal a la hora de documentar un Web Service, pero
puede no ser el único. En la mayoría de los casos es conveniente que esté acompañado por un
documento escrito en lenguaje natural que brinde información de qué es lo que hace cada uno de
los métodos brindados por el Web Service así como también ejemplos, tales como los mensajes
SOAP que espera y responde el servicio.

En forma resumida podríamos decir que un archivo WSDL describe lo siguiente:

 Mensajes que el servicio espera y mensajes que el servicio responde.

 Protocolos que el servicio soporta.

 A dónde mandar los mensajes.

Formato de un archivo WSDL


A continuación se muestra cómo es el formato básico de un archivo WSDL. La especificación
completa de este lenguaje se puede encontrar en http://www.w3.org/TR/wsdl.html.

Un archivo con formato WSDL básicamente contiene los siguientes elementos:

Type: Describe los tipos no estándar usados por los mensajes (Message).

Message: Define los datos que contienen los mensajes pasados de un punto a otro.

PortType: Define una colección de operaciones brindadas por el servicio. Cada operación tiene un
mensaje de entrada y uno de salida que se corresponde con algún Message antes definido.

Binding: Describe los protocolos que se utilizan para llevar a cabo la comunicación en un
determinado PortType; actualmente los protocolos soportados son SOAP, HTTP GET, HTTP POST y
MIME, siendo SOAP el más utilizado.
Port: Define una dirección (URL) para un determinado Binding.

Service: Define una colección de Ports.

El siguiente es un ejemplo de archivo WSDL:

El mismo define dos mensajes (Simple.foo y Simple.fooResponse), luego define un método llamado
“foo” el cual recibe el mensaje Simple.foo y retorna el mensaje Simple.fooResponse. A continuación
se define un binding para el método foo asociándolo con el protocolo SOAP. Por último se da una
URL física que implementa lo antes descrito.
Interfaz e implementación
La estructura básica de archivo con formato WSDL podría ser dividido en dos partes lógicas: la
interfaz del servicio, y la implementación del mismo.

Esta división lógica divide los elementos de la siguiente forma:

Interfaz del servicio

Type, Message, PortType, Binding.

Contiene una definición abstracta y reusable del servicio que puede ser instanciada y referenciada
por distintos proveedores del mismo.

Implementación del servicio

Port, Service.

Contiene una implementación de una determinada Interfaz del servicio.

A partir de esta división lógica se puede definir por medio de una Interfaz del servicio un estándar
para realizar, por ejemplo, órdenes de compras que puede ser reutilizada e implementada por todas
las empresas, sin tener que redefinir cada una de ellas la interfaz.

Si al igual que con SOAP se siente preocupado por la complejidad de los archivos WSDL de nuevo
despreocúpese; la mayoría de los lenguajes de programación proveen o proveerán herramientas
para generar en forma automática el archivo WSDL a partir de un determinado método o función.

UDDI (UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION)


UDDI (www.uddi.org) es un proyecto inicialmente propuesto por Ariba, Microsoft e IBM; es un
estándar para registrar y descubrir Web Services. La idea es que las distintas empresas registran su
información acerca de los Web Services que proveen para que puedan ser descubiertas y utilizadas
por potenciales usuarios.

La información es ingresada al registro de empresas UDDI, un servicio lógicamente centralizado, y


físicamente distribuido a través de múltiples nodos los cuales replican su información en forma
regular. Una vez que una empresa se registra en un determinado nodo del registro de empresas
UDDI la información es replicada a los otros nodos y queda disponible para ser descubierta por otras
empresas.
El esquema UDDI
El modelo de información base utilizado por los registros UDDI es definido en un esquema XML. Este
esquema define cuatro tipos básicos de información, cada uno de los cuales proveen la clase de
información que un usuario necesita saber para utilizar un Web Service de otra empresa.

Los cuatro tipos de información son:

 Información del negocio

Este tipo de información está definido en el elemento businessEntity. Contiene información de la


empresa, como ser su nombre, los contactos, el tipo de empresa, etc.

 Información del servicio

Dentro del elemento businnessEntity se encuentran los elementos businessServices, estos


elementos contienen información sobre Web Services generalmente agrupados por procesos de
negocio o categorías de servicios.

 Información del enlace (binding)

Dentro de cada elemento businessServices se encuentran los elementos bindingTemplate.


Cada uno de ellos brinda una dirección fisica para hacer contacto con los servicios
descriptos anteriormente.

 Información sobre las especificaciones del servicio

Cada bindingTemplate tiene asociado un tModel, el cual brinda informacíon sobre las
especificaciones del servicio, por ejemplo, cómo tienen que ser los mensajes que el servicio espera
y responde, etc.
Un tModel puede ser asociado con elementos bindingTemplate de distintas empresas que
brindan la misma especificación del servicio. Utilizando entonces los tModels se pueden
encontrar todas las empresas que brindan tal servicio.
Por más información sobre el esquema UDDI:

http://www.uddi.org/pubs/ProgrammersAPI_v2.pdf

API UDDI
El acceso al registro UDDI, ya sea para realizar búsquedas o para ingresar o modificar un registro, se puede
realizar a través de una página Web que implemente el acceso o utilizando ciertas interfaces (Web Services)
que provee la especificación de UDDI. Estas interfaces están descriptas en una API, que puede ser dividida en
dos partes lógicas, la API de consultas y la API de publicación.
Por más información sobre la API UDDI: http://www.uddi.org/pubs/ProgrammersAPI_v2.pdf

Un ejemplo

Las formas en que se pueden realizar negocios utilizando Web Services son muy variadas. El
consumidor podría pagar por utilizar los servicios brindados por un proveedor, o el proveedor podría
pagar para que aparezcan los servicios que él ofrece en un determinado consumidor, o incluso
existen casos en los cuales ni el consumidor ni el proveedor pagan por consumir o proveer los
servicios en forma respectiva. Este es el caso que se presenta a continuación.

El ejemplo es tomado de la vida real y es sobre la compañía aérea Southwest. En su portal


http://www.southwest.com/ , esta compañía aérea permite hacer reservas de boletos, pero además
como valor agregado a los clientes permite hacer reservas de hoteles y reservas de alquileres de
autos. Los datos para poder realizar estas reservas están tomados de Web Services que brindan los
distintos hoteles y rentadoras de autos.

Este es un ejemplo de uso de Web Services en el cual ni el consumidor ni los proveedores pagan; a
ambos les sirve este intercambio ya que la compañía de aviones le brinda un valor agregado a sus
clientes, y los hoteles y rentadoras de autos están expuestos a ser contratos por potenciales clientes.
Es más, estas empresas no publicaron sus servicios para que fueran exclusivamente utilizados por la
compañía aérea, sino que los mismos pueden ser descubiertos y utilizados por cualquier empresa
que los necesite.
Claramente se muestra en este ejemplo el gran poder de los Web Services, y la ventaja que tendrán
las empresas que los sepan utilizar en forma adecuada con respecto a las otras. Imagínese en este
caso si usted fuera a reservar boletos de avión y pudiera elegir por una compañía que además de
reservar los boletos le permitiera hacer la reserva de hotel, y otra que no; ¿por cual haría la reserva?
Por otro lado imagine que usted es dueño de una rentadora de autos y sabe que su competencia
está brindando sus servicios en un portal de una compañía aérea y usted no, ¿qué haría?

XML

Introducción

Hoy en día, se pueden encontrar muchísimos sitios Web que brindan servicios on-line como por
ejemplo reservas de asientos para espectáculos, aviones, reportes meteorológicos, etc.; para poder
brindar estos servicios a los usuarios, los diseñadores y los programadores Web deben combinar los
datos y la presentación en un documento HTML. Muchas veces el proveedor de determinada
información no es quien la va a “procesar” (sea esto publicarla en un sitio, ingresarla en una
aplicación, etc).

La necesidad de generar grandes cantidades de datos dinámicos y complejos por un lado y la


necesidad de procesarlos y publicarlos por otro, han provocado la definición de un formato de datos
universal: XML.

Descripción

La idea principal detrás de XML es el desarrollo de un lenguaje estándar de etiquetas (similar a


HTML) para describir datos en forma estructurada. Este lenguaje debe poder ser interpretado tanto
por computadoras como por seres humanos. Si una aplicación en el servidor del servicio
meteorológico graba un documento XML con el reporte del tiempo y luego otro sitio Web puede
leer dicho documento, se puede publicar el estado del tiempo en forma automática, sin necesidad
de ingresarlo dentro de la aplicación del sitio Web cada día o convertir la información recibida.

El lenguaje XML está compuesto por etiquetas que describen el contenido del documento. Un
elemento XML queda definido por una etiqueta de comienzo y otra de fin con el valor del elemento
entre ambas etiquetas. Los elementos pueden estar anidados y además pueden contener en forma
opcional, uno o más atributos. Los atributos son usados para adjuntar información secundaria a los
elementos.

A continuación se visualiza un ejemplo de un documento XML:


<weather-report>

<date>March 25, 2000</date>

<time>08:00</time>

<area>

<city>Montevideo</city>

<country>Uruguay</country>

</area>

<measurements>

<skies>partly cloudy</skies>

<temperature>26</temperature>

<wind>

<direction>SW</direction>

<windspeed>6</windspeed>

</wind>

<humidity>87</humidity>

<visibility>10</visibility>

</measurements>

</weather-report>

El ejemplo anterior está compuesto únicamente por elementos XML, pero el mismo podría
redefinirse, de forma que la información correspondiente al área estuviese representada por
atributos, como se representa a continuación:

<weather-report city=Montevideo country=Uruguay>

<date>March 25, 2000</date>

<time>08:00</time>

<measurements>

<skies>partly cloudy</skies>
<temperature>26</temperature>

<wind>

<direction>SW</direction>

<windspeed>6</windspeed>

</wind>

<humidity>87</humidity>

<visibility>10</visibility>

</measurements>

</weather-report>

Si bien el hecho de estar compuesto por etiquetas hace que sea parecido a HTML, hay una diferencia
muy importante: en un documento XML no hay información acerca de cómo deben ser presentados
los datos. Así, como HTML provee etiquetas específicas para formatear un documento, XML provee
un marco para crear etiquetas.

Resumiendo, XML es un lenguaje estándar definido por el Consorcio World Wide Web para permitir
grabar y leer datos en forma estructurada con formato estándar independiente de aplicaciones y
vendedores.

En GeneXus, se cuenta con funciones para el manejo de XML: XMLWriter, XMLReader.

Protocolo SOAP

Introducción

SOAP es un protocolo “liviano” basado en XML, para invocar procedimientos en forma remota
(Remote Procedure Call). Utiliza cualquier protocolo que permita transportar mensajes de texto,
siendo HTTP el más utilizado.

Su especificación describe el contenido que debe tener un mensaje XML para ser usado en una
invocación remota.
Cualquier aplicación que cumpla la especificación puede invocar y proveer servicios sin importar en
que lenguaje o plataforma esté implementado, lo único necesario es que la aplicación sea capaz de
interpretar el mensaje SOAP que recibe, realizar el procesamiento que el mensaje requiera, y
devolver otro mensaje SOAP con la respuesta.

En las aplicaciones generadas por GeneXus se utiliza SOAP para invocar a objetos en forma remota,
usando HTTP como protocolo de transporte.

Alcance

OBJETOS LLAMADORES (CLIENTES)


Aplica a todos los objetos, generando tanto para Java como para .NET.

Los objetos llamadores son los que invocan servicios mediante SOAP.

OBJETOS LLAMADOS (SERVIDORES)


Aplica a los objetos: Procedimientos y Reportes, generando tanto para Java como para .NET.

Los objetos llamados son los que brindan un servicio invocado mediante SOAP.

Descripción

Algunas de las ventajas de utilizar este protocolo en aplicaciones GeneXus son la posibilidad de
desarrollar servicios Web, así como el poder hacer invocaciones entre objetos de diferentes
generadores (por ej. llamar desde Java a .NET).

Servidor

Para indicar en GeneXus que un objeto main va a ser llamado utilizando el protocolo SOAP, se
deberá seleccionar el valor “SOAP” en la propiedad “Options/Call Protocol”. Nos referiremos en
adelante a dichos objetos como “Servidores” o “Servicios Web”. Solo pueden ser reportes o
procedimientos, sin ningún tipo de interfaz con el usuario.

Se requiere un servidor Web que haga el hosting de los servicios a ser invocados.
Los programas Servidores reciben la invocación http, procesan el mensaje SOAP que envía el Cliente
con sus parámetros, realizan la acción requerida, y generan otro mensaje SOAP de respuesta
(eventualmente con los parámetros modificados).
Cliente

Los objetos que van a invocar al servicio Web, a los que llamaremos “Clientes”, pueden ser cualquier objeto
GeneXus. La invocación se hace con el comando call() de GeneXus.

Los programas Clientes realizan las tareas necesarias para ensamblar el mensaje SOAP, hacer la invocación
http, y desensamblar la respuesta, obteniendo los parámetros modificados en forma automática. Todo esto
se realiza en forma automática y transparente para el usuario.

Locations

Para indicar cual va a ser la ubicación de los servicios invocados se utiliza un esquema conocido
como Locations.

Manejo de errores

COMPORTAMIENTO FRENTE A UN ERROR


Si al hacer un llamado SOAP desde un objeto GeneXus se produce un error, normalmente la
ejecución del llamador se cancelará mostrando el error que ocurrió.

Si el objeto llamado es un procedimiento o reporte GeneXus, es posible indicar que se detenga la


ejecución de los programas llamadores en caso de fallar la llamada. Esto se hace mediante la
propiedad “Cancel Caller Execution on Error”:
Esta propiedad se habilita solamente cuando la propiedad “Call Protocol” tiene el valor “SOAP”. El
valor por defecto es “Yes”. De tener valor “No”, la ejecución no se cancelará y se podrá obtener el
código numérico de error con la función GetSOAPErr(), y el mensaje de error mediante la función
GetSOAPErrMsg().

CÓDIGOS DE ERROR EN EL CLIENTE


Los posibles códigos de error que pueden ser retornados mediante la función GetSOAPErr() son los
siguientes:

 0: Operación completada con éxito.

 Mayor que 0 y menor que 10000: Algún parámetro retornado por el servidor no tiene el
nombre esperado. El código de error indica la posición del parámetro que ocasionó el
conflicto.

 Menor que 0 y mayor que -10000: Sucedió un error al interpretar el XML de respuesta.
Sucederá por lo general si la respuesta no es XML o no es XML bien formado. Si se toma el
valor absoluto del código de error el resultado corresponderá a un código de error del
objeto XMLReader. De todas formas, getSOAPErrMsg() retornará una descripción del error.
 Menor que -10000: Sucedió un error en la comunicación HTTP. Si se toma el valor absoluto
del código de error y se le resta 10000 el resultado corresponderá a un código de error del
objeto HTTPClient. De todas formas, getSOAPErrMsg() retornará una descripción del error.

 -20001: La respuesta recibida es un XML válido pero no es un mensaje SOAP válido.

 -20004: El servidor retornó que hay un error en el pedido SOAP realizado por el cliente. En
este caso getSOAPErrMsg() retornará un mensaje conteniendo el código y el mensaje de
error retornados por el servidor. Si el servidor es un procedimiento o reporte GeneXus,
retornará alguno de los códigos de error descriptos más abajo.

 -20006: Sucedió un error no identificado. En este caso getSOAPErrMsg() retornará un


mensaje conteniendo el código y el mensaje de error retornados por el servidor.

 -20007: Nombre de location no válido. Sucede cuando se llama a la función


GetLocation(Nombre) con un nombre de location que no está definido para ningún objeto
en la base de conocimiento.

CÓDIGOS DE ERROR EN EL SERVIDOR


Un procedimiento o reporte GeneXus que es llamado mediante SOAP puede retornar alguno de los
siguientes códigos de error:

 -20000: No se recibió un mensaje SOAP.

 -20001: El mensaje recibido es un XML válido pero no es un mensaje SOAP válido (igual que
en el cliente).

 -20002: El método llamado no es el esperado. (El método SOAP de los objetos GeneXus
siempre se llama “Execute”).

CONSUMIDORES A WEB SERVICES EXTERNOS


El WSDL Inspector permite importar la definición del servicio que se desea consumir. Por más
detalles ver WSDL Inspector.
Web Services con GeneXus

A continuación se detallan los mecanismos para proveer y consumir Web Services con GeneXus.

Proveer

Para proveer Web Services con GeneXus se debe definir un objeto Procedimiento o Reporte, que
debe ser de tipo main, y asociado a un generador Web.

Se debe configurar la propiedad de objeto “Call protocol” con el valor “SOAP”.

Se debe publicar el objeto en un servidor Web, con lo que el Web Service queda operativo para ser
invocado.

El WSDL del servicio queda disponible agregando el parámetro wsdl a la URL del mismo. Por
ejemplo:

http://server/baseurl/aservice.aspx?wsdl

Consumir

Se utiliza el WSDL Inspector, que permite importar la definición del servicio que se desea consumir.
Se debe indicar el WSDL del mismo, y el utilitario definirá los tipos de datos necesarios para poder
consumirlo desde GeneXus.

En el caso de que el Web Service utilice tipos de datos estructurados, los mismos serán agregados a
la base de conocimiento al importar la definición con el WSDL Inspector.

Además, es necesario configurar la propiedad de objeto Location. Esto servirá luego para configurar,
en los objetos GeneXus que vayan a invocar al Web Service, la ubicación del mismo (host, port, etc.).
Práctico: Creación de Web Service Genexus

En esta sección crearemos un Web Service GeneXus, y veremos como consumirlo desde una
aplicación GeneXus.

Supongamos que quisiéramos publicar un servicio de nuestro sitio Web, por ejemplo un ranking con
los 10 destinos más elegidos.

Vamos a definir entonces un Web Service al que llamaremos “Ranking”.

Lo primero es definir un SDT con las siguientes características, que nos permita almacenar la
información de los destinos que nos interesa publicar:

Nombre: Destinationsdt

Structure Type

CountryId Identifier

CountryName Character(20)

CityId Identifier

CityName Character(20)

Destinationsdt será una Collection.

Para programar el procedimiento “Ranking” se recorre la tabla COUNTRIES1 en forma descendente


por CityQtity, que indica para una ciudad de un país en particular, qué cantidad de veces que ha sido
elegida en vuelos que la tienen como ciudad destino. De esa forma, obtendremos las 10 más
elegidas.

Definiremos una variable que nos permita contar la cantidad de ciudades: &Qty, más una variable
que permita almacenar toda la colección de destinos más elegidos (Destination) junto con una
variable que cargue cada uno de los items de esa colección de destinos (DestinationItem).
Las variables a definir entonces son las siguientes:

Name Type

Qty N(2)

Destination S(Destinationsdt)

DestinationItem S(Destinationsdt.DestinationsdtItem)

&Qty = 1

for each (CityQtity)

&DestinationItem.CityId = CityId

&DestinationItem.CityName = CityName

&DestinationItem.CountryId = CountryId

&DestinationItem.CountryName = CountryName

&Destination.Add(&DestinationItem)

&DestinationItem = new Destinationsdt.DestinationsdtItem()

&Qty +=1

if &Qty > 10

exit

endif

endfor

Rules:

parm(out:&Destination);

Resulta necesario que el procedimiento sea main, y configurar la propiedad “Call protocol” con el
valor “SOAP”.
Luego de generar y compilar el procedimiento Ranking, verifique el Web Service generado
automáticamente por GeneXus, digitando la siguiente URL en el browser:

http://localhost/practico/aranking.aspx?wsdl

Creación del Consumidor del Web Service

A continuación crearemos un Web Panel que será el consumidor del Web Service “Ranking”
recientemente creado.

En general un Web Service será externo a la base de conocimiento, por lo cual vamos a crear una
nueva base de conocimiento para crear ese Web Panel al que llamaremos ViewRanking. Como se
describe a continuación.

1. Creación de una nueva base de conocimiento, de nombre “Consumer”.

2. Desde diseño, ejecutar el WSDL Inspector: Tools / WSDL Inspector.

En “Web service URL” colocar la siguiente URL


http://localhost/practico/aranking.aspx?wsdl y luego hacer clic en el botón
“Inspect”·

Observe que el método del Web Service es “Execute” y el tipo de datos que
devuelve es “Destinationsdt”.

Cuando se hace clic en el botón “Add Reference” se definen los tipos de datos
además de toda la información necesaria para poder consumir el Web Service.

Pasar a prototipo forzando el impacto.

3. Creación del Web Panel ViewRanking, para eso definiremos las siguientes
variables:
Name Type

CityId Character(3)

CityName Character(20)

CountryId Character(3)

CountryName Character(20)

Destination S(Destinationsdt)

DestinationItem S(Destinationsdt_DestinationsdtItem)

Rank O(org_tempuriaction_.Ranking)

Observe que los tipos de datos Destinationsdt (colección de destinos),


Destinationsdt_DestinationsdtItem (cada item de la colección) y
org_tempuriaction_.Ranking (Web Service) se crearon automáticamente al inspeccionar el
servicio con el WSDL Inspector.

El form del Web Panel ViewRanking contendrá un grid con las variables &CityId, &CityName,
&CountryId y &CountryName. Y se deberá programar los eventos Refresh y Load del Web
Panel, como se muestra a continuación:

Event Refresh

&Destination = &Rank.Execute() //aquí se invoca la ejecución del Web Service y se


carga la colección en la variable &Destination

EndEvent // Refresh

Event Grid1.Load

for &DestinationItem in &Destination //se recorre la colección y se carga el grid

&CityId = &DestinationItem.CityId

&CityName = &DestinationItem.CityName

&CountryId = &DestinationItem.CountryId

&CountryName = &DestinationItem.CountryName

load
endfor

EndEvent // Grid1.Load

Ejecute el Web Panel ViewRanking y observe como se obtiene la información requerida.

Demo: Cómo consumir un Web Service externo

Una de las características interesantes de los Web Services, es que podemos agregar valor a nuestro
sitio Web, sin necesidad que el usuario deba ir a otro sitio. Es importante evitar “perder” el usuario
al llevarlo a otras páginas Web.

Lo que queremos ver en esta sección es como incluir un Web Service externo no GeneXus en nuestra
aplicación (ya hemos visto en este capítulo un ejemplo de como crear y consumir un Web Service
hecho con GeneXus).

Lo que haremos es importar un Web Service que provée Google. Google es una compañía
especializada en la búsqueda de información en la Web. En su página Web (http://www.google.com)
se puede ingresar una lista de palabras por las cuales buscar y retorna todos los sitios Web en las
cuales encontró esas palabras. Esta misma funcionalidad Google la provee por medio de un Web
Service.

El WSDL de dicho Web Service es: http://api.google.com/GoogleSearch.wsdl

El WSDL Inspector permite a partir del WSDL de un Web Service definir los tipos de datos necesarios
en GeneXus para poder consumir el Web Service en forma transparente, sin tener que preocuparse
de los protocolos involucrados en el proceso y la definición del mismo.

Entonces, el procedimiento a seguir para incluir el Web Service de Google en el sitio Travel Agency
es el siguiente:

1. Ejecutar el WSDL Inspector (Tools / WSDL Inspector en el modelo de diseño).

2. En “Web Service URL” ingresar: http://api.google.com/GoogleSearch.wsdl

3. Presionar el botón “Inspect”.


Notar que el WSDL Inspector determinó que el Web Service tiene los siguientes
métodos: doGetCachedPage, doSpellingSuggestion y doGoogleSearch (este último es el
que luego vamos a consumir).

Notar en el costado inferior izquierdo los tipos de datos complejos que va a crear
GeneXus para consumir el Web Service en forma adecuada.

4. Presionar el botón “Add Reference” para que GeneXus cree en la base de conocimiento
todo lo necesario para consumir el Web Service.

5. Cerrar el WSDL Inspector.

6. Impactar el modelo de diseño.

Haga clic aquí para ver la demostración

A continuación es necesario consolidar el “GoogleSearch.xpz”, que contiene el Web Panel


GoogleSearch donde vamos a consumir el Web Service de Google.

En ese Web Panel, crear las siguientes variables:

Nombre Tipo

Ws GoogleSearch.GoogleSearchService

Return GoogleSearchResult

ResultElements ResultElementArray

ResultElement ResultElement

Ya están definidas en el xpz el resto de las variables necesarias para hacer el ejercicio.
Luego, debemos programar el evento search.click de la siguiente forma:

Event search.click

&Key = "3yHXpPZQFHKdexiyPjqTPYNqVvnYj8cZ"

&MaxResult = 10

&Filter = 1

&SafeSearch = 1

&Return=
&Ws.doGoogleSearch(&Key,trim(&Query),&Start,&MaxResult,&Filter,&Restrict,&Safesearch,&Lr,&
Ie,&Oe)

&ResultElements = &Return.resultElements

&searchTime = &return.searchTime

EndEvent

En este evento se realiza la invocación al método doGoogleSearch del Web Service. Los resultados
son devueltos en una Collection de un tipo de datos estructurado, el que es definido
automáticamente en GeneXus por el WSDL Inspector.

Programar el evento Load del grid de la siguiente forma:

Event Grid1.Load

For &ResultElement in &ResultElements

Title.Caption = &ResultElement.title

&url = &resultElement.URL

Title.LinkTarget = "_BLANK"

Title.Link = link(&ResultElement.URL)

&Summary = &ResultElement.snippet

&cachedsize = &resultelement.cachedSize

grid1.Load()
Endfor

EndEvent

En este evento se recorre la Collection con los resultados devueltos por el Web Service y se realiza la
carga del grid.

Haga clic aquí para ver la demostración

Especificar, generar, compilar y ejecutar el Web Panel GoogleSearch.

Haga clic aquí para ver la ejecución

Nota: La especificación del Web Service del ejemplo, se puede leer de:
http://www.google.com/apis/reference.html

Debug de una llamada SOAP

Introducción

Cuando se produce un error al realizar una llamada SOAP desde GeneXus, es bastante difícil en
ocasiones saber donde se encuentra el problema. Es necesario contar con alguna forma de poder
efectuar un debug.
En este documento se presentan una serie de pasos para verificar cuando se produce una situación
de este tipo, así como también se detalla el uso de un utilitario de libre distribución que puede
resultar de utilidad.

Se recomienda la lectura previa de los documentos Protocolo SOAP y Locations.

Aunque este documento está orientado específicamente a las llamadas SOAP, también aplica en
forma general a la detección de problemas utilizando los tipos de datos HTTP.

Descripción

Cuando se produce un error en una llamada SOAP, es conveniente verificar ciertos puntos en el
siguiente orden:

1) Verificar que el servicio esté funcionando

Una causa obvia del fallo puede ser el hecho de que el Web Service al que se está invocando no esté
operativo, ya sea porque el servidor está caído u otras causas.

Para verificar esto se puede invocar al archivo WSDL, en el caso de que el Web Service haya sido
desarrollado con GeneXus, se deberá llamar a la siguiente URL en un browser:

http://servidor:port/url_base/servicio?wsdl

Por ejemplo, para invocar al servicio que devuelve la Edición de las noticias de ARTECH, sería:

http://www.gxtechnical.com/cgi-bin/adevedicion.exe?wsdl

Deberá visualizarse un archivo XML válido y no un error HTTP . Por ejemplo algo como:

<?xml version="1.0" encoding="iso-8859-1" ?>


- <definitions name="DevEdicion" targetNamespace="http://www.gxtechnical.com/cgi-
bin/adevedicion.exe?wsdl" xmlns:wsdlns="http://www.gxtechnical.com/cgi-
bin/adevedicion.exe?wsdl" xmlns:typens="http://www.gxtechnical.com/cgi-
bin/adevedicion.exe?type" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/">

- <types>

<schema targetNamespace="http://www.gxtechnical.com/cgi-
bin/adevedicion.exe?type" xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
elementFormDefault="qualified" />

</types>

- <message name="DevEdicion.Execute">

<part name="Ediid" type="xsd:integer" />

<part name="Idioid" type="xsd:string" />

</message>

.
2) Verificar que la llamada se hace a la URL correcta

Otro punto a verificar es que la URL a la que se está invocando sea la correcta.

Podría suceder que el archivo LOCATION.XML no estuviera en el directorio correcto en tiempo de


generación o ejecución (en caso de que se configurara la llamada mediante archivo), o que las
propiedades de la variable de tipo Location tuvieran valores incorrectos (en caso de que la
configuración se hiciera mediante código en tiempo de ejecución).

Entonces se deben verificar los valores de dichas propiedades, para lo cual se deberá definir una
variable de tipo Location (en caso de que no existir) y asignarla al location del objeto llamado,
utilizando la función GetLocation(). Se pueden entonces evaluar las propiedades, asignándolas por
ejemplo a variables que se despliegan por pantalla. Algo similar a:

.
&Loc = GetLocation(“<Nombre_location>”)

&Host = &Loc.Host

&Port = &Loc.Port

&URLBase = &Loc.BaseUrl

call(PMiServicio,......)

Otro valor a considerar es la extensión agregada al nombre del objeto, esto dependerá del
generador asociado al main correspondiente.

Para tener la seguridad de que la invocación se está realizando con la extensión correcta, remitirse al
punto 4.

3) Obtener la descripción del error


La descripción del error también nos da una pista del problema la mayoría de las veces. Es posible
obtener el código y descripción del error utilizando las funciones GetSOAPErr() y GetSOAPErrMsg(),
invocándolas luego del call(). Combinándolo con el ejemplo del punto anterior, quedaría:

.
&Loc = GetLocation(“<Nombre_location>”)

&Host = &Loc.Host

&Port = &Loc.Port

&URLBase = &Loc.BaseUrl

call(PMiServicio,......)

&ErrCode = GetSoapErr()

&ErrCodeDsc = GetSoapErrMsg()

4) Analizar el Request y el Response HTTP

Si los puntos anteriores no nos llevaron a la solución del problema, es conveniente verificar el
Request y el Response HTTP que se generan. Existen varias herramientas con las que se puede hacer
esto, en particular mostraremos tcpTrace, un utilitario de libre distribución que puede obtenerse en
http://www.pocketsoap.com/tcptrace/. El mismo no necesita instalación, es solamente un
ejecutable.

Al ejecutar el archivo tcpTrace.exe se presenta el siguiente diálogo:


Se deberá completar lo siguiente:

Local Port # - un número cualquiera de puerto local, por ej. 8085

Destination Server - el servidor destino

Destination Port # - el Puerto del servidor destino (por defecto es 80).

Luego clickear OK.

A continuación se deberá ejecutar la llamada SOAP, modificando previamente los parámetros de la


misma para que se realice al servidor localhost y al puerto especificado en Local Port #. Esto se
deberá realizar ya sea modificando el archivo LOCATION.XML o bien modificando las propiedades de
la variable de tipo Location (dependiendo del modo de configuración utilizado).

Al efectuar la llamada, en la ventana del tcpTrace se visualizará:


En la ventana de la izquierda aparecerá una línea por cada llamada. Al hacer clic sobre una línea, en
las ventanas de la derecha se mostrarán el Request y el Response HTTP para la llamada
correspondiente.

Mirando el header del Request se puede verificar que la URL base y la extensión que se están
generando sean correctas. El body (lo que esta después de la línea que comienza con Content-
lenght) es el mensaje SOAP de la llamada, debe ser un XML bien formado.

En la ventana inferior derecha se ve el Response del Web Service. Si se devolvió algún error HTTP, el
mismo se puede visualizar en el header del mismo, y en el body se muestra alguna descripción. En el
caso de que el servicio finalizó en forma exitosa, se devuelve un código 200, y en el body aparece el
Response SOAP (a partir de la línea en blanco posterior al header). El mismo también deberá ser un
XML bien formado (para verificar esto se puede copiar y pegar el contenido, salvarlo como un
archivo con extensión XML, y abrirlo con un browser).

WSDL Inspector

Introducción

El WSDL Inspector permite a partir del WSDL de un Web Service definir los tipos de datos necesarios
en GeneXus para poder consumir el Web Service en forma transparente sin tener que preocuparse
de los protocolos involucrados en el proceso y la definición del mismo.

Descripción

El WSDL de un Web Service es un archivo que describe al mismo; brinda toda la información
necesaria para poder consumirlo.

GeneXus brinda una herramienta llamada WSDL Inspector que permite a partir del WSDL de un Web
Service definir en la base de conocimientos todo lo necesario para poder consumir los métodos del
Web Service en forma transparente.

Para acceder al WSDL Inspector hay que ejecutar la opción Tools / WSDL Inspector. La misma está
solamente accesible desde Design.
En “Web Service URL” se debe ingresar el camino hacia el WSDL. Puede ser referenciado por medio
del protocolo http (por ej. http://api.google.com/GoogleSearch.wsdl ) o file (por ejemplo:
file:C:\Servicios\AmazonWebServices.wsdl).

Una vez ingresado el camino del WSDL se debe presionar el botón “Inspect”, con lo cual en caso de
no existir ningún error se mostrará la información de los distintos métodos que brinda el Web
Service, junto con los tipos de datos necesarios para poder consumirlos.

Para poder “importar” la información necesaria dentro de la base de conocimiento que permita
consumir el Web Service se debe presionar el botón “Add Reference”.

En la imagen anterior se muestra la información de un Web Service simple, el cual cuenta con un
solo método llamado BabelFish que recibe dos parámetros de entrada de tipo Character y retorna
otro parámetro de tipo Character.

El siguiente ejemplo muestra otro caso en el cual el Web Service cuenta con más de un método y se
necesita definir nuevos tipos de datos (ArrayOfNewsCategoty, NewsCategoty,
ArrayOfBusnessShortNews, BusnessShortNews):
Add Reference

Como se mencionó anteriormente al presionar el botón “Add Reference” se genera dentro de la


base de conocimiento los tipos de datos necesarios para poder consumir el Web Service en forma
transparente. O sea, se genera un tipo de datos que identifica el Web Service y en caso de que el
mismo necesite nuevos tipos de datos se genera un tipo de datos estructurado para cada uno de
ellos.

De esta forma se puede definir una variable a la cual asignarle el tipo de datos definido para el Web
Service y utilizando los métodos de la misma poder invocar a los distintos métodos que el Web
Service provee. Si para consumir el método se necesitan tipos de datos estructurados hay que crear
variables con los tipos de datos estructurados creados por el Inspector.

Invocación de los métodos de un Web Service

MÉTODO SIN TIPOS DE DATOS ESTRUCTURADO


Volvamos entonces a la primera imagen para poder mostrar en un caso sencillo como poder
consumir un Web Service.
En este caso al presionar el botón “Add Referente” se agrega a los tipos de datos que maneja
GeneXus, el tipo “net_xmethods_wwwsd_BabelFishService.BabelFishService”. (Notar que en el
nombre asignado al tipo de datos está precedido por el namespace que identifica al Web Service, de
esta forma GeneXus asegura que no van a existir dos tipos de datos con el mismo nombre para
distintos Web Services).

De esa forma se puede definir una variable a la cual asignarle ese tipo de datos; llamaremos a la
misma “ws”.

Luego podremos invocar utilizando la variable “ws” a cualquiera de los métodos que el Web Service
provee (en este caso solo uno) de la siguiente forma:

&result = &ws.BabelFish(&traslationmode, &source)

Donde &result, &traslationmode y &source son variables de tipo character.

Eso es todo!, de esta forma se puede invocar a un Web Service en forma sencilla sin tener que
preocuparse de los protocolos involucrados en el proceso y la definición del mismo; solamente se
tuvo que dar la ubicación de su WSDL y GeneXus se encargó de esconder la complejidad y definir un
tipo de datos que represente al Web Service.
MÉTODO CON TIPO DE DATOS ESTRUCTURADO
Ahora vamos a consumir un Web Service que utiliza dos tipos de datos estructurados.

Al importar el Web Service en GeneXus se crea lo siguiente:

 Un nuevo tipo de datos correspondiente al Web Service

(com_swanandmokashi.Horoscope)

 Un tipo de dato estructurado llamado ZodiacSigns con la siguiente definición:

ZodiacSign Character(9999)

DailyForecast Character(9999)

 Un tipo de dato estructurado llamado ArrayOfZodiacSigns con la siguiente


definición:

ArrayOfZodicSigns collection of ZodiacSigns

Para consumir el Web Service se tiene el siguiente código:

&array = &ws.GetHoroscope()

For &item in &array

&SodiacSign = &item.ZodiacSign

&ForeDailiy = &item.DailyForecast

load

endfor

Donde:

&ws es de tipo com_swanandmokashi.Horoscope

&array es de tipo ArrayOfZodicSigns

&item es de tipo ZodiacSigns

De esta forma se consume un Web Service que usa tipos de datos estructurados.
Nota: En el caso de tipos de datos booleanos, se debe utilizar el tipo de datos numérico N(1). El valor
1 se corresponde con el True, y el 0 con el False.

Uso de Locations en el consumo de Web Services

De la misma forma que con el llamado de los procedimientos SOAP, es posible modificar diferentes
parámetros de la invocación de Web Services utilizando los locations.

El nombre del location (indicado en el tag <GXLocation name=> del archivo location.xml, que debe
utilizarse es el nombre que GeneXus le asigna al tipo de datos creado por el WSDL Inspector para el
servicio, sustituyendo el último punto (.) por un underscore (_).

Por ejemplo, en el caso del Web Service de Horóscopo anterior, en GeneXus el tipo de datos para el
servicio muestra:

com_swanandmokashi.Horoscope

El location que se debe utilizar en este caso es:

com_swanandmokashi_Horoscope

El archivo location.xml debe de estar en el directorio corriente y sólo se toma en cuenta en tiempo
de ejecución.

Por ejemplo si se quiere redireccionar el Web Service a localhost:88 se tiene que tener un
location.xml de la siguiente forma:

<GXLocations>

<GXLocation name="com_swanandmokashi_Horoscope">

<Common>

<Host>localhost</Host>

<Port>88</Port>
</Common>

<HTTP>

<BaseURL>/HomePage/WebServices/</BaseURL>

</HTTP>

</GXLocation>

</GXLocations>

Ejemplo

En GXOpen se encuentra una base de conocimiento de ejemplo en la cual se consumen tres Web
Services; GXChart (servidor de gráficas), Babelfish (traductor de textos) y GetJoke (provee chistes
agrupados por categorías).

El mismo puede ser obtenido en http://www.gxopen.com/main/hproject.aspx?176

Consideraciones

Para consolidar objetos que tengan variables de tipos de datos asociados a Web Services, es
necesario previamente agregar la referencia con el WSDL Inspector en la base de conocimiento
destino. Otra opción es copiar los archivos asociados al Web Service desde el directorio
<dir.KB>\kbdata\usrtypes de la base de conocimiento origen a la destino (se generan dos archivos
con extensiones .ari y .xml por cada Web Service agregado, que contienen las definiciones del
mismo). Además, luego de consolidarlo, es necesario en el objeto borrar y volver a definir la/s
variable/s de ese tipo, de lo contrario se producirá un error de especificación:

spc0056, Internal error. Variable <variable> definition is incorrect or not available.


Data:<tipo>.

Cuando se compila un objeto main se compilan todos los tipos de datos definidos en lugar de
compilar solamente los usados por ese main.
Locations

Introducción

Se busca permitir configurar las invocaciones a objetos main GeneXus en forma remota, cuando se
utilizan diferentes protocolos, por ej. llamadas vía SOAP. Dichas configuraciones se pueden hacer tanto usando el
tipo de datos Location de GeneXus como el archivo location.xml.

Alcance

Aplica a los siguientes objetos: Transacciones, Work Panels, Web Panels, Reportes, Procedimientos.
Para los siguientes generadores: .NET, Java, Visual Basic y Visual FoxPro.

Descripción

Cada programa main de GeneXus tiene asignado un location. Éste es un nombre lógico al que se le
hace corresponder una ubicación válida para el caso de que el objeto sea invocado, según el
protocolo que se utilice.

Necesitamos entonces describir las características de este location, para lo que se utiliza el siguiente
esquema:

En primer lugar, se asigna al objeto a ser invocado un nombre lógico, configurando el mismo en la
propiedad Location de dicho objeto.

Será necesario entonces poder configurar los locations, según los diferentes protocolos que se
utilicen para la invocación del objeto. Existen tres instancias posibles para realizar esto:

1) En tiempo de generación.

Mediante el archivo location.xml, ubicado en el directorio raíz de la base de


conocimiento y cuya estructura es descripta más abajo. Este archivo debe ser creado
por el usuario GeneXus.

2) En tiempo de ejecución, mediante un archivo.

Mediante el archivo location.xml, ubicado en el directorio corriente durante la


ejecución del programa que invoca al main, cuya estructura coincide con el archivo
del mismo nombre descripto en la instancia anterior. Este archivo debe ser creado o
editado por el usuario GeneXus.
3) En tiempo de ejecución, mediante código.

Mediante variables de tipo Location, cuya estructura es descripta más abajo.

Es decir que las propiedades especificadas en tiempo de ejecución mediante código tendrán
preferencia sobre las especificadas en tiempo de ejecución mediante un archivo y éstas a su vez
tendrán preferencia sobre las especificadas en tiempo de generación para permitir mayor
dinamismo en la configuración de los locations.
Propiedades

Se describen a continuación las propiedades disponibles para describir el location en el archivo XML:

Propiedad Elemento XML Subelemento Tipo Protocolo


XML

Host Host Character HTTP

Port Port Numeric HTTP

BaseURL BaseURL Character HTTP

Secure Secure Numeric HTTP


(0|1)

Timeout Timeout Numeric HTTP

Authentication Authentication Numeric HTTP


(0|1)

AuthenticationMethod Authentication Method Numeric HTTP

AuthenticationRealm Authentication Realm Character HTTP

AuthenticationUser Authentication User Character HTTP

AuthenticationPassword Authentication Password Character HTTP

HOST
Especifica la dirección del servidor correspondiente al location.

El valor por defecto es “localhost”.

Ejemplo por código

&Location.Host = “www.soaplocation.com”

Ejemplo en XML

<Host>www.soaplocation.com</Host>
PORT
Especifica el puerto en el servidor correspondiente al location.

El valor por defecto es 80.

Ejemplo por código

&Location.Port = 8080

Ejemplo en XML

<Port>8080</Port>

BASEURL
Especifica la URL base del location, en caso de utilizar el protocolo HTTP. La URL final tiene la forma
http://Host:Port/BaseUrl/pgmname. Si se necesitan varias BaseUrls sobre el mismo servidor se
deberá definir un location para cada una.

El valor por defecto es “/”.

Ejemplo por código

&Location.BaseURL = “/mydirectory/soap/”

Ejemplo en XML

<BaseURL>/mydirectory/soap/</BaseURL>
SECURE
Especifica si los llamados al location se harán mediante un protocolo seguro o no, en caso de utilizar
el protocolo HTTP. Si esta propiedad tiene el valor 1 se utilizará el procolo HTTPS.

El valor por defecto es 0.

Ejemplo por código

&Location.Secure = 1

Ejemplo en XML

<Secure>1</Secure>

TIMEOUT
Especifica el tiempo, en segundos, a esperar por una respuesta del servidor. Si el valor es 0, la espera
es indefinida.

El valor por defecto es 0.

Ejemplo por código

&Location.Timeout = 1

Ejemplo en XML

<Timeout>1</Timeout>

AUTHENTICATION
Especifica si se utilizará autentificación con el servidor o no.

El valor por defecto es 0.


En XML se especifican las propiedades de la autentificación dentro del elemento <Authentication> y
por lo tanto no se especifica valor para este elemento. La simple mención del elemento
<Authentication> indica que esta propiedad tendrá valor 1.

Ejemplo por código

&Location.Authentication = 1

Ejemplo en XML

<Authentication/>

AUTHENTICATIONMETHOD
Especifica el método de autentificación con el servidor, en caso de utilizarla. Los posibles valores son
los mismos que en el objeto HTTPClient.

El valor por defecto es 0.

Ejemplo por código

&Location.AuthenticationMethod = 1

Ejemplo en XML

<Authentication>

<Method>1</Method>

</Authentication>
AUTHENTICATIONREALM
Especifica el realm para la autentificación con el servidor, en caso de utilizarla.

El valor por defecto es “”.

Ejemplo por código

&Location.AuthenticationRealm = “MyRealm”

Ejemplo en XML

<Authentication>

<Realm>MyRealm</Realm>

</Authentication>

AUTHENTICATIONUSER
Especifica el nombre de usuario para la autentificación con el servidor, en caso de utilizarla.

El valor por defecto es “”.

Ejemplo por código

&Location.AuthenticationUser = “Name”

Ejemplo en XML

<Authentication>

<User>Name</User>

</Authentication>

AUTHENTICATIONPASSWORD
Especifica la contraseña para la autentificación con el servidor, en caso de utilizarla.
El valor por defecto es “”.

Ejemplo por código

&Location.AuthenticationPassword = “MyPassword”

Ejemplo en XML

<Authentication>

<Password>MyPassword</Password>

</Authentication>

Formato del archivo XML

El archivo location.xml utilizado para describir los locations empleados en la base de conocimiento
debe tener el siguiente formato:

<GXLocations>

<GXLocation name=”NombreDelLocation”>

<Common>

Propiedades

</Common>

<Protocolo>

Propiedades

</Protocolo>

<Protocolo>

Propiedades

</Protocolo>

.
.

<Protocolo>

Propiedades

</Protocolo>

</GXLocation>

</GXLocations>

Las propiedades en el elemento Common aplican a todos los protocolos. Las propiedades
especificadas en un protocolo en particular tendrán prioridad sobre estas.

En esta versión, el único protocolo soportado es HTTP.

Obtención de locations en tiempo de ejecución

Para poder modificar las propiedades de un location en tiempo de ejecución es necesario definir una
variable de tipo Location y asignarle alguna de las locations existentes. Esto se puede hacer con la
función getLocation( LocationName) que toma como parámetro una cadena con el nombre de algún
location existente y devuelve un tipo Location.

Por ejemplo si definimos la variable &Loc de tipo Location y tenemos algún procedmiento con la
propiedad location en “MyLocation”, podemos ejecutar &Loc = getLocation( “MyLocation”) y luego
modificar sus propiedades. Las modificaciones así realizadas son globales. En cualquier momento
posterior en que se haga un llamado a un procedimiento en dicho location se tendrán en cuenta las
últimas propiedades asignadas.

Ejemplo de archivo location.xml

<GXLocations>

<GXLocation name=”Location1”>

<Common>

<Host>www.soapserver1.com</Host>

<BaseURL>/soap/services/</BaseURL>

<Timeout>30</Timeout>
</Common>

</GXLocation>

<GXLocation name=”Location2”>

<Common>

<Host>www.soapserver2.com</Host>

<Port>80</Port>

</Common>

<HTTP>

<BaseURL>/webservices/</BaseURL>

<Port>8080</Port>

<Secure>1</Secure>

<Authentication>

<User>UserName</User>

<Password>Password</Password>

</Authentication>

</HTTP>

</GXLocation>

</GXLocations>

Con este archivo location.xml (usado tanto en tiempo de generación como en tiempo de ejecución),
los locations Location1 y Location2 tendrán las siguientes propiedades:

Propiedad Location1 Location2

Host www.soapserver1.com www.soapserver2.com

Port 80 8080

BaseURL /soap/services/ /webservices/

Secure 0 1
Timeout 30 0

Authentication 0 1

AuthenticationMethod 0 0

AuthenticationRealm (vacío) (vacío)

AuthenticationUser (vacío) UserName

AuthenticationPassword (vacío) Password

Tipo de Datos XMLWriter

Introducción

El objetivo del tipo de datos XMLWriter es proveer la posibilidad de grabar archivos XML de un modo
más sencillo que las funciones incluidas en versiones anteriores. El documento XML contiene una
introducción a dicho lenguaje.

Se recomienda leer también el documento XMLReader.

Alcance

Aplica a los siguientes objetos: Transacciones, Work Panels, Web Panels, Reportes, Procedimientos.
Para los generadores: .NET, Java, Visual Basic y Visual FoxPro.

Descripción

Para poder crear un archivo XML desde un objeto GeneXus, se debe definir una variable de un nuevo
tipo de datos denominado XmlWriter (xmlwrt) y luego invocar a los métodos necesarios para crear
los nodos que lo componen.

Métodos

MÉTODOS BÁSICOS

Open([FileName])

Permite crear un documento XML.


File Name es el nombre de archivo con el cual se va a crear el documento, si se omite, el
mismo se genera por “standard output”. En caso de ser un objeto Web se genera en el
response. (Funciona con CGI, ISAPI WebClasses y Servlets).

FileName – Character

OpenToString()

Permite crear un documento XML a un buffer inerno en lugar de a un archivo.

El contenido del buffer puede ser consultado por medio de la propiedad ResultingString.

WriteStartElement(<ElementName>)

Comienza un elemento compuesto. Este elemento puede tener subelementos, por lo que es
valido anidar llamadas a WriteStarElement/WriteElement.

<ElementName> - Character

WriteElement(<ValueName>, <ElementValue>)

Almacena un valor dentro del tag de nombre ValueName. En el caso de que


ElementValue sea de tipo Character, se sustituyen los caracteres especiales por
secuencias de caracteres (el '<' se sustituye por '&lt;', el '>' por '&gt;', etc.).

A diferencia del caso anterior este elemento no contiene subelementos.

<ValueName>- Character

<ElementValue>- Character

WriteText(<Value>)

Genera character data con el string <Value>. Se sustituyen los caracteres especiales
por secuencias de caracteres (el '<' se sustituye por '&lt;', el '>' por '&gt;', etc.).

<Value> - Character

WriteRawText(<Value>)

Genera cualquier texto sin sustituir los caracteres especiales por secuencias de
caracteres.
<Value> - Character

WriteAttribute(<AttriName>, <AttriValue>)

Asigna un atributo al último elemento. Es decir, al elemento que se creó con la última
invocación a WriteStartElement(<ElementName>) o WriteElement(<ValueName>,
<ElementValue>).

<AttriName> - Character

<AttriValue> - Character

WriteEndElement()

Cierra el último elemento abierto.

Close()

Cierra el documento.

OTROS MÉTODOS

WriteComment(<Comment>)

Escribe el comentario indicado en <Comment>.

Ejemplo:

WriteComment(‘Comentario’) genera lo siguiente:

<!— Comentario -->

<Comment> - Character

WriteEntityReference(<Entity>)

Escribe una referencia a la entidad <Entity>.

Ejemplo:

WriteEntityReference(‘Entidad’) genera lo siguiente:

&Entidad;

<Entity> - Character
WriteCData(<DataValue>)

Escribe una sección Cdata con el valor <DataValue>.

Si el contenido especificado para la sección Cdata contiene la secuencia de


caracteres ]]>, el mismo es fraccionado y se generan tantas secciones Cdata como
sean necesarias para obtener un documento XML bien formado.

Ejemplo:

WriteCData(‘Value’) genera lo siguiente:

<![CDATA[value]]>

<DataValue> - Character

WriteProcessingInstruction(<Action>, <Value>)

Escribe el registro del tipo processing instruction indicado por <Action> y <Value>.

Ejemplo:

WriteProcessingInstruction(‘play’, ‘sound = “Hello.wav”’) genera lo siguiente:

<? Play sound=”Hello.wav” ?>

<Action> - Character

<Value > - Character


WriteStartDocument([Encoding, [StandAlone]])

Escribe la declaración de XML usando la versión 1.0 y codificación ISO-8859-1.


Opcionalmente se puede indicar un entero (0/1) como valor booleano para usar en la
declaración standalone y un encoding.
Este método debe ser llamado al comienzo de la generación del documento (luego del
open() y antes de cualquier otro método).
Ejemplo:

WriteStartDocument() genera lo siguiente:

<?xml version=”1.0” enconding=”ISO-8859-1” ?>

Enconding - Character

StandAlone – Integer (0/1)

WriteDocType(<DocName> [,SubSet])

Escribe la declaración DOCTYPE del documento XML. Si se incluye un SubSet se ingresa


entre corchetes al final de la declaración.
Ejemplo:

WriteDocType(‘<book>’, ‘<!ENTITY ge “entity”>’) genera lo siguiente:

<!DOCTYPE <book> [<!ENTITY ge “entity”>]>

<DocName> - Character

SubSet – Character

WriteDocTypeSystem(<DocName>,<uri> [,SunSet])

Escribe la declaración DOCTYPE del documento XML con una declaración de tipo
SYSTEM. Si se incluye un SubSet se ingresa entre corchetes al final de la declaración.

Ejemplo:

WriteDocTypeSystem(‘<book>’, ‘file.dtd’) genera lo siguiente: <!DOCTYPE


<book> SYSTEM “file.dtd”>

<DocName> - Character

<uri> - Character

SubSet – Character

WriteDocTypePublic (<DocName>,<PubId>, <uri> [,SunSet])


Escribe la declaración DOCTYPE del documento XML con una declaración de tipo
PUBLIC. Si se incluye un SubSet se ingresa entre corchetes al final de la declaración.

Ejemplo:

WriteDocTypePublic(‘<book>’,‘Id’, ‘http://www.ser.com/dtd’) genera lo siguiente:


<!DOCTYPE <book> PUBLIC “Id” “http://www.ser.com/dtd”>

<DocName> - Character

<PubId> - Character

<uri> - Character

Subset - Character
PROPIEDADES
Indentation

Define cuantos caracteres se utilizan para indentar el código generado. Por defecto es 2.

IndentChar

Define el carácter que se utiliza para indentar el código generado. Por defecto se utiliza un
espacio en blanco.

ErrCode

Retorna un valor mayor que cero en caso de haber ocurrido un error durante la generación
del documento XML.

ErrDescription

Contiene la descripción del error ocurrido cuando ErrCode tiene un valor distinto de cero.

ResultingString

Permite consultar el valor del documento XML que se encuentra en un buffer interno
cuando el documento se creó a partir del método OpenToString().

El documento retornado puede ser incompleto si se invoca a la propiedad antes de la


ejecución del método close().

Soporte para Namespaces

En esta sección se describen las funcionalidades disponibles para generar documentos XML que
utilizan namespaces.

MÉTODOS
WriteNSStartElement(<LocalName> [,Prefix, NameSpaceURI])
Este método es análogo al WriteStartElement.
Si se indica un NameSpaceURI que no está en el ámbito de definición del elemento, o este
tiene un prefijo diferente del parámetro Prefrix, se crea automáticamente el atributo
xmlns:prefix=URI

<LocalName> - Character
Prefix - Character

NameSpaceURI - Character

WriteNSElement(<LocalName> [,NameSpaceURI [,Value]])


Este método es análogo al WriteElement.
El prefijo se determina automáticamente en base a los prefijos definidos en el ámbito del
elemento. Si ningún prefijo estuviera asociado al URI especificado, se define junto con el
elemento un namespace por defecto.
Ejemplo:
WriteNSElement(‘Precio’, ’20.5’, ‘http://www.genexus.com’) genera lo siguiente:
<prefijo:Precio>20.5</prefijo:Precio>
o
<Precio xmlns=” http://www.genexus.com”>20.5</Precio>

<LocalName> - Character

NameSpaceURI - Character

<Value > - Character

WriteAttribute(<LocalName>, <Value>)
Cuando se trabaja con documentos con name sapace, el método WriteAttribute tiene un
comportamiento especial para algunos atributos. Si el nombre del atributo es “xmlns” o
comienza con “xmlns:” se registra la definición del atributo como la definición de un
namespace.
De esta forma, en futuras invocaciones de un método WriteNSStartElement o
WriteNSElement puede determinarse el prefijo correspondiente a una determinada URI.

EJEMPLO DE SOPORTE DE NAMESPACES


El siguiente procedimiento genera el archivo ejemplo.xml

&writer.Open(‘ejemplo.xml’)

&writer.WriteNSStartElement(‘a’)

&writer.WriteAttribute(‘xmlns:p1’, ’http://www.artech.com’)

&writer.WriteAttribute(‘xmlns’, ‘http://defecto.com’)

&writer.WriteAttribute(‘att’, ‘a1’)

&writer.WriteNSElement(‘b’, ’http://www.artech.com’)

&writer.WriteAttribute(‘att’, ‘a1’)

&writer.WriteAttribute(‘p1:att2’, ‘a2’)

&writer.WriteNSElement(‘b’, ’http://www.genexus.com’)

&writer.WriteAttribute(‘xmlns:p1’,’http://www.genexus.com’)

&writer.WriteAttribute(‘xmlns:p2’,’http://www.artech.com/segundo’)

&writer.WriteAttribute(‘p2:att1’, ‘a1’)
&writer.WriteEndElement()

&writer.Close()

El archivo ejemplo.xml queda de la siguiente forma:

<a

xmlns:p1="http://www.artech.com"

xmlns="http://defecto.com"

att="a1">

<p1:b

att1="a1"

p1:att2="a2"

/>

<p1:b xmlns:p1="http://www.genexus.com"

xmlns:p2="http://www.artech.com/segundo"

p2:att1="a1"

/>

</a>

Ejemplo

El siguiente procedimiento genera un archivo llamado Reunion.xml que contiene datos de una
reunión, indicando que integrantes participaron de la misma, y cuales son las tareas de cada uno.

&filexml.open('Reunion.xml')

&filexml.WriteStartDocument()

&filexml.WriteStartElement('REUNION')

&filexml.WriteAttribute('Fecha', dtoc(ReuFch) )
&filexml.WriteElement('FECHA', dtoc(ReuFch) )

&filexml.WriteComment('Descrpción de la reunión')

&filexml.WriteCData(ReuDsc )

&filexml.WriteStartElement('INTEGRANTES')

for each

&filexml.WriteElement('INTEGRANTE', ReuPerNom )

endfor

&filexml.WriteEndElement()

&filexml.WriteStartElement('TAREAS')

for each

&filexml.WriteStartElement('TAREA')

&filexml.WriteElement('RESPONSABLE', ReuTarPerNom)

&filexml.WriteCData(ReuTarDsc )

&filexml.WriteEndElement()

endfor

&filexml.WriteEndElement()

&filexml.WriteEndElement()

&filexml.Close()
El archivo reunion.xml contiene:

<?xml version="1.0" encoding="ISO-8859-1" ?>

<REUNION Fecha="06/03/01">

<FECHA>06/03/01</FECHA>

<!-- Descrpción de la reunión-->

<![CDATA[ Reunion del equipo de desarrollo de la aplicación.

La reunión fue realizada el Viernes a las 9:30 horas.]]>


<INTEGRANTES>

<INTEGRANTE>Juan Pedro</INTEGRANTE>

<INTEGRANTE>Laura</INTEGRANTE>

<INTEGRANTE>Diego</INTEGRANTE>

<INTEGRANTE>Florinda</INTEGRANTE>

</INTEGRANTES>

<TAREAS>

<TAREA>

<RESPONSABLE>Juan Pedro</RESPONSABLE>

<![CDATA[ Realizar la documentción de la aplicación]]>

</TAREA>

<TAREA>

<RESPONSABLE>Florinda</RESPONSABLE>

<![CDATA[ Reunion con los clientes.]]>

</TAREA>

<TAREA>

<RESPONSABLE>Laura</RESPONSABLE>

<![CDATA[ Realizar el maunal de usuario]]>

</TAREA>

<TAREA>
<RESPONSABLE>Diego</RESPONSABLE>

<![CDATA[ Documentar las especificaciones.]]>

</TAREA>

</TAREAS>

</REUNION>

Tipo de Datos XMLReader

Introducción

El objetivo del tipo de datos XMLReader es proveer la posibilidad de leer el contenido de los archivos
XML. El documento XML contiene una introducción a dicho lenguaje.

Se recomienda leer también el documento XMLWriter.

Alcance

Aplica a los siguientes objetos: Transacciones, Work Panels, Web Panels, Reportes, Procedimientos.
Y para los siguientes generadores: .NET, Java, Visual Basic y Visual FoxPro.

Descripción

Para poder leer el contenido de un archivo XML desde un objeto GeneXus, se debe definir una
variable de un nuevo tipo de datos denominado XmlReader y luego invocar a los métodos y
propiedades necesarios para obtener la información de los nodos que lo componen.

La idea básica del funcionamiento es la siguiente: existe un método Read() que se comporta a
manera de cursor avanzando al siguiente nodo del archivo, luego utilizando ciertas propiedades
como por ejemplo Name y Value se puede obtener los datos del nodo, en este caso el nombre y el
valor del mismo. De esta forma utilizando el método Read() se “navega” a lo largo del documento en
forma secuencial obteniendo los distintos nodos del mismo.
Métodos

MÉTODOS BÁSICOS
Open(<FileName>)

Permite abrir un documento XML.

File Name es el nombre de un archivo XML o una URL con un archivo XML. Puede
usarse la propiedad ErrCode para consultar el éxito de la operación.

<FileName> – Character

OpenFromString(<DocXML>)

Permite abrir un documento XML contenido en un string.

<DocXML > – Character

Read()

Este método se utiliza para ir obteniendo en forma secuencial los distintos nodos del archivo
abierto. Invocando al mismo se avanza al siguiente nodo y retorna un valor entero mayor
que cero si se leyó un nodo y cero en caso contrario.

ReadType(<NodeTypeConstraint> [,NameConstraint])

Al igual que el método Read(), este método avanza al siguiente nodo pero que cumpla con
las restricciones indicadas y retorna un valor entero mayor que cero si se leyó un nodo y
cero en caso contrario.
La restricción <NodeTypeConstraint> especifica cuales son los tipos de nodos que
quiero leer. Se especifica indicando las constantes del tipo de nodo concatenadas
por medio del carácter “+”

Por ejmplo: <NodeTypeConstraint> = 1 + 4 (especifica el tipo Element y Text)

Si NameConstraint tiene un valor no nulo, especifica que valor debe de tener el


nombre del nodo que quiero leer, siempre y cuando el nodo sea de tipo Element o EndTag.

<NodeTypeConstraint> – Character
NameConstraint – Character

GetAttributeByIndex(<Index>)

Retorna el valor del atributo en la posición <Index> del nodo actual obtenido por el
método Read o ReadType.

Solo es válido para nodos de tipo Element.

Las posiciones se numeran desde 1.

<Index> – Integer
GetAttributeByName(<Name>)

Retorna el valor del atributo de nombre <Name >del nodo actual obtenido por el
método Read o ReadType.

Solo es válido para nodos de tipo Element.

<Name> – Character

ExistsAttribute(<Name>)

Retorna 1 si el atributo de nombre <Name> del nodo actual obtenido por el método Read o
ReadType existe y 0 en caso contrario.
Sólo es válido para nodos de tipo Element.

<Name> – Character

Close()

Cierra el documento.

OTROS MÉTODOS
SetDocEncoding (<Encoding>)

Permite establecer explícitamente la codificación de caracteres utilizada en el


documento. El valor indicado tiene precedencia sobre la propiedad encoding de la
declaración <?xml?> del documento.

Los valores posibles de <Enconding> son:

ANSI

US-ASCII

UTF-8

UTF-16

ISO-8859-1

<Enconding> - Character

SetNodeEncoding(<Encoding>)
Permite establecer la codificación de caracteres utilizada para los valores retornados por el
objeto XMLReader al programa GeneXus.
Los valores posibles de <Enconding> son:

ANSI

UTF-8

El valor por defecto es ANSI.

<Enconding> - Character

Skip()

Permite saltear un elemento completo con todos sus hijos.

Solo es válido para nodos de tipo Element.

ReadRawXML()

Permite obtener texto XML plano a partir del inicio de un elemento.

Solo es válido para nodos de tipo Element.


AddSchema(<URI>, [Namespace])(Solo .NET)

Indica que se va a utilizar el “schema” de la <URI> para validar el XML del [Namespace]
indicado.
Si no se indica [Namespace], se toma el del atributo targetNamespace del esquema.

Lo indicado en este método tiene prioridad sobre el atributo schemaLocation del


documento XML (en caso de que exista).

Para utilizar este método hay que indicar en la propiedad ValidationType que se
realice validación por esquema o automática.

<URI> – Character
Namespace – Character

Propiedades

PROPIEDADES BÁSICAS
Nodetype

Retorna el tipo de nodo actual obtenido por el método Read o ReadType.

Los valores posibles son:

1 - Element

2 - EndTag

4 - Text

8 - Comment

16 - WhiteSpace

32 - Cdata

64 - ProcessingInstruction

128 - DocumentType

ElementType
EndTagType
TextType
CommentType
WhiteSpaceType
CDataType
ProcessingInstructionType
DoctypeType

Estas propiedades contienen valores constantes que pueden utilizarse para comparar el resultado de
la propiedad NodeType o con el método ReadType.
Name

Retorna el nombre del nodo actual obtenido por el método Read o ReadType.

Solo es válido para nodos de tipo Element y EndTag.

Value

Retorna el valor del nodo actual obtenido por el método Read o ReadType.

Solo es válido para los nodos de tipo Text, Comment, ProcessingInstruction, DocumentType
y Element

IsSimple

Indica si el nodo actual obtenido por el método Read o ReadType responde a una estructura
del tipo <Elemento>Valor</Elemento>

AttributeCount

Retorna la cantidad de atributos que posee el nodo actual obtenido por el método Read o
ReadType.

Solo es válido para nodos de tipo Element.

EOF

Retorna si se alcanzo el final del docuemnto.

ErrCode

Retorna un valor mayor que cero en caso de haber ocurrido un error durante el
procesamiento de un documento XML.

ErrLineNumber; ErrLinePos

Retornan el numero de linea y posición dentro de la misma respectivamente en caso de que


ErrCode sea distinto de cero.
ErrDescription

Retorna la descripción del error en caso de que ErrCode sea distinto de cero.

OTRAS PROPIEDADES
ReadExternalEntities
Esta propiedad booleana(1/0) indica si deben leerse las entidades externas parseadas que
forman parte del documento XML que se esté procesando (esto incluye el subconjunto
externo del DTD). Si la lectura está habilitada, el objeto XMLReader leerá y procesará en
forma transparente para el usuario toda referencia a archivos o URLs externas que sean
incluidas por el documento. En caso contrario, las referencias a entidades externas son
ignoradas.

RemoveWhiteSpaces
Esta propiedad booleana(1/0) indica si deben eliminarse los espacios en blanco, tabuladores
y finales de línea del inicio y fin del valor de un nodo de tipo TEXT o ELEMENT.

El valor por defecto es TRUE(1).

RemoveWhiteNodes
Esta propiedad booleana(1/0) indica si deben pasarse por alto los nodos de tipo WhiteSpace
al procesar un documento.

El valor por defecto es TRUE(1).

SimpleElements
Esta propiedad determina si los elementos con una estructura simple como la siguiente:

<elemento>valor</elemento> o <elemento/>

son procesados como un único nodo de tipo Element.

El valor por defecto es TRUE(1).

ValidationType(.NET y Java)
Esta propiedad determina como se va a validar el XML leído.
Los valores posibles son:
0 – No se realiza validación
1 – Validación automática
2 – Validación por medio de DTD
3 – Validación por medio de un “Schema”
4 – Validación por medio de XDR (Solo .NET)

StopOnInvalid(Solo .NET)
Esta propiedad booleana(1/0) indica si el parser tiene que parar cuando detecta un error de
validación, pero el xml está bien formado.
Si el valor es 0 el método Read() retornará 1 aunque haya habido un error de validación y la
forma de detectar el error es controlando el valor de la propiedadErrCode.

El valor por defecto es TRUE(1).


Soporte para Namespaces

En esta sección se describen las funcionalidades disponibles para procesar documentos XML que
utilizan namespaces.

MÉTODOS
Los siguientes métodos retornan los distintos componentes del nombre de un atributo indicado por
<Index>.
Sólo son válidos para nodos de tipo Element.

Las posiciones se numeran desde 1.

GetAttributeName(<Index>)

GetAttributePrefix(<Index>)

GetAttributeLocalName(<Index>)

GetAttributeURI(<Index>)

<Index> - Integer

PROPIEDADES
Las siguientes propiedades sólo son válidas para nodos de tipo Element y EndTag.

Name
Retorna el nombre completo prefijo:nombrelocal.

Prefix
Retorna el prefijo que representa al namespace del nombre.

LocalName
Retorna el nombre sin el prefijo que representa al namespace.

NameSpaceURI
Retorna el URI usado para identificar al namespace.

Cuando un elemento no está calificado con un namespace, las propiedades Name y LocalName
coinciden.

Entity references

Por defecto, tanto las entidades internas como externas son procesadas automáticamente
reemplazando las referencias por sus valores. El procesamiento de las externas sin embargo puede
ser desactivado usando la propiedad ReadExternalEntities.

Se dispone además de las siguientes funcionalidades:

MÉTODOS
Los siguientes métodos permiten acceder a la notación y entidad referenciadas por un atributo de tipo
ENTITY.
El atributo puede especificarse por medio de su posición en el texto o por su nombre y no se verifica que sea
de tipo ENTITY. Si ninguna declaración fue hecha en el DTD del documento para el valor atributo se devuelve
una cadena vacía.
Sólo son válidos para nodos de tipo Element.

Las posiciones se numeran desde 1.


GetAttEntityValueByIndex(<Index>)

GetAttEntityValueByName(<Name>)

GetAttEntityNotationByIndex(<Index>)

GetAttEntityNotationByName(<Name>)

<Index> - Integer
<Name> - Character

Ejemplo

Se tiene el siguiente documento XML, llamado Reunion.xml

<?xml version="1.0" encoding="ISO-8859-1" ?>

<REUNION Fecha="06/03/01">

<FECHA>06/03/01</FECHA>

<!-- Descrpción de la reunión-->

<![CDATA[ Reunion del equipo de desarrollo de la aplicación.

La reunión fue realizada el Viernes a las 9:30 horas.]]>


<INTEGRANTES>

<INTEGRANTE>Juan Pedro</INTEGRANTE>

<INTEGRANTE>Laura</INTEGRANTE>

<INTEGRANTE>Diego</INTEGRANTE>

<INTEGRANTE>Florinda</INTEGRANTE>

</INTEGRANTES>

<TAREAS>

<TAREA>

<RESPONSABLE>Juan Pedro</RESPONSABLE>

<![CDATA[ Realizar la documentción de la aplicación]]>

</TAREA>

<TAREA>

<RESPONSABLE>Florinda</RESPONSABLE>

<![CDATA[ Reunion con los clientes.]]>


</TAREA>

<TAREA>

<RESPONSABLE>Laura</RESPONSABLE>

<![CDATA[ Realizar el maunal de usuario]]>

</TAREA>

<TAREA>

<RESPONSABLE>Diego</RESPONSABLE>

<![CDATA[ Documentar las especificaciones.]]>

</TAREA>

</TAREAS>

</REUNION>
Este procedimiento GeneXus lee el archivo y obtiene los integrantes de la reunión.

&readfile.open(‘Reunion.xml’ )

&readfile.ReadType(1, 'INTEGRANTES')

&readfile.read()

do while &readfile.name <> 'INTEGRANTES'

&Integrante = &readfile.value

&readfile.read()

enddo

&readfile.close()

Este procedimiento GeneXus lee el archivo y obtiene las tareas de un integrante de la reunión.

&readfile.open(‘Reunion.xml’)

&exito = &readfile.ReadType(1, 'RESPONSABLE')

do while &readfile.value <> &Integrante

&exito= &readfile.ReadType(1, 'RESPONSABLE')

If &exito = 0

Exit

Endif

enddo

If &exito <> 0

&readfile.read()

&tareas = &readfile.value

else

&tareas = Nullvalue(&tareas)

Endif
&readfile.close()

Consideraciones generales

 Para el generador Java sólo se implementó la validación por medio de DTD

 El método AddSchema solo está implementado para el generador .NET

Glosario

Las siguientes definiciones fueron extraídas de “Extensible Markup Language (XML) 1.0 (Second
Edition)”; por más información referirse a http://www.w3.org/TR/2000/REC-xml-20001006; y para el
caso de los Namespaces referirse a http://www.w3.org/TR/1999/REC-xml-names-19990114/

 Character data: Markup takes the form of start-tags, end-tags, empty-element tags, entity
references, character references, comments, CDATA section delimiters, document type
declarations, processing instructions, XML declarations, text declarations, and any white
space that is at the top level of the document entity (that is, outside the document element
and not inside any other markup).

All text that is not markup constitutes the character data of the document.

 Entities: An XML document may consist of one or many storage units. These are called
entities; they all have content and are all (except for the document entity and the external
DTD subset) identified by entity name.

Entities may be either parsed or unparsed.

A parsed entity's contents are referred to as its replacement text; this text is considered an
integral part of the document.

An unparsed entity is a resource whose contents may or may not be text, and if text, may be
other than XML. Each unparsed entity has an associated notation, identified by name.
Beyond a requirement that an XML processor make the identifiers for the entity and
notation available to the application, XML places no constraints on the contents of unparsed
entities.

Parsed entities are invoked by name using entity references; unparsed entities by name,
given in the value of ENTITY or ENTITIES attributes.
 Entity reference: Refers to the content of a named entity.

 CDATA sections may occur anywhere character data may occur; they are used to escape
blocks of text containing characters which would otherwise be recognized as markup. CDATA
sections begin with the string "<![CDATA[" and end with the string "]]>".

 Processing instructions (PIs) allow documents to contain instructions for applications.

 Standalone document declaration: Markup declarations can affect the content of the
document, as passed from an XML processor to an application; examples are attribute
defaults and entity declarations. The standalone document declaration, which may appear
as a component of the XML declaration, signals whether or not there are such declarations
which appear external to the document entity or in parameter entities.

 Document type declaration: XML provides a mechanism, the document type declaration,
to define constraints on the logical structure and to support the use of predefined storage
units. An XML document is valid if it has an associated document type declaration and if the
document complies with the constraints expressed in it.

The XML document type declaration contains or points to markup declarations that
provide a grammar for a class of documents. This grammar is known as a document type
definition, or DTD. The document type declaration can point to an external subset (a special
kind of external entity) containing markup declarations, or can contain the markup
declarations directly in an internal subset, or can do both. The DTD for a document consists
of both subsets taken together.

 XML namespaces provide a simple method for qualifying element and attribute names used
in Extensible Markup Language documents by associating them with namespaces identified
by URI references.
Tipo de Datos WebWrapper

Introducción

WebWrapper es un tipo de datos de GeneXus que permite encapsular la ejecución de los objetos
Web (el código HTML generado). En particular permite enviar el contenido de un Web Panel por
mail.

Aplica a los siguientes objetos: Transacciones, Web Panels y Procedimientos, tanto para el generador
Java como .NET.

Descripción

Para poder enviar el contenido de un Web Panel vía mail desde un objeto GeneXus es necesario
definir una variable de tipo WebWrapper, para luego aplicar los métodos y propiedades necesarios.

La idea es capturar el contenido de un Web Panel en su código HTML, y enviar éste vía mail, por lo
tanto hay que tener en cuenta que el cliente de correo que reciba el mail debe tener la capacidad de
interpretar lenguaje HTML, en caso contrario verá el código del Web Panel.

PROPIEDADES
BaseURL: Es la dirección Base del Web Panel.

La dirección base determina el servidor y directorio virtual al que apuntarán los links y a donde se irá
a buscar el Web Panel en caso de que se presione algún botón. La dirección base es agregada al
código HTML que devuelve el método GetResponse.

Object: Objeto Web a encapsular en la variable de tipo WebWrapper.

A la propiedad Object debe asignársele siempre el resultado de la función Create: Create(Objeto,


Parámetros)

MÉTODOS
GetResponse: Retorna el código HTML que devolvería el objeto Web especificado en la propiedad
Object con los parámetros allí indicados.
Ejemplo

El siguiente ejemplo es un procedimiento que ilustra como enviar por mail, mediante Outlook, el
Web Panel Hnotify para cada registro de la tabla USERS. Dicha tabla tiene clave primaria UserId, el
cual se pasará como parámetros al Web Panel Hnotify. También tiene entre sus atributos
secundarios a UserName, con el nombre del usuario, y UserMail, con la dirección de correo el
electrónico del usuario.

Variables Definidas:

&Wrap del tipo WebWrapper

&MailMsg del tipo MailMessage

&Outlook del tipo OutlookSession

&Wrap.BaseURL = “http://myserver/mysystem/”

For each UserId

&Wrap.Object = Create(Hnotify, UserId)

&MailMsg.To.New(UserName, UserMail)

&MailMsg.HTMLText = &Wrap.GetResponse()

&Oulook.Send(&MailMsg)

EndFor

Consideraciones Generales

Los objetos Web Panel de GeneXus, no son estáticos, por este motivo al enviarlos vía mail, en
realidad se está enviando una imagen estática. Por lo tanto cualquier evento que se produzca en el
Web Panel que realice un post al servidor (por ejemplo hacer clic en un botón, disparar un
procedimiento, etc.) producirá que se abra el Web Panel en el browser, en la dirección especificada
en la propiedad BaseURL.

Si se desea hacer un WebWrapper de un Web Panel que incluya imágenes, se puede hacer de dos
maneras:

 Poner en el Web Panel las imágenes en forma absoluta, el inconveniente de esto es que el
usuario debe estar conectado en el momento de leer el mail.
 Poner en el Web Panel las imágenes relativas y mandarlas como archivos adjuntos en el mail. En
este caso la ruta de la imagen no debe incluir directorios (por ej.: /imágenes/logo.jpg) si no
hacer referencia directamente a la misma (por ej.: logo.jpg).

Si se utiliza un objeto WebWrapper para mandar un Web Panel mediante mail, y dicho Web Panel
tiene un botón o evento clic, el comportamiento al apretar dicho botón (o control con evento clic)
en Outlook XP difiere del de Outlook 2000 y Outlook Express.

En Outlook 2000 y Outlook Express el comportamiento es el esperado: se abre un browser, se hace


el post al servidor Web, y en el browser se muestra la respuesta (incluso puede haber una
redirección, call o link, en el evento).

En Outlook XP el comportamiento es el siguiente: el post lo hace el propio Outlook (no se abre un


browser para hacer el post). Luego se abre un browser haciendo un get de la página para mostrarla.
Pero dicho get se hace solamente si no había una redirección en el evento que ejecutó el post. (De
todas formas, el evento se ejecuta siempre).

Por ejemplo, si se tiene un evento asociado a un botón que graba algo en la base de datos y asigna
cierto valor a una variable que está en el form. En Outlook 2000 y Outlook Express, al apretar dicho
botón en el mensaje se ejecutará el evento, por lo que se hará el cambio a la base de datos, y se
abrirá un browser donde se verá en el form la variable con el valor que se le asignó en el evento. En
Outlook XP se ejecutará el evento, haciendo el cambio en la base de datos, pero el form de
respuesta nunca se mostrará. Luego se abrirá un browser donde se desplegará el form sin modificar
la variable.

Otro ejemplo: el evento asociado al botón modifica la base de datos y hace un call a otro Web Panel.
En Outlook 2000 y Outlook XP, al apretar el botón se hace la modificación a la base de datos y se
abre un browser donde se muestra el Web Panel llamado. En Outlook XP se hace la modificación a la
base de datos pero no se muestra nada, ni siquiera se abre el browser.

Hay dos formas en las cuales podemos cambiar nuestra programación para asegurarnos de que el
comportamiento sea el mismo en los 3 clientes de mail:

1) No usar eventos. Siempre se pueden usar links.


2) Usar un Web Component. Es decir, el Web Panel que se manda por email está compuesto
solamente por un Web Component. Dicho Web Panel tendría el evento Refresh similar al siguiente:

Event Refresh

if base de datos fue modificada

webcomponent.object = create(HGracias, pars...)

else

webcomponent.object = create(HMailForm, pars...)

endif

End Event

En el evento de usuario de HMailForm se haría la modificación a la base de datos por la cual se


chequea en la condición. HGracias es el Web Panel al cual se quería hacer la redirección al procesar
el evento.

INTRODUCCIÓN

Los objetos GeneXus pueden comunicarse entre ellos o con otros programas externos.

Un objeto GeneXus puede llamar a, o ser llamado por, otro objeto pudiendo intercambiar
información a través de parámetros.

En el siguiente cuadro se muestran las invocaciones válidas entre los distintos objetos Web.
C:\Documents and Settings\jiriarte\Desk top\cursointernet90\C ursoInternet90\C urso_no_presencial_'Desarrollo_de_aplicaciones_para_Internet_con_GeneXus'\14_ComunicacionentreObjetos\01_Introduccion_files\image001.g if

Nota:

Es importante tener en cuenta que no todas las combinaciones siempre son válidas. Verificar las combinaciones válidas
en el documento Invocación desde un objeto a otro.
Invocación desde un objeto a otro

Para invocar desde un objeto Web GeneXus a otro objeto GeneXus o programa externo, contamos
con el comando/regla CALL, el comando/función LINK y la función UDP:

 CALL – Es una regla o comando (ya que dependiendo del objeto GeneXus en el que se vaya
a usar, se podrá escribir en la sección de reglas, eventos, u otra parte del objeto) para llamar
a un objeto GeneXus o a un programa externo, siendo posible pasarle parámetros.

 UDP – (User Defined Procedure) Es una función que permite llamar a un objeto GeneXus o
programa externo al cual se le podrán pasar parámetros, y retornará al menos un valor
como resultado de su ejecución.

 LINK - El comando o función link es equivalente al comando CALL para llamar a páginas
estáticas o redireccionar a una URL. Este comando puede ser utilizado dentro de cualquier
evento de un objeto Web con excepción del evento Load. El resultado de la utilización de
este comando es el redireccionamiento en forma automática a la URL especificada dentro
del mismo.

Tanto al utilizar CALL como UDP para invocar desde un objeto GeneXus, a otro objeto GeneXus o programa
externo, cuando se ejecute la invocación, se pasará el control al programa llamado, y al finalizar éste su
ejecución, devolverá el control al llamador en el caso en que el objeto llamado no tenga form, retornándole
parámetros si los hay. Si el objeto al cual se invoca tiene salida en pantalla, este último pasa a tener el
control total, por lo tanto si tenía código por ejecutar el llamador luego de esta invocación, no se ejecutará.

Es importante tener en cuenta que los objetos Web ejecutan en el servidor y por consiguiente no pueden
realizar llamadas a programas externos que tengan salida en pantalla, ya que la ejecución de dicha llamada
cancelaría por time-out. En resumen, desde un objeto Web, se puede llamar a otro objeto Web o a un
Procedimiento o Reporte que no tengan salida en pantalla.
Utilizando CALL, se puede invocar a un objeto GeneXus o programa externo, tanto sin pasarle
parámetros, como pasándole.

Y utilizando UDP, es posible invocar a un objeto GeneXus o programa externo, con la particularidad de que el
programa llamado retornará necesariamente al menos un valor al programa que lo invocó.

El comando LINK permite llamar a páginas estáticas o redireccionar a una URL y en el caso que corresponda
permite pasarle parámetros.

Sintaxis
Link( usr-pgm | ’url’ [{parm1, parmn}…] )

Donde:

usr-pgm: es el nombre del objeto Web al que se va a redireccionar.


<URL> : es el nombre de la URL a la que se va a redireccionar.
<parm1>...<parmn>: son los parámetros que recibe la URL.

El pasaje de parámetros es opcional.

Por ejemplo:

Event ENTER
Link(‘http://www.ARTech.com.uy’)
Endevent

Consideraciones

Los Procedimientos pueden invocar Web Panels y Transacciones Web.

Si el Procedimiento ha sido invocado desde un Web Panel o una Transacción Web o vía HTTP (por
ej.: con la propiedad “Call Protocol” en “HTTP”), podrá también invocar con un CALL o LINK a una
URL HTTP (por ej.: llamar a un Web Panel o a una Transacción Web).

Se debe considerar que dicha invocación no será ejecutada sincrónicamente. Será ejecutada como
un redireccionamiento al objeto invocado al final de la ejecución Web.

Un procedimiento llamado desde la línea de comando, por ejemplo, no puede invocar a un Web
Panel. Pero sí se puede utilizar la función opendocument() para abrir una URL en el browser.

Ejemplo
En este ejemplo se muestra como se realiza la ejecución de distintos objetos cuando desde un
procedimiento se invocan Web Panels o Transacciones Web.

Procedimiento prc01:

call(hwbp01)

for each
A=B

endfor

Procedimiento pproc02:

call(hwbp01)

..

call(hwbp02)

Event 'one'

pprc01.call()

EndEvent

Resultado: El Web Panel hwbp01 será ejecutado antes del "endevent", después del for each.
Event 'two'

pprc02.call()

EndEvent

Resultado: El Web Panel hwbp02 será ejecutado antes del "endevent".

Event 'three'

pprc02.call()

hwbp03.call()

EndEvent

Resultado: El Web Panel hwbp03 será ejecutado antes del "endevent".

¿Por qué funciona de esta forma?

Internamente, en cada sentencia call se setea una variable interna con el nombre del objeto al cuál,
al final de la ejecución en el servidor, la redirección irá.

INTRODUCCIÓN

En este capítulo veremos los requerimientos necesarios para los generadores .NET y Java. Tanto para
el desarrollo de aplicaciones Web como para la puesta en producción.

También profundizaremos en las propiedades necesarias para una aplicación Web, ya sean
propiedades propias de cada generador como también propiedades independientes del generador.

Requerimientos .NET

Además de los requerimientos básicos de GeneXus 9.0 (espacio en disco, cantidad de memoria, etc.)
para cada equipo de desarrollo, se debe contar con el software mencionado a continuación.
Plataforma .NET

Para el desarrollo de aplicaciones es necesario instalar:

Release del Framework Redistributable 1.1 y J# Version 1.1 Redistributable Package o

Release del Framework Redistributable 2.0 y J# Version 2.0 Redistributable Package

El Visual J# es requerimiento para los reportes PDF de las aplicaciones Web.

Manejador de base de datos

SQL Server

ADO.NET utiliza el Data Provider de Microsoft para SQL Server (el cual se instala con el Framework).
No se requiere el cliente SQL Server.

Oracle

Se debe tener el Cliente de Oracle versión 8.1.7.5 o superior, de esta forma se instala el Data
Provider correspondiente. El valor “Server Name” de las DBMS option hace referencia al Service
Name definido en la instancia del Oracle.

La implementación utiliza el Data provider de Microsoft para Oracle (System.Data.OracleClient), el


cual requiere el cliente.

DB2 UDB for iSeries

Se necesita la V5R3 del iSeries Client Access con un service level igual o superior a SI20055. La menor
versión testeada del server es la V5 R1.

Se puede obtener desde:http://www-03.ibm.com/servers/eserver/iseries/access/casp.html

Al crear un modelo se debe copiar la dll IBM.Data.DB2.iSeries.dll al directorio gxnet/bin.

DB2 Universal Database

Se necesita tener instalada la versión 8.1.3 o superior.

La dll es IBM.Data.DB2.dll, se debe copiar a los directorios gxnet/bin.

MySQL
MySQL soporta diferentes motores, GeneXus utiliza el InnoDB

(http://dev.mysql.com/doc/mysql/en/InnoDB.html).

La menor versión soportada del server es 3.23.58. El driver cliente para .NET se puede obtener
desde:

http://sourceforge.net/projects/mysqldrivercs.

Luego de instalado se debe tener los archivos:

 mysql.dll – Biblioteca .NET de acceso a MySQL.

 MySQLDriverCS.dll se debe copiar bajo el directorio gxnet/bin.

Informix

No tiene acceso ADO.NET, se debe acceder con ODBC. La versión del DBMS puede ser 7.0 o Informix
Foundation 2000. En el cliente debe estar instalado el cliente con la versión correspondiente. Se
recomiendan los drivers de Intersolv o Informix.
PostgreSQL

No tiene acceso ADO.NET, se debe acceder con ODBC.

Servidor Web

Se deberá contar con el servidor Web Internet Information Server 5.0 o superior.

IMPORTANTE: El mismo debe ser instalado antes del .NET Framework.

INTRODUCCIÓN

Existe una API especificada por Sun Microsystems que se llama “Java Servlet API”. Esta API define la
forma de ejecutar lo equivalente a los objetos Web de GeneXus, por lo tanto, el generador Java, por
cada objeto Web de GeneXus, genera lo que se llama un Servlet.

Los Servlets proveen una gran cantidad de ventajas que el generador Java aprovecha, como por
ejemplo, la utilización de un pool de conexiones a la base de datos y la multiplataforma.

A su vez, el generador Java provee una funcionalidad adicional que consiste en que los objetos Web
pueden enviar la página HTML comprimida, para que sea descomprimida en tiempo real por el
browser. La compresión se realiza sólo si el browser indica que es capaz de descomprimirlo. Esta
opción puede deshabilitarse con la propiedad “Auto Compress HTTP Traffic”, para contemplar el
hecho de que algunos browsers no reporten correctamente su capacidad para descomprimir las
páginas, y no las puedan desplegar correctamente. En las pruebas que hemos realizado, esta
funcionalidad se ha comportado de forma correcta con todos los browsers.

Requerimientos Java

Además de los requerimientos básicos de GeneXus 9.0 (espacio en disco, cantidad de memoria, etc.)
para cada equipo de desarrollo, es necesario contar con cierto software de desarrollo Java para la
compilación y ejecución de las aplicaciones generadas y el software necesario para el acceso a la
base de datos (drivers JDBC).
JDK/JRE (Java Development Kits Compiladores y Máquinas Virtuales)

Para la compilación y ejecución de los programas es necesario contar con alguno de los
Development Kits del mercado. Los principales son los de Sun, Microsoft e IBM.

Si bien no es requisito tener todos los Development Kits, es recomendable.

JDK DE SUN
Para instalar el JDK de Sun, se debe bajar del Web site de Sun la última versión del JDK para Win32,
ejecutar el EXE descargado, y seguir las instrucciones.

SDK DE MICROSOFT
El SDK de Microsoft no está disponible en internet ni se comercializa más. En ese caso se podrá usar
el compilador del JDK de Sun (javac.exe), que es gratuito.

Para determinar si el intérprete está instalado, puede ejecutarse lo siguiente:

C:\WINDOWS\system32>jview

Se mostrará la versión disponible del compilador y de la máquina virtual, respectivamente, por


ejemplo:

Cargador de línea de comandos de Microsoft (R) para Java


Versión 5.00.3810

Copyright (C) Microsoft Corp 1996-2000. Todos los


derechos reservados.

Uso: JView [opciones] <classname> [argumentos]

Opciones:

/? muestra texto de uso

/cp <ruta de clase> establece la ruta de clase

/cp:p <ruta> antepone la ruta a la ruta


de clase
/cp:a <ruta> agrega ruta a la ruta de
clase

/n <nombre del espacio> nombre del espacio en el que


ejecutar

/p pausa antes de finalizar si


ocurre un error

/v comprueba todas las clases

/d:<nombre>=<valor> define las propiedades del


sistema

/a ejecuta AppletViewer

Nombre de clase:

Archivo .CLASS a ejecutar.

Argumentos:

Argumentos de la línea de comandos para pasar al


archivo de clase

Generalmente el intérprete de Microsoft ( jview.exe ) es parte de la instalación de todas las


plataformas Windows, aunque no esté instalado el SDK de Microsoft.

Si no está disponible o está desactualizado (esto es, con una versión anterior al 5.00.3805), entonces
se puede obtener con Windows Update.

La otra alternativa es usar el intérprete de Sun, java.exe, que forma parte del SDK de Sun.

Por razones de performance, se recomienda fuertemente utilizar el compilador de Sun ( javac.exe )


conjuntamente con el intérprete de Microsoft ( jview.exe ).
COMPILADOR JIKES DE IBM
IBM provee sólo el compilador Java, en forma open-source. Para instalarlo, se debe bajar la versión
para windows, que es un archivo zip.

Para la instalación simplemente se debe descomprimir el zip hacia una carpeta, y mover ésta hacia
donde quiera hacerse la instalación. El directorio de instalación contendrá dos subdirectorios: bin,
que tiene el compilador (jikes.exe) y doc, que contiene instrucciones de uso y licencia.

Para poder utilizar este compilador es necesario que esté instalada alguna versión del JDK de Sun,
dado que requiere de sus bibliotecas de clases.

En cuanto a las versiones de este software se recomienda utilizar las últimas liberadas de cada uno
de ellos, pero no versiones beta.

Driver JDBC

Los drivers JDBC (equivalentes a ODBC) permiten efectuar conexiones con bases de datos.

Existen cuatro tipos de driver JDBC que se detallan a continuación.

Dependiendo del DBMS y del tipo de acceso a la base de datos que se utilice, puede ser necesario
obtener uno u otro tipo de driver JDBC. Generalmente se utilizan los drivers de tipo 4, que se
presentan a continuación junto con otros tipos de driver.

Los números de tipos de driver corresponden a una numeración que fijó SUN.

Tipo 1: Java -> ODBC


Esta arquitectura, tiene como ventaja importante que permite la utilización de drivers ODBC
existentes, pero la desventaja de que hay que instalarlos en cada máquina, así como el cliente de
DBMS.

De esta forma, en el cliente se requiere:

 DRIVERS JDBC

 DRIVERS ODBC (se crea un Data Source con la información de conexión)

 CLIENTE DBMS

La aplicación GeneXus-Java se comunica con los DRIVERS JDBC. A los DRIVERS JDBC se les configura
un parámetro para indicar que la conexión es a cierto Data Source. Y finalmente con la información
definida en el Data Source, se establece la conexión del cliente con el Servidor Manejador de Base de
Datos (DBMS).

Las implementaciones actuales de estos drivers no son muy fiables, por lo que no se recomienda su
utilización en ambientes de producción. Sin embargo, existe un caso por el cual utilizar el driver tipo
1: algunas versiones de AS/400 no soportan los dirvers JDBC, de modo que la única forma de
implementar una aplicación Java en 2 capas, en esos casos, sería mediante este tipo de driver
llamado también Bridge JDBC-ODBC.
Tipo 2: Java -> Protocolo DBMS

Con esta implementación, en el cliente se tienen los DRIVERS JDBC que se comunican directamente
(en forma nativa) con el CLIENTE Oracle, Sybase, Informix, DB2, o cualquier otro DBMS.

De esta forma, entonces, al igual que el driver de tipo 1, este también requiere que se instale en
cada máquina cliente, los DRIVERS JDBC y CLIENTE DBMS.

En general los drivers tipo 2, también llamados Native-API Partly-Java, se comunican muy rápido
con la base de datos, siendo en teoría, los más performantes. Salvo por ésto, este tipo de driver no
presenta demasiadas ventajas con respecto a las otras alternativas.

Tipo 3: Java -> Servidor JDBC

Esta clase de driver traduce llamadas JDBC en un protocolo de red independiente del DBMS y luego,
a un protocolo de DBMS.

Un Servidor JDBC, realiza la tarea de middleware, siendo capaz de conectar un cliente Java a
diferentes bases de datos.

La implementación del Servidor JDBC se realiza mediante la instalación de un software que sabe
“escuchar” los requerimientos del CLIENTE JDBC y traducirlos a llamadas nativas para los DBMSs.
Una ventaja que posee el driver tipo 3, también conocido como net-protocol all-Java, es que no requiere
instalación en los clientes, según el DBMS. Como contrapartida, este driver requiere la instalación del
Servidor JDBC.

Merant DataDirect SequeLink Java Edition es un driver de tipo 3 que se ha probado para SQL Server y
Oracle.

Nota: Para ejecutar Applets, en 2 capas, si se utiliza el driver tipo 3, el Servidor JDBC deberá
encontrarse en el mismo host que el Servidor Web, por ser el Servidor JDBC el que resolvería la
conexión. En este caso, sería posible efectuar conexión con un DBMS que no se encuentre en el
mismo host que el Servidor Web.
Tipo 4: Java -> DBMS

El driver tipo 4 convierte llamadas JDBC directamente en el protocolo de red usado por el DBMS.
Esto permite llamadas directas desde la máquina del cliente al servidor del DBMS y es una solución
práctica para el acceso a Intranets.

Requieren más código, por lo que si se usa en 2 capas hay que bajar más código al cliente, y la
performance suele ser algo menor que la de los otros drivers (esto puede depender mucho del
driver, de la cantidad de conexiones simultaneas, etc). De todas formas, este es el tipo de driver más
común, y el que se usa más en general.

Dado que muchos de estos protocolos son propietarios, los proveedores de bases de datos son la
principal fuente de este tipo de driver.

Algunos ejemplos son:

 I-net Software

 WebLogic jDriver

 AsToolBox

 Merant

El driver tipo 4, también denominado native-protocol all-Java, no requiere instalación en los


clientes, según el DBMS.

Nota: Para ejecutar Applets, en 2 capas, si se utiliza el driver tipo 4, el DBMS deberá encontrarse en
el mismo host que el Servidor Web pues no se permite a un Applet establecer una conexión con otra
máquina que no sea el servidor de donde provino.
Browser

Para utilizar el generador Java, no es necesario tener ningún un browser instalado, sin embargo, se
recomienda tener tanto Internet Explorer como Netscape para probar el correcto funcionamiento de las
aplicaciones.

Dependiendo de la versión del Java Development Kit que se utilice, el browser puede requerir el Java Plug-In,
por lo que sería necesario disponer de este software también.

Visualización de Reportes

Para poder visualizar reportes PDF desde el browser, debe tenerse instalado Adobe Acrobat Reader.

Para poder ejecutar Servlets, es necesario contar con:

 Un Servidor Web

 Un Motor de Servlets

 JavaServer Web Development Kit

El Servidor Web y Motor de Servlets, son dos servicios que se requieren (en un mismo servidor físico,
o no) para poder ejecutar Servlets.

En teoría, las aplicaciones GeneXus pueden ejecutarse con cualquier Motor de Servlets que sea
compatible con la especificación de Servlets 2.1 o posterior.
Algunos de los motores que se han utilizado exitosamente son:

 IBM WebSphere en Windows, RS/6000, Unix OS/390, Linux y AS/400

 JRun en Windows

 Jakarta Tomcat en Windows y Linux

 Resin en Windows y Linux

 Apache Jserv en Windows y Linux

Por su parte, el JavaServer Web Development Kit, se instala automáticamente con la instalación del
Motor de Servlets, y permite que el desarrollador pueda compilar los Servlets (objetos Web de
GeneXus).

A continuación explicaremos los pasos en orden, que se deben seguir para configurar y utilizar estos
requerimientos. Explicaremos en forma conceptual y genérica cada punto, y tomaremos a modo de
ejemplo, la opción de utilizar el Motor de Servlets RESIN para Windows, en forma local, con el fin de
mostrar un ejemplo práctico concreto.

Configuración de un Motor de Servlets

Para ejecutar una aplicación Web Java, se debe configurar un motor de servlets; para ello se deben
realizar algunos pasos, que si bien varían un poco según el motor de servlets que se vaya a utilizar,
básicamente los pasos a seguir, son similares.

Primeramente, vamos a introducir el concepto de “Webapp”, relacionado a los motores de servlets.


Qué es una Webapp?

Cada motor de servlets crea y maneja una “Webapp”. El nombre Webapp resulta de la abreviación
de "Web application" y consiste en un directorio base, que contiene a su vez una estructura de
subdirectorios determinada, en la cual se deben distribuir los archivos que sean necesarios para la
ejecución de una aplicación Web.

Los tipos de archivos involucrados en la ejecución de una aplicación Web, pueden ser los servlets
(archivos .class), contenido estático y librerías adicionales (archivos .JAR).

Pasos a seguir

Una vez visto este concepto, pasemos a detallar entonces los pasos a seguir para configurar un
motor de servlets:

1) Instalar el motor de servlets.

2) Definir una Webapp o bien identificar cuál es la Webapp por defecto para utilizarla.

3) Copiar drivers JDBC y clases standard de GeneXus (gxclassr.zip) al directorio “lib” de la


Webapp.

4) Levantar el motor de servlets.

5) Tests:

a. Ejecutar el servlet de ejemplo del motor de servlets, para comprobar que la


instalación haya sido correcta, así como comprobar que el motor haya levantado
bien.

b. Ejecutar el servlet: com.genexus.Webpanels.gxver, que devuelve la versión de las


clases standard de GeneXus. Mediante la ejecución de este servlet se puede
comprobar primeramente que se están encontrando las clases standard de GeneXus
y luego, que se trata de la misma versión con las que se generaron los servlets.

A modo de ejemplo, si se utiliza RESIN en Windows, en forma local, se deben seguir los siguientes
pasos:

1) Instalar el motor de servlets: para ello, simplemente se debe descomprimir un archivo de


instalación .ZIP en algún directorio del equipo servidor (por ejemplo en c:\resin).

2) La Webapp por defecto en este caso, es: C:\resin\doc\


3) Copiar las clases standard de GeneXus (gxclassr.zip) y las clases del driver JDBC al directorio
C:\resin\doc\WEB-INF\lib

4) Para levantar el motor de servlets, se debe ejecutar c:\resin\bin\httpd.exe.

5) Tests:

a. Para verificar que el RESIN haya levantado bien, se debe ejecutar el servlet que viene
de ejemplo accediendo de la siguiente forma:

http://localhost:8080/examples/basic/servlet/HelloServlet

b. Para verificar que se estén tomando las clases standard de GeneXus y cuál versión,
se debe ejecutar:

http://localhost:8080/servlet/com.genexus.Webpanels.gxver

Propiedades de ejecución .NET

A continuación se detalla el significado de cada una de las opciones que figuran en el diálogo de
configuración de la opción del menú Build / Run (F5).

Compiler Path: Determina el path del compilador (csc.exe), este se encuentra bajo el directorio de
instalación del Framework en:

C:\WINNT\Microsoft.NET\Framework\v1.1.4322

Virtual Directory: Determina la URL base de ejecución, esta contiene el directorio virtual a ser
creado (si no existe) por GeneXus en el Internet Information Service (IIS) local. El momento de la
creación es luego de la compilación y reorganización.

Propiedades de ejecución Java

Para la ejecución de aplicaciones Web con Java, se debe configurar las siguientes propiedades:

Platform

Se debe seleccionar el ambiente de compilación y ejecución, es decir cuál Java Development Kit se
utilizará. Las posibilidades son:
 Microsoft SDK

 Sun JDK

 IBM’s Jikes Compiler

Classpath

En classpath se referencian las clases necesarias para compilar los servlets (clases correspondientes
al JavaServer Web Development Kit). El archivo puede llamarse servlet.jar o jsdk.jar o jsdk22.jar
(dependiendo del Motor de Servlets que se utilice) y por lo general se encuentra en el subdirectorio
Lib del Motor de Servlets. Estas clases se deben referenciar en el classpath, además, del resto de los
archivos de clase que se requieran referenciar en dicha variable de entorno.

Compiler Path

En el Compiler path se especifica la ubicación del compilador Java a utilizar.

El compilador del Development Kit de Sun se llama javac.exe, mientras que el compilador del
Development Kit de Microsoft se llama jvc.exe. Ambos compiladores se encuentran en el
subdirectorio BIN del JDK / SDK.

El compilador del Development Kit de IBM, por su parte, se llama jikes.exe.

Make Path

Aquí se debe especificar la ubicación del programa de make que se desea utilizar. La función del
programa de make es procesar los archivos .mak, que indican las precedencias entre archivos para
compilar.

Microsoft provee un programa de make (sin costo) llamado nmake.exe, que es el que se recomienda
usar.

Sun no provee un programa de make, por lo que para compilar con el JDK de Sun se puede utilizar el
programa de make de otros proveedores, como el de Microsoft.
Si se opta por compilar con Jikes de IBM se sugiere utilizar el programa de make que provee
Microsoft.

Interpreter path

El intérprete de Sun se llama java.exe mientras que el de Microsoft se llama jview.exe. Ambos
intérpretes se encuentran en el subdirectorio BIN del JDK / SDK. El intérprete de Microsoft es uno los
programas básicos provistos junto con el sistema operativo. Es decir, normalmente Windows incluye
jview, en el directorio C:\WINDOWS\system32, independientemente de si el JDK está instalado o no.

JIKES de IBM, por su parte, incluye solamente compilador. Si la ejecución es en Windows, se suele
elegir el intérprete de Microsoft, de lo contrario el de Sun.

Normalmente se recomienda utilizar plataforma y compilador de Sun, pero con el intérprete jview y
el programa nmake, ambos de Microsoft.

Web application base URL

Este campo es para especificar la URL que el browser utilizará como base para la ejecución de los
objetos Web.

Propiedades avanzadas

WEB BROWSER SETTINGS


Esta sección aplica solamente a la ejecución de Applets. Si se marca la opción “Use Default Browser”,
se ejecutarán los Applets utilizando el browser que se tenga por defecto en el sistema.

Si no se marca dicha opción, se puede ingresar el path del browser a utilizar. Adicionalmente, los
JDK/SDK’s incluyen un programa llamado appletviewer que permite ejecutar Applets.

COMPILES OPTIONS
Permite especificar parámetros que se desee pasar al compilador elegido cada vez que GeneXus lo
llame. El compilador especificado en “Compiler Path” debe poder reconocer estos parámetros. Por
defecto, está dado el parámetro “–O”, que permite generar código optimizado para la ejecución, sin
información para el programador.
Si se dispone del SDK de Sun y se desea ver las opciones posibles para el compilador, puede
invocarse desde línea de comandos como:

javac -help

En la configuración más recomendada (plataforma y compilador de Sun, más intérprete y nmake de


Microsoft), las opciones a pasar al compilador deben ser las siguientes:

-O 1.1 -target

INTERPRETER OPTIONS
Análogo al anterior, permite especificar parámetros opcionales que quieran pasarse al intérprete.
Con SDK de Sun, las opciones disponibles pueden verse con:

java –help

MAKE OPTIONS
Permite especificar opciones para el comando make especificado en “Make Path”. Por ejemplo, si se
utiliza el nmake de Windows, para ver las opciones disponibles, ejecutar desde una consola de DOS:

nmake -help

Propiedades a considerar en el desarrollo de objetos Web

En los modelos GeneXus, existen propiedades que aplican exclusivamente a los objetos Web.
Algunas a nivel del modelo de diseño por lo que aplican a toda la base de conocimiento y otras se
encuentran a nivel de los generadores (por lo que aplican al modelo de prototipo o producción que
lo utilice).

Propiedades generales

Estas propiedades se definen a nivel del modelo de Diseño. Se setean mediante la opción File / Edit
Model / Properties teniendo abierto el modelo de diseño. Las relacionadas con objetos Web son:
 Base Image Path

Propiedades a nivel del Generador

A nivel de cada modelo, existen algunas propiedades (en la sección Web Information) que aplican
exclusivamente a los objetos Web.

FOCUS CONTROL
Esta propiedad permite determinar si los objetos Web, al mostrar su página, intentan posicionar el
foco en el primer control de entrada (no read-only) o dejan librado al browser la posición del foco.

Los valores posibles son:

 First input att/var on the page

 Browser dependent

Existe también la propiedad a nivel de objeto con los mismos valores que la propiedad del modelo y
también el valor “Use model's property value”.

PROTOCOL SPECIFICATION
Esta propiedad permite especificar el protocolo a utilizar en la URL generada para invocar a los
objetos Web.

Tiene tres valores posibles:

 Unsecure (HTTP)

 Secure (HTTPS)

 Do not specify

El valor por defecto es “Unsecure (HTTP)”, que fuerza a generar HTTP como protocolo en la llamada
al Web Panel e indica que el protocolo a utilizar es el Hypertext Transfer Protocol.
El valor “Secure HTTPS”: fuerza a generar HTTPS como protocolo e indica que el protocolo a utilizar
es el Secure Hypertext Transfer Protocol. Para utilizar este protocolo es necesario disponer de un
servidor seguro.

El valor “Do not specify” indica que no se especificará un protocolo particular, sino que se utiliza el
mismo protocolo empleado para acceder al Web Panel actual.

En el caso de tener aplicaciones con un esquema mixto: algunas páginas seguras y otras no, la
propiedad del modelo deberá configurarse con el valor “Do not specify” y para cambiar el protocolo
deberá hacerse un link al objeto indicando expresamente el protocolo a utilizar.

ENCRYPT URL PARAMETERS


Esta propiedad permite especificar si se desea encriptar los parámetros que se envían entre objetos
y que son visibles en la URL del browser.

Por más información referirse a la documentación: Encriptación de parámetros.

ON REQUEST SSP SERVER DIRECTORY


La propiedad “On request SSP server directory” es requerida cuando se generan SSP (Smart Static
Pages) en forma dinámica. Por más información referirse a la documentación de Smart Static Panels.

ON REQUEST SSP CLIENT URL


La propiedad “On request SSP client URL” es requerida cuando se generan SSP (Smart Static Pages)
en forma dinámica. Por más información referirse a la documentación de Smart Static Panels.

BEFORE CONNECT
La propiedad “Before Connect” ha sido implementada para cambiar las propiedades de la conexión
en forma dinámica en tiempo de ejecución.

Para utilizar esta característica, se requiere un Procedimiento GeneXus. Este Procedimiento debería
establecer las propiedades de conexión en tiempo de ejecución; será ejecutado inmediatamente
antes que el pedido de cualquier conexión sea ejecutado por la aplicación para interactuar con la
base de datos.

TEMP MEDIA DIRECTORY


Esta propiedad se utiliza para configurar el path en el servidor Web en donde se salvarán
temporalmente los archivos cuando se carguen en la base de datos. Esto ocurre, cuando un Blob es
agregado o modificado, temporalmente se guarda en dicho directorio. Este directorio debe ser
accesible desde el directorio virtual.

AFTER CONNECT
Esta propiedad permite llamar a un procedimiento GeneXus, inmediatamente después de ser
asignada la conexión en una aplicación. Esta implementación permite apoyarse en los mecanismos
de auditoría.

EXPOSED NAMESPACE
Por medio de esta propiedad se puede indicar el valor del namespace del SOAPAction del Web
Service.

Aplica a procedimientos con la propiedad “Call protocol” en “SOAP”.

El valor por defecto es el nombre de la base de conocimiento pero es conveniente cambiarlo a un


namespace que identifique a la empresa al momento de poner en producción el Web Service.

Propiedades de .NET

Estas propiedades se definen a nivel del modelo .NET y se setean mediante la opción File / Edit
Model / Properties teniendo abierto dicho modelo.

.NET aplication Namespace

Determina el namespace de la aplicación. Los programas generados por GeneXus y compilados con
.NET se encuentran disponibles bajo el namespace indicado por esta propiedad. El default es
GeneXus.Programs. Sirve para los usuarios avanzados que quieren hacer algún tipo de deployment
en el GAC (Global Assembly Cache).

Valor por defecto: GeneXus.Program.

Generate developer menu makefile

Indica si se generaran los archivos necesarios para compilar el developer menú. El valor en “No” es
útil para evitar el armado del makefile del developer menú, este es muy costoso ya que debe
generar todos los response file (*.rsp) cada vez que se compila un objeto.

Valor por defecto : “Yes”.


Generate strong named assemblies
Determina que los objetos main y/o dlls (assemblies) generados tengan un nombre único o no. Esto
permite acceder a un conjunto de ventajas importantes que provee el .NET Framework, como
deployment en el GAC o configuración de seguridad para el assembly.

Valores:

Yes: El programa generado tiene un “Strong Name”.

No: El programa generado no tiene un “Strong Name”.

Valor por defecto: “No” .

Para generar el “Key” que identifica al objeto, el generador al momento de compilar busca un
key.snk en el directorio dataxxx, si no hay: genera uno. (se requiere el SDK en el ambiente de
desarrollo para ejecutar el sn.exe y generar el archivo con la Key).

Además se debe configurar en la variable de ambiente “path” el camino a sn.exe para que la
encuentre el compilador ("C:\PROGRAM FILES\MICROSOFT.NET\SDK\V1.1\bin"), de lo contrario da
el error "Before compile error: The system cannot find the file specified"

Los programas estándar provistos por el generador tienen strong names independiente del valor de
la propiedad.

Assemblie versión number


Determina el número de versión a asignar a los assemblies que tienen strong name. La propiedad
sólo aplica cuando la propiedad “Generate strong named Assemblies” está en “Yes”.

Valor por defecto: 1.0.0.0

Compiler Flag
La información de esta propiedad se incluirá en el .rsp que se usa para compilar los assemblies. Es
útil por ejemplo, para generar información de debug (incluyendo el string “/debug”) o para incluir
una dll dentro del namespace (/r:xxx.dll ).
Config HttpHandlers Section
La información de esta propiedad determina cómo se mapean los assemblies en ejecución.

Valores:

HttpHandler for each object: Una entrada en el web.config por cada assembly. Aquí se
mapea el request del aspx con el assembly GeneXus.Programs.object (bin\object.dll).

HttpHandlerFactory: Hay una sola entrada para todos los objetos en el web.config, en donde
se indica un objeto al que pedirle el mapeo.

ASHX: No hay mapeos en el web.config, se genera un archivo ashx por cada objeto que
realiza el mapeo con el assembly GeneXus.Programs.object

El valor HttpHandler for each object es más rápido en ejecución pero más lento en la carga inicial.
Además permite tener objetos (*.aspx) no generados con GeneXus, con HttpHandlerFactory esto
no es así.

HttpHandlerFactory es más rápido para prototipar pero más lento en cada llamada porque el
mapeo se resuelve en cada requerimiento. Esta opción puede enviar mensajes de error poco
descriptivos, lo que dificulta la prototipación.

El valor ASHX, es similar a Handler Factory, crea un archivo físico con el nombre del objeto y
extensión ashx, el cual es invocado en ejecución.

Valor por defecto: HttpHandler for each object

Access Method
Determina qué tipo de acceso se va a utilizar para acceder a la base de datos. El método de acceso
especificado será utilizado para acceder a cada uno de los data stores.

Valores:

ODBC: Acceso vía ODBC

ADO.NET: Acceso vía ADO.NET

Valor por defecto: Depende del DBMS asociado al data store Default.

Propiedad Enable Caching


Esta propiedad permite definir si se habilita el “cache” de sentencias.

Valores:

Yes: Hablita el caching


No: Deshabilita el caching

Valor por defecto: “No”.

Caching Section
Las siguientes tres propiedades aplican cuando la propiedad “Enabled Caching” está en “Yes”.

PROPIEDAD HARDLY EVER TTL (MINS)


Cuando se lee una tabla que tiene en la “Propiedad Change frequency” el valor “Hardly Ever”, se
mantiene en el “cache” durante el tiempo en minutos definido en esta propiedad.

Valor por defecto: 600

PROPIEDAD TIME TO TIME TTL (MINS)


Cuando se lee una tabla que tiene en la “Propiedad Change frequency” el valor “Time to Time”, se
mantiene en el “cache” durante el tiempo en minutos definido en esta propiedad.

Valor por defecto: 60

La diferencia entre la propiedad “Time to Time” y la propiedad “Hardly Ever”, es permitir definir
distintos puntos de persistencia en las tablas del modelo.
PROPIEDAD CHANGE FREQUENCY
Si bien el “cache” se realiza a nivel de sentencia, es a nivel de tabla que se configura, permitiendo
seleccionar el tiempo en que los datos van a persistir en memoria antes de ir a buscarlos
nuevamente a la base de datos. Para poder configurar este tiempo se utiliza esta propiedad, que se
configura a nivel de tablas, en modo de diseño.

Valores:

Almost Never: Se mantienen los datos en “cache” indefinidamente.

Pretty Often: No se realiza “cache”.

Hardly Ever: Valor que se define a nivel de modelo prototipo/producción.

Time to Time: Valor que se define a nivel de modelo prototipo/producción.

Valor por defecto: Pretty Often

Log Level

Esta propiedad permite configurar el nivel de trace de acceso a la base de datos con conexión
ADO.NET.

Valores:

0. Off

1. Fatal

2. Error

3. Warn

4. Info

5. Debug

6. All

Valor por defecto: Off

Esta propiedad escribe el tag <log4net threshold=...> del archivo web.config y client.exe.config (para
modelos Web y Gui respectivamente). En el caso de modelos web también se escribe el tag <trace
enabled=true />.
Propiedad Maximum Cached cursors per connection

Uno de los costos más importantes en las operaciones ODBC/ ADO.NET es el de preparar las
sentencias SQL. La preparación incluye la compilación y validación de la sintaxis de dicha sentencia
por parte del servidor.

Los programas generados en .NET realizan un manejo inteligente de los cursores abiertos, de modo
que no haya que volver a preparar cursores que ya fueron preparados. Para eso se mantiene un pool
de cursores preparados, cuyo tamaño por defecto es de 100 cursores. Si se desea cambiar este
número, se puede cambiar el valor de esta propiedad.

Valor por defecto: 100

Propiedades del modelo Java

A continuación se explican las propiedades que deben configurarse para la generación de


aplicaciones Web con el generador Java.

 Servlet Directory

 Static content base URL

 Static directory seen from client

 Auto compress web pages

 Generation Mode

Propiedad Servlet Directory

Para ejecutar los Servlets, una vez compilados, deben estar en un directorio específico de la
estructura obtenida al instalar el Motor de Servlets. La misma varía en cada caso, dependiendo del
Motor de Servlets que se utilice.

Propósito

Permite especificar el directorio donde se transferirán los Servlets generados. En tiempo de


compilación de cada objeto Web, el generador los copiará al directorio especificado.
Notas:

 Es necesario especificar este valor antes de generar, ya que se utiliza para la generación del
archivo de make.

 El path debe ser relativo al cliente, es decir un path visto desde el PC en el que se está
trabajando con GeneXus.

 Se copiarán además de los archivos .class, los archivos .cfg, los cuales contienen la
información de las propiedades ingresadas; por lo tanto, si se modifica algún valor de las
propiedades del modelo, es necesario volver a generar y compilar algún objeto Web.
Además, para que se tome en cuenta este cambio al ejecutar, es necesario reiniciar el
servidor de servlets.

Ejemplos de valores

 H:\servlets - Si el motor de servlets está instalado en una máquina mapeada con el “drive”
H y servlets es el nombre del directorio donde deben residir los servlets.

 C:\resin\doc\Web_inf\classes – Si el motor de servlets es el RESIN y esta instalado


localmente en el directorio C:\resin.

Propiedad Static Content base URL

Propósito

Indica el directorio donde los servlets buscarán el contenido estático (imágenes, javascritps y
styles.css) utilizado en los objetos Web correspondientes. Los servlets siempre ejecutan en el
servidor, por lo que este directorio debe especificarse relativo al directorio correspondiente a la
“base URL” de la webapp.

Nota: Cambiar el valor de esta propiedad no implica regenerar la aplicación, sino solo un objeto Web. Si está
en producción, sólo basta con modificar el archivo client.cfg.

Ejemplo de valores

Si se crea un directorio llamado “images” bajo el directorio raíz del webapp donde se instalaron los
servlets, y a él se copian todas las imágenes necesarias, y en diseño sólo se especifica el nombre de
la imagen, entonces en esta propiedad habría que poner /images.
Propiedad Static Content directory seen from client

Propósito

Permite especificar el directorio donde se transferirán los JavaScripts (archivos *.js) que se generan
para los menubars de objetos Web y Web Panels generados como estáticos. En tiempo de
compilación, el generador los copiará al directorio especificado.

Notas:
 En este mismo directorio también habrán archivos de imágenes que se utilicen en los
objetos Web. Los mismos se deben copiar manualmente a este directorio, y en los
programas generados se referenciarán utilizando el valor de la propiedad “Static Content
Base URL” concatenada con el nombre de cada imágen.

 El path especificado debe ser relativo al cliente, es decir un path visto desde el PC en el que
se está trabajando con GeneXus.

Ejemplos de valores

 X:\images - Si el servidor Web está instalado en una máquina, mapeada con el “drive” X y
es el directorio “images” el utilizado para dejar el contenido estático.

 C:\resin\doc\images – Si el motor de servlets es el RESIN, está instalado localmente en el


directorio C:\resin y se le creó el directorio images donde se copiaron las imágenes.

Propiedad Auto Compress HTTP Traffic

Propósito

Los objetos Web, en Java, pueden enviar la página HTML comprimida, de modo que sea
descomprimida en tiempo real por el browser. La compresión se realiza solamente si el browser
indica que es capaz de descomprimirlo.

Valores

Yes: envían la página comprimida.

No: no envían la página comprimida. Es posible que algunos navegadores no reporten


correctamente su capacidad para descomprimir las páginas, y no puedan desplegarlas
correctamente.
Default Value = “Yes”.

Generation Mode

Esta propiedad permite especificar si los objetos Web del modelo se generarán como objetos
dinámicos (acceden a la base de datos) o como páginas HTML inteligentes (Smart Static Panels).

También existe la posibilidad de generar Smart Static Panels a pedido mediante el valor “Create
Static panels on request” de esta propiedad. Si se elige este valor, cuando se ejecuta un Web Panel,
chequea si existe un .html que corresponda a sí mismo, con los parámetros que se le pasaron. Si
existe, se redirecciona la llamada a dicho html. Si no existe, se crea el .html y luego se redirecciona.

Por más información referirse a la documentación de Smart Static Panels

Existe también la propiedad a nivel de objeto con los mismos valores que la propiedad del modelo y
también el valor “Use model's property value”.

Puesta en Producción Generador .NET

Requerimientos

Los requerimientos son similares al ambiente de desarrollo.

 Servidor Web

 Internet Information Server 5.0 o superior


 .NET Framework Redistributable 1.1 o 2.0 (Recomendable: Realizar la instalación del
mismo a partir del Windows component update provisto por el setup de Visual Studio
.NET)
 Manejador de Base de datos

 Servidor de Base de Datos

Instalación en el servidor

En una aplicación Web es necesario copiar al servidor:

 El directorio bin del modelo (donde se encuentran las dlls de cada objeto)
 Los java script ( *.js)

 Las imágenes, htmls, *.css y cualquier contenido estático deseado

 El archivo Web.config

 Si se usan tipos de datos de Office, es necesario registrar la gxoffice2.dll

Instalación en el Cliente

Cliente Web, solamente alcanza con un browser. Para el caso de Internet Explorer la mínima versión
soportada es I.E. 6.0. Para poder visualizar los Resportes PDF debe tener instalado el Adobe Acrobat
Reader.

Puesta en Producción Generador Java (War Deployment)

Introducción

Los servlets pueden ser ejecutados por motores de servlets (Tomcat, Resin, Jrun, etc.), o por
servidores J2EE (WebSphere, BEA Weblogic, etc.).

Configurar en forma adecuada los distintos motores de servlets o servidores J2EE, para ejecutar las
aplicaciones Web Java, tiene cierta complejidad; se necesita conocer en cual directorio deben ir los
servlets, en cual directorio deben ir los archivos adicionales (driver JDBC, classes adicionales, etc.) y
dónde colocar el contenido estático. Además, una vez que se hace funcionar todo en un ambiente
de prototipo hay que llevarlo a producción, es decir, configurar todo esto en el cliente. Entonces, el
generador Java provee el War Deployment, que es un “output processor” del Deployment Wizard,
que permite empaquetar en un sólo archivo, todo lo necesario, para la instalación y ejecución de
una aplicación Web Java, en los distintos motores de servlets, o servidores J2EE, de forma sencilla.

El War Deployment genera archivos con extensión .WAR (Web Archive Resource), los cuales son
básicamente archivos .JAR a los cuales se les cambia la extensión a .WAR. Estos archivos
empaquetan servlets, contenido estático, librerías adicionales y un archivo con formato XML, al cual
se le llama descriptor, que contiene cierta información de la aplicación Web como por ejemplo el
nombre de la aplicación, nombre de los servlets, mapeos, etc.).

Configuración

Para distribuir una aplicación Web, se debe ejecutar el Deployment Wizard, a través del Win
Developer Menu. Este, permitirá seleccionar los objetos Web main para los que se desee armar el
deployment, y luego automáticamente se abrirá el WAR Deployment para el armado del .WAR.
Dentro del .WAR se incluirá todo lo necesario para ejecutar el objeto Web main y todos los llamados
por él, más todos los archivos que se encuentren en el directorio indicado en la propiedad “Static
content directory seen form client”.

El WAR Deployment presenta estas opciones:

Location Aquí se debe seleccionar el Location para el cual se quiera armar el


.WAR. En caso de tratarse de un .WAR para una aplicación Web se
debe seleccionar el Location <Client>; el resto de los locations son
para el caso de querer distribuir las clases necesarias para ejecutar el
servidor de aplicaciones en un aplicación en 3 capas con protocolo
HTTP.

Deploy this Location Sirve para confirmar que se desea armar un .WAR para la Location
actualmente seleccionado.

Descriptor Type Aquí se debe seleccionar el motor de servlets que se va a utilizar y en


función de ello se arma el descriptor correspondiente (se profundiza
más adelante).

Web Application Name Este es el nombre que identifica a la aplicación Web. Para algunos
motores de servlets va a ser utilizado luego en la URL para invocar los
servlets.
Additional Libraries Aquí se deben agregar todos las librerías adicionales para ejecutar la
aplicación; el caso más común es el de los drivers JDBC.

Additional Files Esta es una estructura de directorios (que por defecto es vacía) en la
cual se puede agregar todo el contenido estático que se necesite para
ejecutar la aplicación.

Add Directory Permite agregar un directorio a la estructura de directorios de


Additional Files.

Remove Directory Permite borrar un directorio a la estructura de directorios de


Additional Files.

Add Files Permite agregar un contenido estático a los Additional Files en el


directorio seleccionado.

Remove Files Permite borrar un contenido estático antes agregado en los


Additional Files.
TAB Deployment Descriptor

En el tab “Deployment Descriptor” se edita el descriptor del .WAR a generarse, en formato XML.

Use Custom Deployment Al chequear esta opción se permite modificar el


Descriptor descriptor por defecto

Get Default Vuelve a obtener el descriptor por defecto

Validate Valida el XML del descriptor en caso de haberlo


modificado.
ANEXO: CONCEPTOS DE INTERNET

El propósito de este anexo es explicar una serie de conceptos sobre cómo funciona el Web.

Para esto es necesario conocer el significado de ciertos conceptos que vamos a usar frecuentemente
a lo largo del curso.

Como la intención de este capítulo es establecer el lenguaje común que utilizaremos a lo largo del
curso en lo que a Internet se refiere, trataremos de dar una visión intuitiva de los temas para no
aburrir al lector con detalles innecesarios.

Definiremos los siguientes conceptos:

 Internet

 WWW

 Página Web

 URL

 Protocolo HTTP

 HTML

 Aplicación Web

Tecnologías de las aplicaciones Web

o Servlets

o Asp.net

 Javascript

 Intranet

Comencemos entonces con definiciones básicas.


Internet

Internet es el nombre genérico que recibe la unión de todas las redes de comunicación a nivel
mundial. Se podría definir como una red global en la que se unen todas las redes que utilizan
protocolos TCP/IP y que son compatibles entre sí.

Al contrario de lo que se piensa comúnmente, Internet no es sinónimo de WWW.

Web o WWW

El World Wide Web (Web o WWW) es uno de los muchos servicios ofrecidos en la red Internet.

Es un sistema de información con interfaz gráfica, fácil de usar, que emplea la red Internet como
medio de transmisión y permite navegar para buscar documentos en Internet. Estos documentos,
como también los links que existen entre ellos forman un "Web" de información.

El Web permite saltar o "hyperlink" de una página Web (o Web page) a otras.

Puede pensarse en el Web como una gran biblioteca.

Los sitios Web (Web sites) son como los libros (libros electrónicos) y las páginas Web son como las
páginas específicas de estos libros. Estas páginas pueden contener noticias, imágenes, sonidos, 3D,
etc. Además pueden estar ubicadas en computadoras de cualquier parte del mundo.

Los libros electrónicos mantienen el concepto básico del libro, y además, brindan la oportunidad de
disponer de una estructura no lineal, la que permitirá, entre otras cosas, decidir el orden en el que
se desea recibir la información.

Algunos de los servicios disponibles en Internet aparte de la Web son el acceso remoto a otras
máquinas (SSH y telnet), transferencia de archivos (FTP), correo electrónico (SMTP), boletines
electrónicos (news o grupos de noticias), conversaciones en línea (IRC y chats), mensajería
instantánea (MSN Messenger, ICQ), transmisión de archivos, etcétera.

Página Web

Una página Web es un documento de la World Wide Web normalmente en formato HTML .

Una página Web típicamente, incluye texto, imágenes y enlaces hacia otros documentos de la red,
pudiendo además contener animaciones, sonidos, programas en Java, y cualquier otro tipo de
documento, por medio de plugins y otras tecnologías.

Actualmente las páginas Web ya no están únicamente enfocadas para ser visualizadas, sino que cada
vez son más dinámicas permitiendo que el visitante participe en ellas mediante menúes interactivos,
encuestas, votaciones, etc.
En el Web se distinguen básicamente dos tipos de páginas. Las páginas estáticas y las páginas
dinámicas.

Las páginas estáticas son las más sencillas, se crean usando un editor de páginas Web o bien
escribiendo directamente el código HTML.

Mientras que se ajustan muy bien a los requerimientos iniciales de hacer promoción y obtener
alguna venta ocasional, o bien la venta masiva de muy pocos productos, no se adecuan a la mayor
parte de las necesidades de la venta.

La desventaja que presentan es que el mantenimiento de las mismas implica un alto costo si se
realizan cambios con frecuencia, ya que una persona debe realizar las modificaciones
correspondientes.

Algunos ejemplos de estas páginas son: Información general, Marketing, Información similar a la que
se distribuye en folletos y documentos. Tienen la ventaja de brindar un acceso rápido y cómodo a
información y brindar direcciones de correo electrónico para información y soporte.

Las páginas dinámicas son creadas en el momento en que son referenciadas por el usuario. Si bien
tienen un estilo base, la información desplegada en las mismas es dinámica.

Son interactivas, ya que permiten que la página a visualizar pueda ser creada en base a la
información ingresada por el usuario. Por ejemplo, una consulta de los pedidos pendientes de una
orden de compra.

Las páginas dinámicas permiten interactuar con una base de datos, por lo que son una poderosa
herramienta para impulsar los negocios de la empresa.

Al utilizar este tipo de páginas, la actualización se realiza en forma automática, pues al acceder a la
página se accede a la base de datos con la información actualizada.

Algunos ejemplos que se prestan para una aplicación que utilice páginas dinámicas:
 Home Banking: operaciones varias sobre cuentas bancarias.

 Divulgación de información: acceso a información publicada por la empresa dependiendo


del rol. Por ejemplo sin costo en el caso de que la información sea pública y con costo para
aplicaciones en el que se exigen una validación de usuario.

 Comunicación con proveedores: para hacer órdenes de compra, verificar existencia de


stock.

 Intranet: Aplicaciones internas de la empresa. No pueden ser accedidas desde fuera.

 Venta directa: Compra de artículos desde la casa, similar a la compra por catálogo.

Las aplicaciones Web desarrolladas con GeneXus generan normalmente páginas dinámicas (porque
acceden a la base de datos).

Intranet

Una Intranet es una red de Área Local (LAN) privada empresarial o educativa que proporciona
herramientas vía Internet, las cuales tienen como función principal proveer lógica de negocios para
aplicaciones de captura, reportes, consultas, etc. con el fin de auxiliar la producción de dichos grupos
de trabajo; es también un importante medio de difusión de información interna a nivel de grupo de
trabajo. No necesariamente proporciona Internet a la organización; normalmente, tiene como base
el protocolo TCP/IP de Internet y, por ser privada, puede emplear mecanismos de restricción de
acceso a nivel de programación como lo son usuarios y contraseñas de acceso o incluso a nivel de
hardware como un sistema firewall que pueda restringir el acceso a la red organizacional.

Las aplicaciones GeneXus Web ejecutan tanto en Intranets como en Internet.

Aplicación Web

Una aplicación Web es aquella que los usuarios usan accediendo a un servidor Web a través de
Internet o de una Intranet.

Son populares debido a la practicidad del navegador Web como cliente “ligero”. Otra razón
importante de su popularidad es la habilidad para actualizar y mantener aplicaciones Web sin
distribuir e instalar software en miles de potenciales clientes.
Tecnologías
Para poder comprender mejor la tecnología escondida detrás de las aplicaciones desarrolladas para el Web,
es necesario aclarar algunos conceptos adicionales.
Los diferentes lenguajes utilizan diferentes tecnologías para generar las páginas dinámicas.

Inicialmente surgió la tecnología CGI y luego las Web Classes las cuales fueron utilizadas en versiones
anteriores de GeneXus por los generadores C/SQL y Visual Basic respectivamente para desarrollar
aplicaciones Web.

Actualmente, las tecnologías empleadas son los servlets y los asp.net por los generadores Java y .NET
respectivamente.

SERVLETS
La palabra servlet deriva de otra anterior, applet, que se refería a pequeños programas escritos en Java que
se ejecutan en el contexto de un navegador Web. Por contraposición, un servlet es un programa que se
ejecuta en un servidor Web.
El uso más común de los servlets es generar páginas Web de forma dinámica a partir de los parámetros de la
petición que envíe el navegador Web.

ASP.NET es otra alternativa de Microsoft para el desarrollo de aplicaciones Web. Esta tecnología se
desarrolló para la nueva plataforma .NET y se trata de una evolución de las ASP o Active Server Pages.
También en este caso se trata de aplicaciones que ejecutan en el servidor y envían el HTML resultante al
cliente. Los programas en el servidor son .dll’s que se invocan con extensión .aspx.

Las aplicaciones Web utilizan también código JavaScript para permitir mayores funcionalidades.

JavaScript
JavaScript es un lenguaje interpretado orientado a las páginas Web, con una sintaxis semejante a la del
lenguaje Java.
Se ha convertido en un verdadero lenguaje de programación que aporta la potencia de cálculo del navegador
para aumentar la usabilidad de aplicaciones Web con técnicas avanzadas como Ajax.

Ajax

Ajax es una arquitectura y no una tecnología. Ajax stands for Asynchronous JavaScript XML.

Incorpora:

 Basado en estándares de presentación usando XHTML y CSS;

 Despliegue e interacción dinámica usando Document Object Model;

 Intercambio y manipulación de datos usando XML y XSLT;

 Recuperación asincrónica de datos usando XMLHttpRequest;

 y JavaScript atando todo junto.

Ajax transforma la experiencia del usuario Web de una experiencia discontinua, donde los usuarios
deben esperar por la respuesta del servidor luego de cada solicitud de una página, en una
experiencia continua y unida, donde los usuarios interactúan con una interfase que rápidamente
responde, sin importar las conexiones al servidor que pasana ser invisibles al usuario..
URL

Básicamente una URL es una dirección Web.

Cuando visualizamos una página Web con Netscape, Internet Explorer o cualquier otro navegador,
los links (visualizados subrayados y generalmente en color azul), contienen información oculta que
apunta a la ubicación del recurso al que se hace referencia.

Se puede pensar una URL como un puntero estándar a un recurso Internet. El recurso podría ser un
gráfico, un sonido o simplemente un archivo de texto.

Las URL’s también pueden usarse para iniciar sesiones telnet, ftp y otros servicios.

En muchos casos es conveniente conceptuar una URL como el equivalente de estándar DOS para
nombre y path de un archivo.

De hecho una URL puede apuntar a un archivo en la máquina local y también puede apuntar a un
archivo específico de un directorio específico en una máquina remota.

Sintaxis

protocol://host/path/filename[?parm1,…,[parmn]]

protocol: Especifica el protocolo de acceso.

Ejemplos: file, ftp, http, telnet

host: Nombre del host al cual deseamos conectarnos.

Ejemplo: www.genexus.com

path/filename: Ubicación y nombre del documento en el servidor.

[parm1,...,[parmn]] Información opcional para consultas


Las URLs pueden definirse de forma absoluta o relativa.

Una URL absoluta empieza siempre por el protocolo, es seguido de dos puntos (":") y de una parte
específica del esquema.

Una URL relativa comprende sólo la parte específica del protocolo de una URL, o de algún
componente de seguimiento de aquella parte. El protocolo y componentes principales se infieren del
contexto en el cual aparece la referencia URL: es decir del documento que contiene la referencia.

Protocolo HTTP

El protocolo de transferencia de hipertexto es el protocolo usado en cada transacción de la Web


(WWW). El hipertexto es el contenido de las páginas Web, y el protocolo de transferencia es el
sistema mediante el cual se envían las solicitudes de acceder a una página Web (desde un Web
browser), y la respuesta de esa Web (desde un programa http Server), remitiendo la información
que se verá en pantalla. También sirve el protocolo para enviar información adicional en ambos
sentidos, como formularios con mensajes y otros similares.

El protocolo HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre
conexiones anteriores. Al finalizar la transacción todos los datos se pierden.

Está basado en el modelo cliente-servidor: un cliente HTTP abre una conexión y realiza su solicitud al
servidor, el cual responde generalmente el recurso solicitado y la conexión se cierra.

Se establecen 4 pasos básicos en el protocolo HTTP:

1) Conexión: Durante la conexión, el Web browser intenta conectarse al servidor. Si el browser no


logra la conexión en una determinada cantidad pre-configurada de tiempo, se desplegará un
mensaje de error y la consulta del usuario cancelará.
2) Solicitud: Una vez que la conexión al servidor HTTP ha sido establecida, el browser envía una
solicitud para el recurso deseado en el servidor.

3) Respuesta: Si el servidor encuentra el recurso, éste es enviado al browser y se pasa al último


paso. De lo contrario, un mensaje de error es enviado y se pasa al último paso.

4) Se cierra la conexión: Si el servidor retornó el recurso solicitado, el browser realizará la carga del
mismo y será desplegado al usuario.

El formato tanto de la solicitud como de la respuesta es el siguiente:

<Línea inicial>

Header-1: value-1

...

Header-n: value-n

<Cuerpo del mensaje (Opcional)>

La línea inicial es diferente en las solicitudes y en las respuestas.

En las solicitudes van tres campos separados por un espacio en blanco: "Método recurso
VersiónDelProtocolo". Por ejemplo: "GET /path/to/file/index.html HTTP/1.0".

La línea inicial de una respuesta tiene tres campos separados por un espacio: "versiónDelProtocolo
códigoRespuesta Mensaje". Por ejemplo: "HTTP/1.0 200 OK" o bien "HTTP/1.0 404 Not Found".

Los encabezados están normados en el protocolo, e incluyen, en el caso de una solicitud,


información del navegador y eventualmente del usuario cliente; en el caso de una respuesta,
información sobre el servidor y sobre el recurso. El cuerpo del mensaje contiene el recurso a
transferir o el texto de un error en el caso de una respuesta. En el caso de una solicitud, puede
contener parámetros de la llamada archivos enviados al servidor. Cabe señalar que los principales
navegadores Web no muestran al usuario los encabezados HTTP del recurso.

La característica de ser un protocolo sin estado, popularizó el uso de cookies, que son archivos que
se almacenan en el computador que puede leer un sitio Web al establecer conexión con él, y de esta
forma reconocer a un visitante que ya estuvo en ese sitio anteriormente. Gracias a esta
identificación, el sitio Web puede almacenar gran número de información sobre cada visitante,
ofreciéndole así un mejor servicio. (Más adelante profundizaremos en cookies.)

Existe también una variante de este protocolo, que brinda comunicaciones seguras en Internet
denominado https. También profundizaremos en este concepto más adelante en este curso.

HTML

Es el lenguaje en el cual están escritos los documentos del WWW. Es un subconjunto especializado
del lenguaje más general SGML (Standard Generalized Markup Language).

El lenguaje HTML está compuesto por una serie de códigos o tags ubicados dentro de un documento
ASCII, que son traducidos por un Web browser como Netscape, Internet Explorer, etc., en
instrucciones específicas para formatear el documento que se va a desplegar en la pantalla. Entre
dichos tags están incluidos los tags de hyperlinks, que permiten especificar enlaces hacia otros
recursos en el Web.

Un documento HTML consiste en texto que compone el contenido del documento y tags, los cuales
definen la estructura y apariencia del documento. La estructura de un documento HTML es simple.

Cada documento tiene un cabezal (head) y un cuerpo (body), delimitados por los tags <head> y
<body>. El cabezal es donde se indica un título al documento y donde se indican otros parámetros
que el browser podría utilizar en el momento de desplegar el documento. El cuerpo es donde se
coloca el contenido propiamente dicho del documento HTML. Esto incluye el texto a desplegar y
otros controles que indican al browser cómo desplegar el texto. Los tags también referencian
archivos de efectos especiales como imágenes y sonido e indican los hot spots que enlazan el
documento a otros documentos.

Un ejemplo de código HTML podría ser el siguiente:

<HTML>

<HEAD>

<TITLE>This is my first page </TITLE>

</HEAD>

<BODY>shows in a very <I>simple</I> way,the basic structure of an


HTML document.

</BODY>

</HTML>
el cual se vería en un browser de la siguiente forma:

Web Server
Un servidor web es un programa que implementa el protocolo HTTP (hypertext transfer protocol), el
cual está diseñado para transferir páginas web.

Un servidor web se encarga de mantenerse a la espera de peticiones HTTP llevada a cabo por un
cliente HTTP que solemos conocer como navegador. El navegador realiza una petición al servidor y
éste le responde con el contenido que el cliente solicita.

A modo de ejemplo, al teclear www.genexus.com en nuestro navegador, éste realiza una petición
HTTP al servidor de dicha dirección. El servidor responde al cliente enviando el código HTML de la
página; el cliente, una vez recibido el código, lo interpreta y lo muestra en pantalla. Como vemos con
este ejemplo, el cliente es el encargado de interpretar el código HTML, es decir, de mostrar las
fuentes, los colores y la disposición de los textos y objetos de la página; el servidor tan sólo se limita
a transferir el código de la página sin llevar a cabo ninguna interpretación de la misma.
Sobre el servicio web clásico podemos disponer de aplicaciones web. Éstas son fragmentos de
código que se ejecutan cuando se realizan ciertas peticiones o respuestas HTTP. Hay que distinguir
entre:

Aplicaciones en el lado del cliente:

el cliente web es el encargado de ejecutarlas en la máquina del usuario. Son las aplicaciones tipo
Java o Javascript: el servidor proporciona el código de las aplicaciones al cliente y éste, mediante el
navegador, las ejecuta. Es necesario, por tanto, que el cliente disponga de un navegador con
capacidad para ejecutar aplicaciones (también llamadas scripts). Normalmente, los navegadores
permiten ejecutar aplicaciones escritas en lenguaje javascript y java, aunque pueden añadirse más
lenguajes mediante el uso de plugins.

Aplicaciones en el lado del servidor:

el servidor web ejecuta la aplicación; ésta, una vez ejecutada, genera cierto código HTML; el servidor
toma este código recién creado y lo envía al cliente por medio del protocolo HTTP.

Las aplicaciones de servidor suelen ser la opción por la que se opta en la mayoría de las ocasiones
para realizar aplicaciones web. La razón es que, al ejecutarse ésta en el servidor y no en la máquina
del cliente, éste no necesita ninguna capacidad adicional, como sí ocurre en el caso de querer
ejecutar aplicaciones javascript o java. Así pues, cualquier cliente dotado de un navegador web
básico puede utilizar este tipo de aplicaciones.

Ejemplos de servidores web son Apache, IIS, Websphere.

Web Browser

Un navegador web o web browser es una aplicación que permite al usuario recuperar y visualizar
documentos de hipertexto, comúnmente descritos en HTML, desde servidores web de todo el
mundo a través de Internet.

Los navegadores actuales permiten mostrar o ejecutar: gráficos, secuencias de vídeo, sonido,
animaciones y programas diversos además del texto y los hipervínculos o enlaces.

El seguimiento de enlaces de una página a otra, ubicada en cualquier computadora conectada a la


Internet, se llama navegación; que es de donde se origina el nombre de navegador. Otra
denominación es explorador web inspirada en uno de los navegadores más populares el Internet
Explorer producido por Microsoft.

Ejemplos de otros navegadores utilizados son Nestcape Navigator, Firefox, Mozilla, etc..
Thin Client

Un Cliente Liviano (Thin client) es una computadora (cliente) en una arquitectura de red cliente-servidor
que tiene muy poca o ninguna lógica del programa, por lo tanto depende principalmente del servidor central
para las tareas de procesamiento.
La palabra liviano se refiere a lo pequeña que es la imagen de arranque, quizás no más grande que la
requerida para conectar a la red y arrancar un navegador web.