Curso Desarrollo de aplicaciones para

Internet
con GeneXus
Versin 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 versin 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 versin 9.0 de GeneXus. El curso consta de los
conceptos tericos necesarios para el desarrollo de una aplicacin web, as como la puesta en
prctica de los mismos en una aplicacin ejemplo. El desarrollo de esta aplicacin 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 aplicacin en paralelo (a medida que avanza captulo por captulo 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 aprobacin) un certificado de haberlo
realizado en modalidad no presencial, dirjase a nuestro sitio de capacitacin a distancia:
http://www.gxtechnical.com/capacitacionadistancia donde podr informarse y contratar estos
servicios.

INTRODUCCIN
En este captulo intentamos ofrecer una orientacin bsica sobre el curso y su logstica.

Incluye informacin acerca de la estructura del curso, cmo navegar a travs del mismo, cmo
comunicarse con un instructor y cmo obtener informacin de inters 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 captulos, cada uno de los cules tiene una introduccin que establece los
temas que sern abordados dentro del mismo y en algunos casos sugerencias acerca de cmo leerlo.
Para facilitar el aprendizaje, los conceptos tericos van acompaados de ejemplos prcticos y de
videos demostrativos, que complementan lo explicado, de manera tal que el alumno pueda obtener
una profunda comprensin de los temas tratados.

A medida que se avanza en los captulos se va desarrollando una aplicacin bien simple que pone en
prctica los conceptos ms 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 prcticos propuestos, luego.

Al finalizar el curso Ud. ser capaz de desarrollar aplicaciones para Internet de la vida real utilizando
la metodologa 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 algn tema en particular, o profundizar en detalles no considerados en
una primera instancia.

Los primeros ocho captulos constituyen el corazn del curso, y deben ser seguidos con
detenimiento. Estos captulos transmiten la esencia del desarrollo de aplicaciones para Internet con
GeneXus. Los dems captulos tienen distintos grados de importancia, pero podran ser
eventualmente omitidos en una primera lectura si lo que se busca es comenzar rpidamente a
desarrollar este tipo de aplicaciones.

Cualquier sugerencia que desee realizar, con gusto la recibiremos en la siguiente direccin de correo
electrnico 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 versin 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 comprensin aceptable ser importante.
Las diferencias inherentes a las versiones de GeneXus pueden dificultar tambin la comprensin del
curso por lo que se recomienda realizar una actualizacin previa a la versin 9.0.

El segundo de los requisitos, si bien no es excluyente, debe alcanzarse antes de comenzar el curso.
Para ello se incluye un captulo como anexo, de Introduccin a Internet que establece la

terminologa y conceptos necesarios para entender este ambiente. Quin no cuente con dichos
conocimientos, deber comenzar por ese captulo y no continuar hasta no haber asimilado todos los
conceptos all vertidos.

Requerimientos computacionales
Debe contar con GeneXus versin 9.0 full. En el presente curso desarrollaremos una aplicacin 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 aplicacin 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 prctica del curso utilizndola 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 caractersticas propias, y
habrn configuraciones particulares que deber realizar de forma distinta a la mostrada.

En el manual de instalacin 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 aplicacin 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 instalacin 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 continuacin 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 ms 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: resolucin 800x600 o mayor, con 256 colores
Software Requirements

Microsoft Windows con tecnologa 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

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

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

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

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

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-94B85A0F62BF7796&DisplayLang=en

Puede bajarlo de nuestro Download Center:

http://www.gxtechnical.com/main/hdcenter.aspx?2,5,36,1183

Necesitar contar con algn reproductor de archivos multimedia para poder ver los videos incluidos
en el curso, que son archivos de extensin AVI.
El video debe reproducirse con el mismo tamao 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 mquina 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 mquina en la que se vayan a visualizar los videos del curso.

En el documento Problemas con la reproduccin de los videos tiene la solucin a algunos de los
problemas que se le podran presentar al intentar reproducir los videos incluidos en el curso. All se
indica tambin de dnde se pueden bajar reproductores en forma gratuita.

Recomendamos una resolucin de pantalla de 800x600, para poder ver los videos correctamente.

Comunicacin con un docente y examen final

En caso de estar interesado en contar con la ayuda de un docente a quien se le podrn
consultar las dudas que vayan surgiendo, y dar un examen final de forma tal de obtener, en
caso de aprobacin, un certificado de haberlo realizado en modalidad no presencial, dirjase a
nuestro sitio de capacitacin a distancia: http://www.gxtechnical.com/capacitacionadistancia
donde podr contratar estos servicios e informarse acerca de los mismos.
Cmo 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 informacin completa de los temas tratados.

Una forma de alcanzar estos objetivos sera postergar la complejidad y/o los detalles para captulos
ms avanzados dentro del curso. Si bien de esta manera lograramos los dos objetivos anteriores, un
mismo tema estara desperdigado en muchos captulos, dificultando as una consulta posterior.

Con la intencin 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 estn tan auto-contenidos como sea posible, de modo de facilitar la consulta posterior.

En la mayora de los casos estos objetivos se tornan contrapuestos, por lo que buscamos una
solucin de equilibrio.
Intentamos dejar los temas lo ms encapsulados posible en captulos, sin perder de vista los
aspectos didcticos. Para ello, establecimos una simbologa que incluimos en los documentos para
orientar visualmente al lector discriminando qu partes de la documentacin pueden excluirse en
una primera lectura, qu partes son de fundamental importancia y deben convocar toda su
atencin, etc. Asimismo establecimos una simbologa anloga a nivel del ndice rbol- del curso. En
las tablas que aparecen al final de esta pgina listamos estos smbolos y sus significados.

Es as que el curso se divide en captulos, cada uno de los cuales contiene una introduccin que
resume los puntos que se tratarn dentro del mismo, brindando sugerencias al lector acerca de
cmo leerlo. Los captulos contienen documentos de distintos tipos, as como subcaptulos.

Este curso est pensado para ser seguido fundamentalmente de manera secuencial. Algunas veces
se podrn producir desviaciones a ese orden, tanto por decisin del lector, como por alguna
sugerencia explcita dentro del curso. Normalmente se comienza con la introduccin de un captulo,
y luego se pasa a leer el documento que le sigue en orden dentro del ndice.

Si bien los documentos estn ordenados de modo de ser ledos secuencialmente, pueden, no obstante,
contener links que los relacionen con otros documentos de otras partes que estn ms adelante o ms atrs
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 especfico. La razn
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 atrs s pueden utilizarse en la primera lectura, pues posibilitan refrescar o
recordar temas, conceptos, ideas, etc. vistos recientemente y an 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 atrs.

Lea las tablas de smbolos que figuran a continuacin para entender el significado de los smbolos
que aparecern a lo largo de todo el curso.
Tabla de smbolos de los documentos

Smbolo

Significado
Denota que lo que se encuentra en esa seccin es de fundamental importancia

y debe prestarse especial atencin a lo que all se dice. Generalmente se trata

de conceptos de gran relevancia. Si el smbolo se encuentra al principio del
documento, aplica a todo el documento. Si por el contrario aparece delimitado
por lneas, aplica solo a lo delimitado por ellas.
Es una referencia a un pie de pgina. Se incorpora en la mitad de un texto
para establecer un link a dicho pie de pgina.
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 aplicacin de
ejemplo.

Desarrollo de una aplicacin

Como el propsito de este curso es que el alumno pueda desarrollar aplicaciones de la vida real para
Internet utilizando GeneXus, elegimos una aplicacin de ejemplo bien simple para ir poniendo en
prctica a lo largo del curso los conceptos que se vayan incorporando.

En el Captulo 2 se presenta el primer paso en el desarrollo de la aplicacin, que ir creciendo a lo

largo de los captulos 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 continuacin
de un video demostrativo el alumno deber reproducir lo visto.

En algunas ocasiones se le indicar explcitamente al alumno luego de un video alguna variante al

mismo, para que no lo repita exactamente, sino con alguna modificacin.

La aplicacin que hemos elegido es una simplificacin de una aplicacin real: un sistema para una
agencia de viajes que permite la bsqueda de pasajes y servicios tursticos.

A grandes rasgos: la agencia contar con un sitio en Internet donde permitir a los clientes realizar
bsquedas de destinos, los vuelos existentes y los diferentes servicios brindados. Incluir tambin
todo el back-end para el mantenimiento de la informacin relacionada.

Convenciones para la documentacin

En los documentos de este curso se utilizan algunas convenciones tipogrficas:

Todos los nombres de atributos y variables aparecern en cursiva.

Los nombres de objetos GeneXus aparecern entrecomillados, con la primer letra en mayscula y el
resto en minscula.
Los nombres de tablas aparecern sin comillas y en mayscula.
Los nombres de ndices estarn tambin sin comillas y en mayscula.

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 inters

Con el objetivo de brindar a los desarrolladores una fuente nica de informacin potenciada con una
ingeniera de bsqueda que les permita acceder rpida y fcilmente a la informacin tcnica
(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
informacin tcnica.

Puede ser consultada online o puede ser utilizada en forma local mediante una sencilla instalacin.
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 segn el nivel de su usuario. En el Download Center
encontrar productos, cursos, ejemplos, manuales, release notes, GXDL, utilitarios, technical papers,
etc.

Temas que no sern abordados en este curso

A continuacin mencionaremos los temas que estn relacionados con el curso para que el lector
pueda recurrir a la GXDL en caso de tener inters en abordarlos por su cuenta.

Ellos son:

Introduccin a Business Intelligence (Data Warehousing)

GXFlow (Aplicaciones de workflow)

Problemas con la reproduccin de los videos

Los videos son archivos con extensin .avi. Debe configurar su mquina 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 mquina 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 mquina. Esta accin solo debe realizarse una vez.

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

Tambin puede ser descargado del sitio web:

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

Si an 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 aplicacin que lo est reproduciendo el video se ver borroso. Los videos
deben reproducirse con su tamao original, sin ser escalados.

Problemas con la reproduccin con Media Player

Si el video se est reproduciendo en Media Player 7, 8 o 9 y ud. no logra ver la imagen ntidamente,
el problema probablemente sea de que el video no se est reproduciendo al 100% del tamao
original. Es un problema que tienen estas versiones del Media Player en sus skins mode

predeterminados. Por defecto escalan los videos durante la reproduccin a un tamao menor,
dando como resultado la degradacin de la calidad de la imagen. Muchas veces el seleccionar
View/Video Size/100% no tiene el menor efecto.

La solucin es configurar el Media Player para que no escale las imgenes. Hay varias formas de
hacerlo:

1.

Configurar Media Player para que utilice Classic skin. Presionar el botn 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 opcin es utilizar el TechSmith Camtasia AVI Player, que puede bajarse libremente de:
http://www.techsmith.com/products/studio/player.asp. En este caso no habrn problemas de
escalado.

INTRODUCCIN
En este captulo 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 aplicacin para una agencia de viajes
que iremos desarrollando gradualmente a lo largo del curso.

Adems, entraremos a GeneXus para dar los primeros pasos en el desarrollo de una aplicacin 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 continuacin se puede observar un esquema simplificado de la
topologa 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 pginas Web.
Este servidor puede ser tambin el servidor de base de datos, o se puede tener un servidor
especfico para realizar esta tarea.

Los usuarios de Internet tendrn acceso a las pginas que sean pblicas y podrn acceder a los datos
almacenados en la empresa a travs de pginas dinmicas.
Por otro lado, los usuarios de la empresa (Intranet) podrn acceder a las pginas pblicas y a las
pginas 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 podrn ejecutar con un servidor Web Windows, UNIX o ISeries y podrn 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 decisin del generador a utilizar se tomar principalmente por los requerimientos adicionales o
interacciones con otras aplicaciones, ya que el look and feel de la aplicacin 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 aplicacin con GeneXus es
crear la base de conocimiento que representar e implementar al sistema. Lo mismo ocurre
cuando la aplicacin 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 tambin, 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 podrn definir en GeneXus los objetos para desarrollar aplicaciones
Web (Web Panels y Transacciones Web).

En modelos de Prototipo o Produccin con ambiente Web, el tipo de objeto que se propone al crear
un nuevo objeto es Web Panel.

Prctico: Creacin 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 versin 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 prcticos 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 creacin del modelo.

Deber elegir un nombre para el modelo. El nombre elegido en el desarrollo de la aplicacin que Ud. ver
en los videos es AgencyNet pero Ud. puede elegir el que desee.
Adems, deber elegir Web como User Interface. Tambin 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 ms informacin.
4.
5.
6.
7.
8.

Al realizar el impacto, GeneXus nos informar de las nuevas tablas que crear en la base de datos.
Confirme y ejecute dicha creacin.
Ahora, est en condiciones de copiar los datos que se encuentran en Agency.bak del cd1.
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.
Compile el Developer Menu2 y ejecute por ejemplo la transaccin Country.
Se recomienda utilizar un directorio virtual especfico para el prctico. Por ejemplo:
http://localhost/practico. De esta forma estamos definiendo un directorio virtual especfico para
nuestra aplicacin 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.

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 pgina 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 diseado siguiendo el estndar de las herramientas
Microsoft Office, lo que permite que los usuarios puedan utilizarlo rpidamente y en forma intuitiva.
Es un editor orientado a pginas, lo que significa que la posicin de los controles que se encuentran
dentro del form en diseo es relativa al tamao de la ventana que contenga la pgina.
Este editor provee el manejo de tablas, caracterstica fundamental a la hora de disear pginas Web.
Esta facilidad habilita al usuario a disear mejores pginas, as como le permite manipular la
alineacin de los controles dentro de los objetos Web.

Complementando este editor, existe el Editor de Temas (que veremos ms 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:

Imgenes

Grid

Texto

Text Block

Tabla

Grid Free Style

Error viewer

Web Components

Embedded Pages

Ms 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 insercin de los controles. A continuacin
se documentan las operaciones que se pueden realizar con cada una de ellas, as como las
caractersticas de los controles disponibles en objetos Web.

Barra de herramientas Pallete

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

Select

Habilita la seleccin de uno o ms

controles.

Attribute
Text
Hyperlink

Inserta un hipervnculo en el Web form. Se

despliega un dilogo, desde el cual se
podr configurar el hipervnculo.

Line

Opcin deshabilitada en ambiente Web

Rectangle

Opcin deshabilitada en ambiente Web

Table
Grid
Free Style Grid
Button

Image

Inserta una imagen en el Web form. Se

despliega un dilogo, desde el cual se
selecciona la imagen a insertar.

Tab Control

Opcin deshabilitada en ambiente Web

Print Block

Solo habilitada en objeto Reporte

ActiveX

Opcin deshabilitada en ambiente Web

Web Component
Embedded Page

Barra de herramientas Formating

Esta barra de herramientas permite realizar las operaciones estndares de edicin 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 diseo
los bordes de las tablas an cuando stos no se vean en ejecucin.
Otra opcin 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 transaccin las secciones disponibles son:

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

Al hacer clic sobre esta seccin se puede disear la pantalla del objeto Web, es decir se insertan los
controles y se visualiza el aspecto que va a tener en ejecucin el mismo.

Si se presiona el botn derecho del mouse dentro del formulario del objeto Web, adems de la
opcin Properties (que permite configurar las propiedades del form) se visualizan dos opciones:
View Source y Edit HTML Source.

Al seleccionar la opcin View Source se abre una ventana donde se puede visualizar el cdigo
HTML que se va a generar al ejecutar dicho objeto. Al cerrarla, se vuelve al formulario del objeto
Web.
Si se selecciona la opcin Edit HTML Source, se puede modificar el cdigo HTML o agregar cdigo,
de forma tal que el cambio se mantiene en el objeto y se genera posteriormente. En este caso, el
cdigo se visualiza dentro de la ventana del objeto Web y para volver al formulario, es necesario
volver a presionar el botn derecho del mouse y seleccionar la opcin Edit Web Form.

La opcin Edit HTML Source se usa para cualquier caso en el que sea necesario agregar cdigo
HTML manualmente, por ejemplo, agregar cdigo 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 disea el objeto Web sin requerir editar el cdigo HTML, pero en caso de
necesitarse esta es la forma de hacerlo.

Controles y sus propiedades

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

Es importante resaltar que la asignacin 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 vara es el costo de mantenimiento
posterior.

En el caso de asignar las propiedades directamente en el control, estas solamente aplicarn al

mismo.

Esta asignacin puede hacerse en tiempo de diseo y para algunas de las propiedades pueden
modificarse en tiempo de ejecucin (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 diseo, se

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

En este captulo se ver una introduccin al objeto Tema y el Editor de Temas, y ms 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
podrn ser asociados a alguna clase del Tema.
Al asociar una clase a un control ste pasa a heredar la configuracin 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.

Cmo 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 especficamente del objeto. Este es el orden tambin 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
diseo (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 estn asociados al mismo Tema.

Cmo asociar una clase a un control

La forma de asociar una Clase de un Tema a un control, es a travs de la propiedad Class. La propiedad
Class es una propiedad del control, y es posible tambin cambiarla en tiempo de ejecucin.

Cmo modificar un tema

Los temas se modifican utilizando un Editor especial, que es de libre distribucin y puede ser
ejecutado independientemente de GeneXus. Esto permite a los diseadores del sitio Web trabajar
en el diseo 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 dinmica (en ejecucin) se puede modificar el mismo. Para insertar un Text
Block, se puede presionar el botn

de la barra de controles disponibles.

Edicin 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 (botn derecho, properties).
que facilita el trabajo con
En la barra de herramientas para el form HTML se incluye un botn
controles de tipo Text Block. Al presionar el botn mencionado, se visualizan los TAGs que lo
definen permitiendo detectar cualquier problema en diseo.

Propiedades del control Text Block en diseo

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 travs de la
propiedad Default HTML Format(Textblocks only) del modelo de diseo.
Fill
ForeColor

Font
OnClickEvent
ReturnOnClick

Propiedades del control Text Block en ejecucin

Adems de las propiedades detalladas anteriormente, se pueden modificar las siguientes

propiedades de los Text Blocks en tiempo de ejecucin:

BackColor
Visible
Enabled
Link
LinkTarget
Format

Propiedades del control textblock en los Temas

Adems 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: Creacin 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 contrasea y validaremos la informacin
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 contrasea, definiremos dos variables en el
form.

Para que no se visualice lo que escribe mientras ingresa la contrasea, 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 tambin un botn que tendr asociado el
evento Login donde ms adelante se realizar la lgica de validacin del usuario.

Vea la demostracin aqu

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

En ejecucin, el Web Panel se ver como lo siguiente:

Si observamos bien el Web Panel, las variables de ingreso de datos no estn 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 dilogo
correspondiente) GeneXus automticamente incluye una tabla para alinear los controles.

En el prximo punto veremos cmo alinear los controles del Web Panel insertndolos 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 prcticos,
existe un Tema de nombre Default. Este Tema se crea automticamente al crear una nueva base
de conocimiento.

Observe tambin 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 estn 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 demostracin veremos los pasos seguidos para modificar el Tema Default y el
efecto de esos cambios sobre el Web Panel que hemos creado en este captulo.

Es posible tambin definir la configuracin de los HTML Tags involucrados en el HTML de la Web
Page. En el curso, a medida que se vayan realizando los ejercicios prcticos, se explicarn ms
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 diseo esttico 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 diseo de los mismos.

Agregar tabla

Para insertar una tabla se debe utilizar el botn

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 varan dependiendo de la seleccin realizada, es decir que las propiedades
disponibles para una celda tienen alguna variacin con respecto a las disponibles para la tabla o la
fila. A continuacin 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 botn derecho del mouse. Seleccionar la opcin Properties del men
pop-up que se despliega.

Otra forma de editarlas es presionando el botn derecho del mouse estando posicionado en
cualquier celda de la tabla, y despus ir a la seccin de Table. En este caso, se podrn editar adems
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 ejecucin, pero podr verse en diseo usando el

botn

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 dilogo de propiedades seccin ROW-, se pueden asignar valores a
propiedades para una fila particular dentro de las tablas. Estos valores tendrn preferencia a los
asignados para la tabla en general.
Las propiedades de las filas, son algunas de las propiedades de las tablas, ms 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 continuacin:

Identifier

Tooltiptext

Align

VerticalAlign

Background

Backcolor

Bordercolor

Height

Width

Colspan

Rowspan

Propiedades de tablas en los Temas

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

configurar otras propiedades que permiten definir otras caractersticas a las tablas. Ver Clase Table

Demo: Creacin de una Tabla

Como decamos anteriormente, para alinear los controles debemos definir una tabla en el form.

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

Podramos tambin, seleccionar nuevamente las variables para que GeneXus automticamente
agregue la tabla con las variables y las descripciones correspondientes.
Luego, debemos posicionar el Mouse en la ltima celda y con el botn derecho seleccionar la opcin
Insert Row para agregar una nueva fila donde incluiremos el botn.

Vea la demostracin aqu

Ahora, compruebe en ejecucin la alineacin de los controles.

Ms adelante, veremos ms casos prcticos del uso de las tablas.

Demo: Cmo darle un mensaje al usuario

En este momento ya tenemos implementada nuestra pantalla donde el usuario final va a ingresar su
usuario y contrasea.
Tenemos que verificar en el evento Enter del botn 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 informndole que se debe registrar como
nuevo usuario.

En un Work Panel normalmente lo haramos utilizando el comando msg(), y se abrira una nueva
ventana con el mensaje. En los objetos Web utilizamos el mismo comando msg(), la diferencia est
en dnde se mostrar dicho mensaje, en una caja de texto y/o en el control Error Viewer (como
veremos ms 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 botn Login y agregar el comando msg() para desplegarle al cliente el mensaje que
corresponda.
Haga clic aqu para ver la demostracin

Orden de precedencia de las propiedades

Las propiedades de un control se pueden configurar en:

Ejecucin (cambiando el valor de la propiedad mediante cdigo GeneXus).

Diseo (en las propiedades del control mismo, seleccionando el control y con botn
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 travs de la propiedad Class del mismo. La propiedad Class se
puede asignar a un control tanto en tiempo de diseo como en ejecucin. Para poder asociar
una clase determinada a un control en tiempo de diseo, es necesario que el Tema en el cual
est definido la clase se asocie al objeto que contiene el control. La asociacin de un Tema a
un objeto se hace a travs 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.

Ejecucin

2.

Diseo

3.

Tema

Es decir que si una propiedad de un determinado control est configurada en el Tema, y tambin en
diseo; la configuracin dada en diseo tiene precedencia sobre la del Tema; y la dada en ejecucin
sobre la de diseo.

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 extensin .CSS (Cascading Style Sheet).

Cambiando el Tema asociado al objeto que se desea modificar, basta con llevar el CSS a produccin y
no es necesario generar/compilar nuevamente la aplicacin. Esto ltimo s resulta necesario de
hacer en caso de configurar las propiedades en tiempo de diseo.

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 dilogo 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 diseo.

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 opcin
Properties del men.

Esta asignacin 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 diseo y algunas de ellas tambin pueden modificarse en tiempo de ejecucin
(programando los eventos del objeto).

Propiedades en Tiempo de Diseo

Las propiedades del form que pueden asignarse son las que se muestran en el siguiente dilogo.

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 mrgenes

TopMargin

BottomMargin

LeftMargin

RightMargin

Propiedades del form HTML en tiempo de ejecucin

En ejecucin se pueden modificar las siguientes propiedades del Form:

BackColor

Background

Caption: El caption del form se transforma en el ttulo de la ventana. Por defecto, tiene
el nombre del objeto Web. Esta propiedad solamente puede modificarse en tiempo de
ejecucin.

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 estn en GeneXus.

En el caso de que una propiedad est asignada en el control (en diseo o en ejecucin) 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 botn derecho del mouse aparecen sus propiedades para ser
modificadas. Esta modificacin se considera realizada en tiempo de diseo.

Para modificar las propiedades de estos controles en ejecucin, es necesario programarlo en algn
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 aplicacin.

Si en el dilogo de seleccin de atributos o en el dilogo de seleccin de variables se seleccionan

varios a la vez, stos se insertan en el formulario dentro de una tabla, simplificando as la tarea de
alineacin.

Propiedades del control Edit en diseo

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 segn el tipo de control).

Dentro del grupo Appearance se encuentran todas las propiedades que aplican al aspecto
del control. Se detallan a continuacin:

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 continuacin:
ReadOnly
EnableHistory
EmptyAsNull
IsPassword
InputType: Esta propiedad permite sustituir lo que el usuario digita en un atributo por un valor ms
amigable. Si esta propiedad toma el valor Descriptions, permite que el usuario digite la descripcin
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 tambin, 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 explcitos (el usuario manualmente hace un pedido para
que se calculen las sugerencias y se le muestren). La actualizacin de la lista es asincrnica y los
tiempos de clculo dependen de la calidad de la conexin. 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 Ejecucin

Adems de las propiedades vistas anteriormente, existen otras que permiten modificar en tiempo de
ejecucin 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 segn el Tipo de Control

Hay otras propiedades, especficas segn el tipo de control que se utilice.

COMBO BOX
Las propiedades a nivel de diseo que aplican son:

Attribute
BackColor
ForeColor
Fill
Font
ReadOnly

Las propiedades a nivel de ejecucin son:

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

NOTA: Alineacin 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 an cuando el combo sea sobre un
atributo numrico los valores que se muestran en el combo son de tipo carcter.

RADIO BUTTON, CHECK BOX

Las propiedades a nivel de diseo que aplican son:

Attribute
BackColor
ForeColor
Fill
Font

Los radio button tienen tambin la propiedad Radio Direction que permite indicar si las opciones del radio
button se desplegarn en forma vertical u horizontal.
Las propiedades a nivel de ejecucin 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 tambin en el Tema. La clase predefinida Attribute del Editor de
Temas rene 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 ms informacin referirse a
Clase Attribute.

Propiedades de variables de tipo bitmap en diseo

Las propiedades que se detallan a continuacin 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 ejecucin

A las variables de tipo bitmap se le pueden modificar las siguientes propiedades en tiempo de ejecucin:

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

ejecucin 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.

Mtodos de los Controles

Los mtodos 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
"visualizacin".

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 vlida: 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 botn en el formulario se puede seleccionar el
disponibles.

de la barra de controles

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

Propiedades de botones

Las propiedades de los controles de tipo Button que pueden modificarse en diseo son:

ControlName

Class

OnClickEvent

Caption

Font

ForeColor

BackColor

BorderWidth

BorderColor

En ejecucin se pueden modificar todas estas propiedades (excepto la control name) del botn y adems
las siguientes:

Enabled

Internal Name

Visible

Propiedades de botones en temas

Adems de estas propiedades, en la clase Button de un tema se pueden setear otras propiedades que
permiten definir otras caractersticas a los botones. Ver Clase Button.

Tamao de botones

El tamao del botn queda determinado por el texto ingresado en la propiedad Caption del mismo.

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

Cmo asignar un evento a un botn

Para asignar un evento a un botn se puede ingresar directamente el nombre del evento (entre comillas
. Al utilizar este selector de eventos se visualiza el siguiente dilogo, con
simples) o hacer clic al botn
los eventos disponibles, habilitando al usuario la creacin un nuevo evento (mediante el botn New).

INTRODUCCIN
Los web panels al igual que los work panels son objetos GeneXus que permiten al usuario en tiempo
de ejecucin, realizar interactivamente consultas a la base de datos a travs de una pantalla.

El trmino 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 continuacin los datos que concuerden
con los mismos. Adems, sobre los datos consultados, el usuario podr realizar distintas acciones,
como veremos.

Los web panels no permiten la actualizacin de la base de datos, sino slo consultarla.

El objetivo primordial de los web panels es la definicin 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 ms.

En este captulo 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 ms
parmetros para filtrar por igualdad por los mismos, la forma ms directa y sencilla de resolverlo es
declarando en la regla parm del objeto, a dicho(s) parmetro(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
parmetro el cdigo del cliente del cual se deben mostrar sus facuras, la opcin ms directa y
sencilla para definir el filtro es en la regla parm, recibiendo al cdigo de cliente en el atributo
mismo: parm(CliCod);

De esta forma, GeneXus entender automticamente 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 condicin de
filtro: CliCod=&CliCod; Recordemos que cuando se reciben variables en la regla parm, GeneXus no
hace nada automticamente con ellas, por lo tanto el analista deber definir condiciones de filtro
explcitamente utilizando a las variables como desee.

Cuando en cambio, se trata de web panels que no reciben parmetros, y que las condiciones de
filtro deben definirse explcitamente (por ejemplo involucrando a variables cuyos valores son
ingresados por el usuario en tiempo de ejecucin 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

informacin especfica de este tema.

Eventos en Web Panels

En los web panels se utiliza la programacin dirigida por eventos, que es un estilo de programacin
en el cul se define cdigo que permanece ocioso, hasta que suceden eventos provocados por el
usuario o por el sistema, que provocan que el cdigo definido se ejecute.

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

El cdigo que se le puede asociar a un evento, se escribe con estilo procedural; y cuando el evento
se produce, el cdigo 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 utilizacin de los mismos.

Orden de los datos en un Web Panel

Para definir en un web panel que una consulta se efecte ordenando por cierto(s) atributo(s), y por
ende que los datos extrados de la consulta se muestren ordenados con dicho criterio, se debe hacer
clic con el botn derecho del mouse sobre el grid, y seleccionar el tem Order en el siguiente men
pop up:

A continuacin, se presentar el siguiente dilogo para que se ingrese por qu atributo(s) se desea
ordenar:

Definir esto es equivalente a definir la clusula order en el comando for each , por ejemplo: que
para ordenar en forma descendente por un atributo se debe encerrar al atributo entre parntesis (),
o que se crean ndices temporales cuando no existe un ndice fsico por los atributos por los cuales se
indica ordenar.

Solamente si el form del web panel no tiene ningn grid, y se necesita definir un orden especfico para la
consulta, se contar con la posibilidad de definir en la seccin 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

informacin especfica de este tema.

Reglas en Web Panels

En el objeto work panel, las reglas ms 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 lnea de
cada grid que exista en la pantalla. Los atributos con Visible en False, no se ven en el grid final pero tambin
se "guardan" aunque solamente para cada lnea 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 slo para el
grid en que fueron definidos. Esto redunda en menos cdigo HTML a enviar al Browser y, en consecuencia,
mejor performance.

Algo similar ocurre con la regla Order, ya que en caso de tener mltiples 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 nmero 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 ejecucin del programa.

Comandos en Objetos Web

A continuacin 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 ejecucin de dicha
llamada cancelara 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 pginas estticas o redireccionar a una
URL. Este comando puede ser utilizado dentro de cualquier evento de un objeto web con excepcin
del evento Load. El resultado de la utilizacin de este comando es el redireccionamiento en forma
automtica 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 parmetros que recibe la URL. El pasaje de parmetros es opcional.

Ejemplo:

Event ENTER
Link(http://www.ARTech.com.uy)
Endevent

Load

El comando Load es anlogo al resto de los objetos GeneXus.

Refresh

El comando Refresh vuelve a cargar la pgina, teniendo el mismo efecto que presionar la tecla de
funcin F5 del browser. La pgina 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 botn 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 mtodos Load de las grillas. Tampoco puede ser ejecutado en subrutinas llamadas directa o
indirectamente por el evento Load o mtodos 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 mtodo Set en un tipo de datos WebSession y luego se ejecuta el comando Return el valor de
la(s) cookie(s) se establece correctamente.

Comparacin 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 mltiples usos, cuya programacin est dirigida por eventos. De todos modos, hay algunas
diferencias causadas principalmente por el esquema de trabajo en Internet.

Tabla Base

La determinacin de la tabla base de los Web Panels es anloga a la determinacin 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 despus de presionar algn botn 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 ningn 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).
Adems, deber estar en el form despus 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
despus de la grilla.

Disparo de frmulas stand alone

En un Web Panel existen frmulas que pueden ser gatilladas antes del evento Start y otras que
deben gatillarse luego del mismo evento.
Las frmulas que se gatillan antes del evento Start son aqullas que slo dependen de los
parmetros que llegan al programa (mediante la regla parm())
Las frmulas que se gatillan despus del evento Start son aqullas que dependen de atributos o
variables instanciados (va asignacin, Call, etc.) en el evento Start.

Propiedades

En los Work Panels las propiedades ms utilizadas son las correspondientes al grupo Loading (Load
Records, Load at Startup, Automatic Refresh y When to Refresh) para manipular la visualizacin 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 continuacin de la apertura del form en tiempo de ejecucin (lo que
se corresponde con el valor Yes de la propiedad Load at Startup).

En las grillas de los objetos Web para resolver la visualizacin de grandes cantidades de registros se
dispone de la paginacin automtica.

Determinacin 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
implcito asociado a l.

Para determinar si un Web Panel tiene tabla base y en caso afirmativo cul 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 parmetro

los atributos mencionados en las condiciones globales del Web Panel

stos actan como filtros una vez determinada la tabla base.

Web Panel con N tablas

Cuando un Web Panel contiene ms 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 determinacin 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 determinacin de la tabla base de
ninguno de los grids, pero debern 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 navegacin resultante, un warning advirtiendo de esta situacin.

Los atributos utilizados en los eventos del Web Panel tampoco participan en la determinacin de la
tabla base de ninguno de los grids. Los atributos que se incluyan en los eventos fuera de comandos
for each, debern 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 tursticas y los servicios provistos de una ciudad como tambin 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 estn 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*
CitiName)

(TouristAttractionId*
TouristAttractionCatId)

TourismSerivceCatId
CountryId
CityId
(TourismServiceCatTypeId*
TourismServiceCatTypePrice)

Flights

TourismServiceCategory

TouristAttractionCategory

FlightId*

TourismServiceCatId*

TouristAttractionCatId*

DepartureCountryId
DepartureCityId

TourismServiceCatDsc
TourismServiceCatImage
(TourismServiceCatTypeId*

ArrivalCountryId
ArrivalCityId
(FlightCategory

TourismServiceCatTypeDsc)

TouristAttractionCatDescription
TouristAttractionCatImage

FlightPrice)
Users

UserId*

UserNickName
UserPwd
UserLastName
UserFirstName
UserName
UserEmail
UserAddress
UserPhone
CountryId
CountryName
CityId
CityName

El objeto en ejecucin deber verse como el siguiente:

En estos captulos iremos adquiriendo los conocimientos necesarios para implementarlo.

Nos centraremos primero en la parte principal de bsqueda.

All programaremos la paginacin a pedido en los grids, cargando 5 registros a la vez y pudiendo
filtrar por pas y ciudad. En cada grid, pondremos links a otros Web Panels con informacin ms
detallada.

Para hacer esto crearemos dos variables en la parte fija del Web Panel, donde el usuario indicar los
filtros correspondientes para el pas 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 rpido.

Para esto, se recomienda que los usuarios no deban ingresar (ni recordar!) cdigos sino que puedan
ingresar los nombres y que el dilogo 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 dinmico. Los valores posibles sern el atributo
CountryId y las descripciones sern el nombre del pas (CountryName).
Adems, utilizaremos un valor vaco que indique que no est seleccionado ningn pas. 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 tambin como combo dinmico con
un valor vaco de texto Select a City.

Recordar que al seleccionar ms de un atributo, GeneXus crea una Tabla para alinear los
controles. Sin embargo, el orden elegido no ser el deseado por lo que debern moverse los
controles.

Para que el combo muestre las ciudades del pas elegido previamente, es necesario definirle una
condicin por el pas.

La condicin ser:

CountryId = &CountryId;

Agregaremos tambin un botn para realizar la bsqueda de los datos.

Vea la demostracin aqu

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

Primero lo especificaremos y generaremos.

En la navegacin vemos que:

GeneXus navega la tabla COUNTRIES ordenada por nombre de pas, para realizar la carga del combo
dinmico &CountryId. Mientas que para la carga de &CityId, recorre la tabla COUNTRIES1 ordenado
por el nombre de la ciudad y filtrando por el pas seleccionado en la variable &CountryId.

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

dilogo de ejecucin.

Cuando se desea que todos los combos dinmicos de la base de conocimiento muestren el
mismo valor en ejecucin para el valor vaco, se deja el valor GX_EmptyItemText propuesto en la
propiedad EmptyItem. Este texto aparecer como cdigo en el Objeto Lenguaje para que pueda
ser traducido. El texto propuesto es (None) cuando el idioma lenguaje es ingls.

Lo mismo ocurrir si se asigna un valor especfico a esta propiedad a nivel del control o del atributo.
En este caso, ese texto ser una nueva entrada en los cdigos del objeto Lenguaje.

Recuerde que es necesario especificar el objeto antes de que aparezcan los cdigos en el objeto
Language.

Evento Start (de Web Panels)

El evento Start es un evento del sistema, que ocurre automticamente.

En qu momento se ejecuta? Cuando comienza la ejecucin del programa asociado a un web

panel, es decir, ni bien se abre un web panel en tiempo de ejecucin.

Cuntas veces se ejecuta? Una vez cuando comienza la ejecucin del web panel y tantas veces
ms como ejecuciones de eventos de usuario se realicen que no incluyan una invocacin a otro
objeto web.

En el evento Start no se conocen valores de atributos, salvo los recibidos por parmetro. Esto se
debe a que an 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 sla cuando comienza la ejecucin del
mismo.

Evento Refresh (de Web Panels)

Cuando el usuario presiona el botn 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, tambin se ejecuta el evento
Refresh.
Y cuando se ejecuta el comando Refresh incluido por el analista GeneXus en algn evento, tambin
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 continuacin de ejecutarse, causa que se ejecute
la consulta a la base de datos. Es decir, al ejecutarse el evento Refresh, se ejecuta el cdigo
asociado al mismo, y a continuacin 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 sla cuando comienza la ejecucin del
mismo.

Evento Load (de Web Panels)

Cada vez que se ejecute el evento Refresh en un web panel, seguidamente a la ejecucin del mismo,
se ejecutar el evento Load.
Cuntas 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 ledo
en la consulta efectuada a la base de datos, justo antes de cargar los datos del registro en una lnea
en el grid.

De modo que por cada registro ledo en la consulta efectuada a la base de datos, se ejecutar el
evento Load (ejecutndose el cdigo incluido en el mismo, y cargndose a continuacin una lnea 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 implcito asociado; por lo
tanto, cuando se ejecute el evento Refresh, no comenzar a ejecutarse ninguna consulta; se
ejecutar el cdigo asociado al evento Refresh, y a continuacin se ejecutar el cdigo asociado al
evento Load, una sola vez.

Evento Enter (de Web Panels)

Cuando se inserta un nuevo botn 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 botn, 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 debern codificarse.

Eventos de usuario (de Web Panels)

Adems 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, imgenes, atributos).

En tiempo de ejecucin, 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 automticamente:

Event Nombre Evento de Usuario [key]

EndEvent

2.

Dndole un nombre al control y en la seccin 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 pgina del servidor Web
para visualizarla, el Browser baja la pgina 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
algn evento de usuario. En ese momento se enva (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
ejecucin 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 razn 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 ejecucin de los eventos

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

PRIMERA EJECUCIN DE LOS WEB PANELS

La primera vez que se ejecuta el web panel (se conoce tambin como el momento en que se hace el
GET de la pgina) 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 ningn otro
web panel (ya sea porque el usuario presion un botn o di clic en algn 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 tambin como el POST de la pgina) los
eventos se dispararn en el siguiente orden:

1.
2.

Evento Start (nuevamente se dispara el evento Start)

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 estn involucradas en las conditions)

3.

Cdigo correspondiente al evento asociado al botn 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 harn despus de ejecutar un evento (presionar un botn),
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 ningn 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).
Adems, deber estar en el form despus 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 despus del
grid.

Si el evento que se ejecuta llama a otro web panel, comenzar a ejecutarse ese objeto,
disparndose los eventos del mismo segn lo descrito antes en la primer Ejecucin de los web
panels.

En HTML se puede especificar dos mtodos distintos para someter un formulario. El mtodo
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 tcnicamente 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
genricamente 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 sera 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 ejecucin, 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 razn que es importante tener claro el orden de ejecucin de los eventos. Ejemplifiquemos esto,
programando nuestra aplicacin.

Supongamos que en el evento donde validamos el usuario y la contrasea (en el web panel Login),
guardamos en una variable el cdigo de usuario para poder utilizarlo en otro evento. Esto nos permitira, por
ejemplo, llamar a un objeto que permita visualizar los datos del usuario.
En consecuencia, deberamos 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 algn evento, o se puede agregar un botn y en el evento asociado invocar al objeto.
El link se podra definir en el mismo evento Login a continuacin de la asignacin de la variable.
Si agregsemos un botn o una imagen con un evento clic asociado, entonces el cdigo 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.
2.
3.

En la primer ejecucin se disparan los eventos: Start, Refresh y Load y podemos ingresar el usuario y
password.
Cuando presionamos el botn para validar el login, se asigna a la variable &UserId el cdigo de
usuario correspondiente.
Cuando presionamos la imagen con el evento clic asociado, se dispara el evento Start, se leen las
variables que estn 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 ejecucin del Web Panel en el punto 2.

Haga clic aqu para ver la demostracin

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 ejecucin
Es por esta razn, que si queremos disponer del valor de la misma, deberamos agregar la variable &UserId
en el form y la ocultaramos usando la propiedad Visible (por ejemplo en el evento Start).
Entonces en este caso, cuando el web panel ejecute por segunda vez, se dispararn los eventos:
1.
2.
3.

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

Haga clic aqu para ver la demostracin

Haga clic aqu para ver la ejecucin

INTRODUCCIN
En los objetos web, se dispone de ms de un tipo de grid: el grid estndar y el grid Freestyle. Estos
grids, potencian el diseo de aplicaciones Web, permitiendo al desarrollador mayor libertad a la
hora del diseo.

Adems en el caso de los Web Panels, es posible utilizar mltiples grids y tambin anidarlos para
permitir navegaciones ms complejas.

A lo largo de este captulo iremos implementando todo esto a medida que vamos viendo los
conceptos tericos necesarios para su desarrollo.

Control Grid
Este control permite desplegar, -y dependiendo del objeto GeneXus que se trate, tambin ingresar,
modificar y/o eliminar- informacin 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 transaccin, 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 ejecucin, el grid es una tabla HTML.

que se encuentra en la barra de controles, permite insertar el control Grid. Al editar las
El botn
propiedades del control Grid, se abre un dilogo 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.

Botn Properties: Permite asignar propiedades especficas a la columna seleccionada.

Properties

Permite asignar propiedades de visualizacin para el grid estndar.

Propiedades del Grid

A continuacin 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, estarn disponibles otras propiedades

adicionales relacionadas con la configuracin de las lneas del grid.

Si BackColorStyle = Header

LinesBackColor

TitleBackColor

Si BackColorStyle = Report

LinesBackColor

LinesBackColorEven

TitleBackColor

Si BackColorStyle = Uniform

BackColor

Clculo 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 funcin 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 ms adelante).
TABLE
Los grids tambin tienen algunas propiedades configurables para las tablas. Estas propiedades son:

ToolTiptext
Align
Background
BorderWidth
Cellpadding
Cellspacing
Rules

Propiedades modificables en ejecucin

A continuacin se detallan las propiedades que se pueden modificar a los grids en tiempo de
ejecucin:

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

Tambin es posible indicar propiedades particulares para las diferentes columnas que forman el
grid. Para esto, se debe seleccionar la opcin Columns del men que aparece al hacer clic en el grid.

En este dilogo, seleccionando Properties sobre una columna se despliega un dilogo, 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 EJECUCIN

En tiempo de ejecucin 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 Estndar

Continuemos con el desarrollo de nuestro objeto MainSearch

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

En la descripcin del vuelo incluiremos un link a otro Web Panel (denominado Flight que
desarrollaremos ms 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 segn el tipo de control y la
cantidad de ese tipo que existan en el form). En muchos casos para simplificar la comprensin de la
lgica del control puede ser til asignarles nombres ms intuitivos.
Le asignaremos al control grid el nombre Flights y los atributos que lo componen sern la
descripcin, la aerolnea y el cdigo del pas/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 tambin 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 demostracin aqu

Especifiquemos el objeto y revisemos la navegacin del mismo.

GeneXus navega la tabla COUNTRIES ordenada por nombre de pas, para realizar la carga del combo
dinmico &CountryId. Mientas que para la carga de &CityId, recorre la tabla COUNTRIES1 ordenado
por el nombre de la ciudad y filtrando por el pas seleccionado en la variable &CountryId.

Para resolver el evento Load asociado al grid Flights, GeneXus navega la tabla FLIGHTS ordenada por
nmero de vuelo y filtrando por el pas 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 ejectelo para ver como funciona.

Al ejecutarlo habr notado que si indica un valor para el pas o la ciudad el dato no se muestra en la
lnea del vuelo, pero el ttulo se mantiene.

Esta es una de las principales diferencias entre los grids estndar y de tipo Free Style.

Notar que las condiciones de filtro por pas y ciudad se realizan con la clusula 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 condicin 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 bsicamente una tabla a la que se le pueden insertar los atributos / variables, text blocks,
imgenes, 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 ttulos para las columnas y adems permite tener ms de un tipo de
control, atributo / variable en una misma celda, proporcionando de esta forma mayor libertad de
diseo.

En ejecucin, el grid es una tabla HTML.

de la barra de controles disponibles. Se
Para insertar el grid Free Style se debe utilizar el botn
despliega el dilogo de seleccin de atributos y variables que conformarn 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 botn derecho del mouse y seleccionar la opcin Properties.

A continuacin 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, estarn disponibles otras propiedades

adicionales relacionadas con la configuracin de las lneas del grid.

Si BackColorStyle = Report

LinesBackColor

LinesBackColorEven

Si BackColorStyle = Uniform

BackColor

Propiedades del grid Free Style modificables en ejecucin

En tiempo de ejecucin 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 tambin 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

Diseando 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 tambin los Work Panels- cuya
nica funcin 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 ningn evento que las procese con el comando For Each line) y
cargarles valores explcitamente.

Mostraremos los datos bsicos del vuelo, la aerolnea, el origen y el destino del mismo y tambin los
datos de los posibles precios.
Pondremos tambin las banderas de los pases, para eso, usaremos variables de tipo bitmap donde
cargaremos las imgenes correspondientes.

Comencemos entonces creando un nuevo objeto de tipo Web Panel con nombre Flights.
Como recibiremos como parmetro el cdigo 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 ms libertad en el diseo.
Le asignaremos el nombre Prices al control y para mostrar la informacin en forma horizontal (y no
vertical) utilizaremos las propiedades Rows y Column.

Vea la demostracin aqu

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

Cmo trabajar con grids en Web Panels

A continuacin se detalla la forma de trabajo con grids en Web Panels.

Cmo desplegar datos

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

Cmo aceptar datos

Es posible aceptar datos en las variables de un grid dependiendo de la programacin 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 algn control en el grid con un evento clic asociado,

entonces todas las variables que estn dentro del grid pasan a ser de ingreso. Es posible indicar en
este caso cules 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.

Cmo asociar eventos a una lnea

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 seccin 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.

Cmo seleccionar lneas

Para ello, se accede a las propiedades del grid haciendo clic en el botn derecho sobre el control grid
y se configura la propiedad AllowSelection con el valor True. Al hacerlo se habilitan tres
propiedades ms, que permiten especificar SelectionColor: el color que tendr la lnea cuando el
usuario la seleccione (haciendo clic con el mouse sobre la misma); AllowHovering: la posibilidad de
que cambie el color de las lneas cuando el usuario se desplaza con el mouse sobre ellas, y
HoveringColor: el color que tendr una lnea cuando el mouse pasa sobre ella.

Demo: Cmo 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 ms 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 demostracin aqu

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

como invocacin a un programa externo. Dicho procedimiento grabara 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 inters.

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 ocuparn tantas lneas como resultados.

Tanto por temas de usabilidad, de performance o de tamao de la pgina HTML generada, puede ser
conveniente desplegar los resultados en un grid de tamao fijo y permitir con botones de
movimiento la navegacin entre las pginas de los mismos. Nos referimos a esto como paginacin
del grid.

Para esto, se dispone de mtodos 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 estndar y free style y tambin cuando los grids estn anidados.

Existen algunas diferencias relacionadas con la paginacin cuando un grid tiene tabla base o no.
Cuando el grid no tiene tabla base, no est disponible el mtodo Last Page ni GotoPage.

Mtodos

A continuacin se describen los mtodos disponibles:

FIRSTPAGE
El mtodo FirstPage lleva al usuario al primer conjunto de registros devueltos.
Los valores devueltos por este mtodo son los siguientes:

0: Operacin exitosa
1: No est habilitado el paginado en el grid

Ejemplo
Event Enter
MyGrid.FirstPage()
Endevent
En este ejemplo cuando el usuario presiona el botn asociado al evento enter, en el grid se
mostrar el primer conjunto de registros.

NEXTPAGE
El mtodo NextPage lleva al usuario al siguiente conjunto de registros.
Los valores devueltos por este mtodo son los siguientes:

0: Operacin exitosa
1: No est habilitado el paginado en el grid
2: Ya se encuentra en la ltima pgina.

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 botn Following, en el grid se mostrar el

siguiente conjunto de registros. En el caso que ya est cargada la ltima pgina, se muestra
el mensaje You already are in the last page en el textblock Message.

PREVIOUSPAGE
El mtodo PreviousPage lleva al usuario al conjunto anterior de registros.
Los valores devueltos por este mtodo son los siguientes:
0: Operacin exitosa
1: No est habilitado el paginado en el grid
2: Ya se encuentra en la primera pgina

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 botn Back, en el grid se mostrar el conjunto
de registros anterior y en el caso que ya est cargada la primer pgina se muestra el mensaje
You already are in the first page en el textblock Message.

LASTPAGE
El mtodo LastPage lleva al usuario al ltimo conjunto de registros. Puede ser utilizado nicamente
si el grid tiene tabla base.
Los valores devueltos por este mtodo son los siguientes:
0: Operacin 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 botn Last, en el grid se mostrar el ltimo
conjunto de registros.
GOTOPAGE
El mtodo 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 mtodo son los siguientes:
0: Operacin exitosa

1: No est habilitado el paginado en el grid

Ejemplo
En este ejemplo, dado el grid (GSearchResults) con el resultado de una bsqueda, y otro grid
(GPages) con el nmero de pginas de la primera para permitir un acceso ms rpido 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 continuacin se incluye una tabla con un resumen de los mtodos disponibles cuando un grid tiene
tabla base y cuando no.

FirstPage
NextPage
PreviousPage
LastPage
GoToPage

Grid con tabla base

Grid sin tabla base

Propiedades

Cada grid dispone de las siguientes propiedades que son utilizadas en la paginacin:

RecordCount

PageCount

Consideraciones

Si el web panel que se est paginando tiene filtros, se debera agregar el mtodo FirstPage
dentro del evento que aplica el filtro, a los efectos de evitar que el resultado desplegado
corresponda a la pgina en la que se encontraba anteriormente.

La eficiencia de los mtodos FirstPage, NextPage, PreviousPage y GotoPage( N) est

asociada a la eficiencia de la definicin de la navegacin del grid correspondiente. En otras
palabras, si el grid, sin paginado tiene buenos tiempos de respuesta, los tiempos con
paginado sern semejantes.

El mtodo LastPage determina cul sera la ltima pgina, 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 cdigo generado) barre dos veces la tabla base del grid (la
primera vez para contar y la siguiente para "cargar").

El mtodo 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 ejecucin del comando mencionado o se ejecuta ms de una vez el mtodo
Load por cada registro, los resultados pueden ser inesperados.

Implementacin

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

Dada la implementacin, se recomienda:

1.

Tener un buen filtrado de datos (de forma que no existan muchas pginas)

2.

Evitar, cuando el costo sea alto, el uso de GotoPage( N) con valores altos de N, as como el
uso de LastPage.

3.

Tambin se recomienda salvar el valor de la propiedad RecordCount en una variable ya que

cada invocacin de la propiedad implica un COUNT en la base de datos.

Ejemplo

Los mtodos 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: Paginacin 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. Adems, para
permitir la navegacin entre todos los registros (las tpicas acciones de ir a la primer pgina, a la
anterior, a la siguiente y a la ltima), vamos a incluir imgenes 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 mtodo de paginacin del grid correspondiente.

El cdigo que se ejecutar cuando el usuario haga clic sobre cada una de las imgenes 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()

Adems cuando modifiquemos los valores de las variables &CountryId y &CityId de la parte fija,
vamos a presionar el botn 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 botn de Buscar lo siguiente:

Event Enter
Flights.FirstPage()
EndEvent // Enter

Vea la demostracin aqu

Si el evento de Buscar no tiene al evento Enter asociado, esta lgica deber estar en el evento
de usuario definido.

Web Panels con ms de un grid

Cuando un web panel contiene ms 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 navegacin independiente. Puede verse una
analoga entre un web panel con varios grids y un reporte con for eachs paralelos.

A continuacin mostramos un ejemplo:

Dado que el web panel View Users & Service Providers tiene ms 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 determinacin 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 determinacin de la tabla base de
ninguno de los grids, pero debern 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 navegacin resultante, el warning: Attribute not instantiated.

Los atributos utilizados en los eventos del web panel tampoco participan en la determinacin de la
tabla base de ninguno de los grids. Los atributos que se incluyan en los eventos fuera de comandos
for each, debern 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 comn entre ellas, y por ende no
definir filtros automticos. Es decir que los grids tendrn asociadas navegaciones independientes o
paralelas.

Si bien GeneXus no establece relaciones entre las tablas bases de los grids, el analista podr definirlo
explcitamente. Primero estudiaremos los eventos en web panels con ms de un grid, y a
continuacin veremos cmo definir cargas relacionadas.

Eventos en Web Panels con ms de un grid

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

El evento Load, no existe global sino slo 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

Adems 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 genrico)

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 ms de un grid. Se debe incluir al
mismo para hacer cargas de grids sin tabla base, dentro del evento Load de un grid.

Cmo definir cargas relacionadas en Web Panels con ms 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 pases (GridCountries), y cada vez que
el usuario seleccione un pas, se cargarn sus ciudades en un segundo grid (GridCities).

Para asociar cargas, se deben definir grids con variables:

De modo que los grids no tendrn tabla base y en consecuencia el evento Load de cada grid, se
ejecutar una sla vez.

A continuacin detallamos el cdigo 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 botn 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 tendrn 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 ms 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

mtodos (por ejemplo, definir en algn evento la siguiente sentencia: CountryId.Visible=0).

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

que las codificaciones que se le hagan, afectarn a todos los grids en los que se encuentre. Es
decir, si el atributo CountryId perteneciera a ms de un grid, al ejecutarse la lnea de cdigo:
CountryId.Visible=0, el atributo CountryId quedara invisible en todos los grids.

Demo: Mltiples grids en un Web Panel

Continuemos avanzando con el desarrollo de nuestro objeto MainSearch

Lo que nos quedara 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 cmo es que dijimos que queramos que apareciera el formulario en ejecucin

Lo primero que debemos hacer para poder mostrar el pas del mes es agregar una celda a la derecha
de la celda donde filtramos por pas/ciudad. La forma ms sencilla de hacerlo es clic con el botn
derecho, y seleccionar la opcin 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 pas del mes es el de cdigo 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 pas 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 pas del mes.
Podemos definir un grid estndar que tenga como ttulo de la columnas Cities.

Para que no se vean en ejecucin los bordes donde se carga el resumen del pas del Mes, a la
variable correspondiente se la debe definir como ReadOnly.
Vamos entonces a hacer estos cambios a la aplicacin

Haga clic aqu para ver la demostracin

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 cdigo y
tambin de la navegacin 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 estndar, aunque si es estndar no puede tener
ninguno anidado.

Puede haber grids anidados de varios niveles y puede haber tambin 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 anidacin.

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

Hoteles
Hotel Colonia
Hotel Oceana
Transport
Alfa Travel
OtherWorld Travel
...

Para ello se define un grid Free Style con la categora y dentro de este se inserta otro grid con los
poveedores de servicios (podra ser un grid estndar o Free Style).

Determinacin 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 determinacin 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
lgica 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 tursticas del pas/ciudad seleccionado, debemos implementar grids
anidados.
El grid padre tendr la categora de las atracciones y en el grid anidado las atracciones en s.
En caso de que no se seleccione un pas, se mostrarn las atracciones del pas del mes. Adems
como no se referencia a la ciudad estarn 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 (tambin de tipo
Free Style y de nombre Attraction) para desplegar la informacin de la atraccin turstica.
Suponiendo que el pas 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 estndar o Free Style, en este caso elegimos un grid Free Style
simplemente por el modo en que esta pgina va a ser diseada.

Haga clic aqu para ver la demostracin

Grids en transacciones con form HTML

El botn

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 ejecucin 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 transaccin es diferente al descrito en los Web Panels.

Como desplegar datos en un grid

En ejecucin, los atributos que se encuentran en el formulario de una transaccin 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 transaccin son de slo lectura.

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

Como aceptar datos en un grid

En el caso de las transacciones, el grid despliega por defecto 5 lneas 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 transaccin son de ingreso, por lo tanto no
es necesario realizar ninguna modificacin.

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

INTRODUCCIN
En este captulo veremos los conceptos de Web Component y Embedded Page (pgina embebida).

El primero nos permite la reutilizacin de lgica entre los objetos y el segundo permite incluir dentro
de sitios diseados con GeneXus pginas de terceros.

Incluiremos tambin en nuestra aplicacin prctica un Web Component.

Web Components
Los Web Components permiten a los diseadores de aplicaciones GeneXus Web un alto grado de
reutilizacin 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 aplicacin web, puede ser
definida como Web Component.
Los ejemplos ms comunes son: mens, login, rea que permite la personalizacin, 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.

Cmo 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
caractersticas, por lo tanto, puede ser ejecutado en forma autnoma.

Los Web Components se generan dentro del mismo HTML del Web Panel que los contiene. Esto
significa que el servidor resuelve la inclusin del Web Component en tiempo de ejecucin y devuelve
al navegador el cdigo 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
opcin Insert / Web Component, o la opcin
control de tipo Web Component en el objeto.

de la barra de controles, con lo cual se crear un

Adems, 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 diseo o en tiempo de
ejecucin, como se describe a continuacin.

PROPIEDADES MODIFICABLES EN DISEO

El control Web Component tiene las siguientes propiedades de diseo:

ControlName: Nombre del control.

Object: Permite asociar un objeto web al Web Component. Slo se aceptan objetos con la
propiedad Type en Component.

Parameters: Permite especificar la lista de parmetros con los que se invocar el Web
Component.

PROPIEDADES MODIFICABLES EN EJECUCIN

A continuacin se detallan las propiedades de los Web Components que se pueden modificar en
tiempo de ejecucin:

Object: permite determinar en tiempo de ejecucin qu Web Panel o Transaccin se va a

desplegar en el lugar del control.

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

Donde:

Wxxx
Es el Web Panel o Transaccin al que se le ha configurado la propiedad Type en Component.
[par1], ... [parn]
Son los parmetros 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 dinmicos

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,
evala que coincidan los parmetros (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 dinmica,
basta con generar y compilar el componente mismo.

Estos objetos se vern adems en el object browser como objetos llamados.

Observaciones

En diseo, el tamao del Web Component permanece fijo, pero en ejecucin, el tamao quedar
sujeto al espacio ocupado por el mismo. La forma de fijar el tamao del Web Component en
ejecucin es entonces incluyndolo en una tabla y fijando el tamao de la celda.

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

La asignacin 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 parmetros se pasarn solamente
la primera vez que se crea. En sucesivos POST, los parmetros se recordarn del render anterior.
Si se asigna un Web Component en cualquier otro evento (Refresh, Load, de usuario, etc.), los
parmetros se pasarn siempre que se ejecute dicho evento.
Si se asigna el objeto web en la propiedad Object del control Web Component en diseo, el pasaje
de parmetros se realiza en forma anloga 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 parmetro el color y asignarlo en el
evento Start del Web Component.

En ejecucin, 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 dems controles.

No se soporta el uso de atributos como primer parmetro de la funcin Create.

Ejecucin de objetos web con Web Components

A continuacin se describe la ejecucin de objetos web que contienen Web Components.

Web Components en rea plana del objeto Web

ORDEN DE EJECUCIN 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 ejecucin de los eventos al realizar la primer llamada al mismo (GET) es el siguiente:
Evento START del objeto web que contiene el Web Component (objeto web padre),
1.
Evento REFRESH del objeto web padre,
2.
Evento START de todos los Web Components dentro del objeto web que no estn dentro de
3.
grids,
Eventos REFRESH y LOAD de cada uno de los Web Components y de los grids en el orden que
4.
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.
2.
3.
4.
5.
6.
7.

Evento
Evento
Evento
Evento
Evento
Evento
Evento

START del Web Panel

REFRESH del Web Panel
START del Web Component A
START del Web Component B
REFRESH del Web Component A y evento LOAD del grid en el Web Component A
LOAD del grid del Web Panel
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 continuacin se analizan ambos casos.
Nota: La lectura de variables de cada objeto se realiza siempre inmediatamente despus del evento Start de
dicho objeto.
Disparo de un evento de un Web Component
1.
2.
3.
4.
5.
6.

Evento START del objeto web padre

Evento START del Web Component cuyo evento se dispar
Evento de usuario del Web Component
Evento REFRESH del objeto web padre
Evento START de los Web Components restantes
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 sera 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.
2.
3.
4.
5.

Evento START del objeto web padre

Evento de usuario del objeto web padre
Evento REFRESH del objeto web padre
Eventos START de todos los Web Components en el orden que se encuentran en pantalla
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 sera el siguiente:
1.
2.
3.
4.

Evento START del Web Panel

Lectura de variables del Web Panel
Evento de usuario del Web Panel
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 ms 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 EJECUCIN 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 diseo para la optimizacin de Web

Components
A continuacin se describen algunos puntos a considerar para el diseo de pginas Web con
GeneXus y Web Components para lograr una optimizacin del cdigo HTML generado:

USO DE LA FUNCIN CREATE

Evitar el uso de la funcin 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 funcin Create (especificando un objeto o una variable) los generadores tienen que
incrementar el cdigo HTML generado para saber cul fue el nombre del Objeto Web Component que se
utiliz.
El incremento en el cdigo HTML por utilizar Create es relativamente menor. De todas formas, en pginas con
muchos Web Components y/o con Web Components dentro de grids, puede sumar varios KBytes ms a la
pgina.

EVITAR EL USO DE LA FUNCIN 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) basndose en los parmetros 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 lgica del programa) y entonces nos encontraramos en la misma situacin
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 cdigo 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 cdigo 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 inclusin de cdigo HTML escrito por el usuario en las pginas generadas. Es muy
recomendable utilizar Text Blocks en este caso.

ELIMINAR ATRIBUTOS/VARIABLES QUE NO ESTN SIENDO UTILIZADOS EN LA

PANTALLA

Genera menos cdigo 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 pgina 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 demostracin

Ms adelante incluiremos este componente en la Master Page.

Embedded Pages
Definicin

El objetivo de las pginas embebidas o Embedded Pages es poder incluir informacin 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 pgina u objeto web GeneXus, cuyo contenido luego ser
incluido en ejecucin dentro del objeto.

El uso de Embedded Pages brinda a los usuarios GeneXus la siguiente posibilidad de incluir
informacin externa: permite que se incluyan pginas estticas o dinmicas de la propia aplicacin o
desarrolladas por terceros.
Dichas pginas pueden estar en el mismo servidor que la aplicacin o en otro servidor. Esta
caracterstica brinda gran dinamismo a las aplicaciones web desarrolladas con GeneXus.

Generacin

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 pgina
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 opcin Insert /
Embedded Page, con lo cual se crear un control de tipo Embedded Page.
Tambin 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 pgina 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 dispararn en forma independiente y no es posible
establecer a priori cundo se ejecutan los de uno con relacin 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 mnimo 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 EJECUCIN

A continuacin se detallan las propiedades modificables en tiempo de ejecucin:

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 algn valor a la misma.
Por ejemplo:
MyPage.Source = http://www.genexus.com, siendo MyPage el nombre del control Embedded Page.
Se permite la asignacin dinmica 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 pgina 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 demostracin aqu

INTRODUCCIN
En este captulo continuaremos viendo formas de reutilizar lgica en el desarrollo de las aplicaciones
Web.

La finalidad contina siendo que la creacin y el mantenimiento de pginas Web asegure

consistencia con la totalidad del sitio.

La Master Page permite centralizar el diseo y el comportamiento en un solo objeto y reutilizarlo en

otros objetos sin requerir programacin.

Definiremos tambin en nuestra aplicacin prctica 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 Transaccin 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 utilizarn como
su pgina maestra.

Tal como lo ilustra la figura anterior, se define un Web Panel para oficiar de pgina maestra, es decir,
de la pgina que contendr el layout y comportamiento genrico del sitio.

Esa pgina tendr un Web Component para cargar el Header que deseemos darle a todas las pginas
del sitio, otro para el men, y luego tendremos el hueco donde querremos que cada pgina
particular del sitio sea cargada.

A cada una de esas pginas individuales que conforman en conjunto el contenido del sitio, habr que
configurarles en su propiedad MasterPage el nombre de la pgina 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 modificacin 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 cdigo (se ahorra mucho cdigo Javascript que generan los Web Components)

Facilidad para disear forms de objetos web

Algunos aspectos de seguridad y auditora pueden ser implementados en el Web Panel

Master Page

Mejor performance (menos cdigo HTML)

Desarrollo incremental (solo cambiando el Master Web Panel cambia toda la aplicacin)

Cmo 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 aparecern 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 ejecucin 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 comn 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 especificacin
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 especificacin 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 mostrarn un error de especificacin (spc0093 The Master Page property
references an object that is not a Master Page).

Demo: Uso de Master Pages

Definamos en nuestra aplicacin prctica una Master Page para incluir en ella el diseo del sitio.
Creemos entonces un nuevo objeto Web Panel MyMPage.

La idea sera tener un cabezal en la parte superior, el componente de login a la izquierda y un pie de
pgina para la aplicacin.

En la parte derecha tendremos las pginas de la aplicacin.

Por lo tanto definiremos una tabla de 3 x 1 para alinear las secciones. La celda del medio la
dividiremos utilizando la opcin Split Cell. Para que luego en ejecucin 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 sern dos nuevos objetos definidos como componentes que sern incrustados
en esta tabla.

Entonces ser as:

Componente Cabezal
Componente Login

Zona de datos

Componente Pie de pgina

Vea la demostracin aqu

Ahora, es necesario definir los Web Panels que se invocarn desde este objeto para tener el diseo
definido. Para esto siga las instrucciones que se describen en el prximo documento.

Prctico: Definicin y uso de Web Components

Ahora es necesario que defina los componentes que se invocarn 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. Adems,
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 pgina, 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, adems 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 tambin 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 ejecucin.

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 utilizarn como
su pgina maestra.

Para insertar un Content Placeholder se debe seleccionar la opcin 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: descripcin 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.

INTRODUCCIN
Destacaremos aqu algunas particularidades de las Transacciones Web que estn diseadas en la
aplicacin para profundizar algunos conceptos.

Para destacar el funcionamiento de las mismas, se describirn sus diferencias con respecto al
comportamiento de las transacciones en ambiente grfico, destacando las propiedades y mtodos
especficos utilizados en ambiente Web, como ser las propiedades Rows y AddLines. As como
tambin el manejo de Blobs en Web Forms.

Form web de Transacciones

Cada Transaccin contiene un form (pantalla) web mediante el cual se realizarn las altas, bajas y
modificaciones en ambiente Web.

Para disear el form web de una Transaccin, se debe abrir la Transaccin y seleccionar la opcin 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 descripcin 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 podrn asignar propiedades (tipo
de letra, color, etc.).
que se utiliza para obtener un registro luego de
2) Aparece un botn llamado Get
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
botn Delete All del form web, no opera de la misma forma que el Delete del form GUIWindows; 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 botn, hay una comunicacin con el servidor Web, una conexin a
la base de datos para efectuar una consulta u operacin, desconexin de la misma, y presentacin
del resultado con formato HTML en el browser del usuario.

Los botones definidos automticamente por GeneXus pueden cambiarse por imgenes a las que se
les asocian en la propiedad OnClickEvent los eventos estndar de GeneXus (por ejemplo, Next,
Last, Get, etc.).

Se muestra un ejemplo a continuacin:

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

Si el control Error Viewer no se coloca en una posicin determinada del form, y se usa la funcin
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 implcito que es donde se
despliega el mensaje al usar la funcin msg().

Propiedades del Error Viewer en diseo

Las propiedades del control Error Viewer en diseo 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 ejecucin

Adems de las propiedades detalladas anteriormente, se pueden modificar las siguientes propiedades en
tiempo de ejecucin:

BackColor
Display Mode
ForeColor
Class

Propiedades del control Error Viewer en los Temas

Adems 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 adems de la Clase ErrorViewer, estn 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: Transaccin de un nivel

Ahora que ya vimos como funcionan las Transacciones Web, podemos definir la Transaccin para
registrar un nuevo usuario que es invocada en el link que definiremos en el Web Panel MainSearch.
Para hacerlo, tenemos que editar la Transaccin de Usuarios (Users), seleccionando previamente el
modelo de Diseo en la base de conocimiento.

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

La numeracin de usuarios se realiza en forma automtica, por lo tanto se debe asignar Yes a la
propiedad Autonumber de la Transaccin para que la clave primaria de la tabla se autonumere.
Como ya existe un registro ingresado, comenzaremos a numerarla a partir del nmero 2. Para eso,
asignar el valor 2 a la propiedad Autonumber Start.

Haga clic aqu para ver la demostracin

Se debe evitar que el Nickname incluya menos de 5 caracteres. El algoritmo podra ser ms
complejo, por lo que en ese caso se debera 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 nmero de telfono) 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 contrasea concuerde con la confirmacin ingresada, para eso
es necesario agregar:

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

En el evento Start, se deber agregar el cdigo 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 demostracin

Ahora que ya definimos la Transaccin Web, podemos modificar el link para registrar un nuevo
usuario, en la pgina principal, de forma de que le pase los parmetros adecuados a la Transaccin
Users.
Recuerde que la pgina 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 ejecucin de nuestra aplicacin y registremos un nuevo usuario

Haga clic aqu para ver la ejecucin

Durante la ejecucin pudimos visualizar claramente como es la ejecucin de las reglas con Ajax.
Pudiendo ver cmo se disparan las reglas, la frmula (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 ms de una vez, como se pudo observar en la ejecucin anterior.

Adems, al momento de grabar la password se podra haber utilizado las funciones de encriptacin
que provee GeneXus.

GeneXus provee las siguientes funciones para encriptar datos: GetEncryptionKey, Encrypt64 y
Decrypt64.

Demo: Transaccin de dos niveles

A continuacin realizaremos las siguientes modificaciones en la Transaccin Flights para poder observar los filtros automticos que
presentan los combos. Para lo cual, modificaremos los controles correspondientes a los pases y ciuades, de forma tal que cuando el usuario
seleccione un pas, luego al seleccionar las ciudades nicamente se desplieguen las ciudades de dicho pas.

Cuando tenemos Transacciones de ms 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 botn Aplay Changes (que tiene asociado el evento Enter). De esta forma se estar
eliminando la/s lneas seleccionadas del grid.

Haga clic aqu para ver la demostracin

Haga clic aqu para ver la ejecucin

Ahora que ya vimos como funcionan las Transacciones Web de dos niveles editaremos la
Transaccin CountryAttraction para registrar las diferentes atracciones de un pas. Para ello el
usuario deber seleccionar un pas y una ciudad (de los respectivos dynamic combo boxes, puesto
que estos atributos fueron definidos as en la Transaccin anterior) y para facilitar al usuario el
ingreso de la informacin en el segundo nivel, aplicaremos las propiedades InputType y Suggest, al
momento de ingresar la categora de la atraccin.
Haga clic aqu para ver la demostracin

Es importante tener en cuenta que si se presiona el botn Delete All (), se eliminar el registro de
la Transaccin.

Dilogo de las Transacciones en Web

El dilogo de las Transacciones en ambiente Web utiliza la tecnologa Ajax para brindar una
alternativa al dilogo a pantalla completa (full screen) y proveer ms interaccin con el usuario.

En la medida que el usuario final vaya pasando por los campos de la pantalla y/o ingresando
informacin en ellos, se irn validando los datos, infiriendo los atributos de la tabla extendida, y
disparndose las reglas y frmulas definidas. Todas estas operaciones se ejecutarn en forma
interactiva para que el usuario final pueda ir viendo resultados. De todas formas, las caractersticas
del dilogo a pantalla completa se mantendrn, en el sentido que cuando el usuario final confirme
los datos, se grabarn los de la pantalla completa, disparndose antes todas las validaciones, reglas,
y frmulas.

Algunas funcionalidades basadas en Ajax son:

Web Client Side Validation

Descripciones en vez de cdigos

o

Propiedad InputType de atributos

Suggest (intellitips) de atributos y variables

Combo boxes dinmicos con filtros

Web Client Side Validation (WCSV)

En las aplicaciones .Net y Java con interfaz Web siempre se trabaja con dilogo de validacin a nivel
del cliente (Web Client Side Validation). El propsito de esta funcionalidad es incrementar el nivel de
interaccin de las aplicaciones Web utilizando la arquitectura Ajax, hacindolas ms atractivas sin
costo de desarrollo alguno.

GeneXus genera cdigo para muchas de las reglas y frmulas 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 pgina entera al servidor.
Este cdigo es generado en el lenguaje Javascript, por lo que el browser debe tener habilitada la
opcin 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
pgina HTML entera del servidor Web al cliente para ser desplegada por el browser. Cuando se carga
la pgina solicitada en el browser, el cdigo Javascript tambin ser enviado para:

Disparo de reglas que no dependen de ningn evento de disparo. Esto quiere decir, reglas
que dependen del rbol natural de evaluacin.

Disparo de frmulas relacionadas, de acuerdo al rbol de evaluacin.

Realizar chequeos de integridad referencial e inferir los correspondientes datos.

Validacin del tipo de datos de los atributos.

Por ejemplo, cuando el usuario final ingresa un valor en un campo que es clave fornea, se realizar
una invocacin 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 travs de l. El
servidor devolver un XML con la informacin solicitada y en el browser se rearmar la pgina HTML.
Observemos que la informacin que viaja por la Web es mnima.

Todo lo que hace el usuario es ingresar un valor en el campo que es clave fornea, 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 informacin al servidor y volvi, rearmndose la pgina entera.

As como ocurra en Win cuando se tena configurada la propiedad Client Side Validation para que
reglas, frmulas 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 validacin de reglas y el clculo de frmulas 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 condicin que la produce deja de cumplirse. Tambin 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 dilogo 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 dilogo 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 aplicacin Java o
.Net Web, se generar con validacin 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
aplicacin Windows ser con validacin a nivel del cliente, puede deshabilitarse.

Inferencia de modo: En Web el modo no ser inferido automticamente 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 diseo aparece automticamente el botn Get,
para permitir recuperar un registro existente y poder trabajar con l. El desarrollador puede
eliminarlo si la transaccin recibe clave y modo. En Win solo ser incluido el botn Get si
se tiene configurada la propiedad CSV en No.

Botn de confirmacin en ejecucin: En Web el botn (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 botn (con texto en diseo Confirm) cambia su texto en ejecucin de acuerdo al
modo en que se encuentre la transaccin (si se est insertando, dir Add, si se est
actualizando dir Update y si se invoc a la transaccin recibiendo modo delete, el botn
mostrar Delete).

Resultado de la operacin sobre la base de datos se informa en: el Error Viewer en la

transaccin Web, y en la barra de estado que aparece en el extremo inferior izquierdo de la
pantalla en la transaccin Win.

Una quinta diferencia que es importante tener en cuenta tiene que ver con la UTL (Unidad
de Trabajo Lgica). 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
transaccin 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
transaccin no operar.

En dnde sern desplegados los mensajes?

El lugar dnde se desplegarn 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. Adems, en cajas de texto sobre la pantalla,
especficamente 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 enva la pgina al servidor, todas las reglas y frmulas se volvern a disparar. Todos los
mensajes que fueron disparados en el cliente y an son vlidos se redesplegarn tambin en un Text
Box o en el Error Viewer. Las reglas asociadas a eventos de disparo (AfterValidate, AfterInsert, etc.)
sern evaluadas por primera vez, lo que generarn mensajes y errores que se desplegarn en el
Error Viewer.

Es decir, funcionarn 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 estn asociadas a la Clase ErrorMessages y las reglas msg estn asociadas
la Clase WarningMessages. Ambas clases pertenecen a la Clase Messages, donde se les puede
configurar sus propiedades como con las dems clases. La diferencia en este caso es que no hay
controles GeneXus asociados a dichas clases. La asociacin a las clases ErrorMessages y
WarningMessages es automtica (para los errores y reglas msg respectivamente).

Tener en cuenta que adems 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 dilogo 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 ejecucin

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 travs de los mismos.

Al ejecutar un programa correspondiente a una Transaccin, se podrn distinguir los siguientes

modos, dependiendo de la operacin que se realice:

Modo Insert : Indica que se est efectuando una insercin

Modo Update : Indica que se est efectuando una actualizacin

Modo Delete : Indica que se est efectuando una eliminacin

Modo Display : Indica que se est efectuando una consulta

Dependiendo de la plataforma o ambiente de generacin, habrn algunas diferencias en lo que se

refiere a la operativa de las Transacciones en tiempo de ejecucin. No obstante, ms all de la
plataforma, cada vez que se realice una operacin de insercin, actualizacin, eliminacin, o
consulta a la base de datos a travs de una Transaccin, habr un modo asociado.

Adems de esto, las Transacciones tienen un comportamiento diferente segn 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 accin: insercin, modificacin o eliminacin de
registros.

Modo Insert

Al ingresar a una Transaccin 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 botn
Apply Changes. Esto provoca, en primera instancia, que se validen los datos ingresados en forma
similar a cuando se presiona el botn 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.

Adems, si no se trabaja con confirmacin (propiedad Confirmation del objeto), se insertarn los
datos. Si se trabaja con confirmacin, se desplegar el mensaje Please confirm the data. Al
presionar nuevamente el botn Apply Changes, se insertarn 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 botn Get (
Esto hace que se carguen los datos del registro.

).

Al cargar los datos tambin se traen las descripciones. Se pueden modificar los datos y presionar el
botn Apply Changes, y se actualizarn los datos con un procedimiento anlogo al del modo Insert.

Modo Delete

Para eliminar un registro primero se debe ingresar en modo Update (ingresando la clave y
presionando el botn Get), y luego presionar el botn Delete All, lo que provoca que se
deshabilite dicho botn. En el caso de trabajar con confirmacin, se desplegar el mensaje Confirm
deletion.

Al presionar el botn Apply Changes, se eliminarn los datos y se desplegar el mensaje Data has
been successfuly deleted.

En el caso de que no se trabaje con confirmacin, al presionar el botn Delete All se eliminarn
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 Transaccin queda en modo Insert.

Observaciones

Tener en cuenta que si la variable &mode no es recibida como parmetro 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 an.

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 Transaccin Web instanciando el modo Delete siempre se despliega el
mensaje Confirm deletion, sin importar si se est trabajando con confirmacin o no. Al
presionar el botn Apply Changes, se elimina el registro.

Transacciones Web de ms de un nivel

Cuando se trabaja con Transacciones Web de ms de un nivel, se tienen que tener en cuenta los
siguientes puntos:

Nmero de niveles de una transaccin

Las Transacciones Web pueden tener ms 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 anidacin previo al ltimo debe ser un grid Free Style que contenga al nivel
siguiente

El ltimo nivel debe ser un grid estndar.

Por ms detalles ver Grids en Transacciones Web.

Mtodo AddLines

Se implement el mtodo AddLines para el tipo de control grid. El mismo aplica en Transacciones
Web. Y permite al usuario ingresar lneas en el grid una por una.

El uso es bastante simple, para el caso del ingreso de datos que necesita ms lneas de las que hay
por defecto se puede agregar un botn con este mtodo. Este mtodo no realiza ni validaciones ni
chequeos, slo agrega las lneas en blanco al final y mantiene los valores que ya estaban ingresados
en la Transaccin.

Sintaxis
MyGrid.AddLines(N)
Agrega N lneas al grid de la Transaccin.

Ejemplo

El usuario podr presionar el botn AddLines en Modo Insert para agregar lnea a lnea en el grid de
la Transaccin.

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'

Eliminacin de lneas

En diseo se utiliza una variable &GxRemove definida y agregada automticamente 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 lnea del grid, se debe marcar la misma con el check box, y
presionar el botn de Apply Changes, no el botn de Delete All. Este ltimo eliminar toda la
transaccin, no las lneas marcadas.

Nota: Es importante considerar nuevamente que cuando se est en una Transaccin Web se est
modificando todo el documento y no se est en un nivel en particular de la misma. Por eso para
eliminar lneas se debe utilizar el botn Apply Changes porque en realidad se est actualizando el
documento. Lo mismo para agregar lneas, se debe utilizar el botn Apply Changes porque se
est actualizando el documento.

Reglas en Transacciones Web

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

Se escriben de forma declarativa, es decir que el orden en el que se escriben no significa que sea el
orden de ejecucin.

Pueden involucrar a los atributos definidos en la estructura de la Transaccin , as como a

variables, constantes y funciones.
Son solo vlidas dentro de la Transaccin en la que estn 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 Transaccin; y la mayor parte de ellas pueden tambin involucrar atributos de la(s)
tabla(s) extendida(s) de la(s) tabla(s) base(s) asociada(s) a la Transaccin. Para poder referenciar a un
atributo en una regla, el mismo deber estar incluido en la estructura de la Transaccin. Ya sea que
pertenezca a alguna de las tablas bases asociadas a la Transaccin, o a sus tablas extendidas.

Reglas ms utilizadas en Transacciones

La siguiente es una lista de las reglas ms utilizadas en Transacciones:

Default

Error

Msg

Asignacin

Serial

Subtract

Add

Allownulls

Update

Accept

Noaccept

Recomendamos acceder al Help de GeneXus para consultar sobre otras reglas vlidas 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 insercin por medio de la Transaccin (modo Insert),
pero el usuario final podr cambiarlo si ese valor no es el que desea.

Sintaxis

Default( att | &var, exp );

Donde:

att: es un atributo perteneciente a alguna de las tablas base asociadas a la Transaccin.

var: es el nombre de una variable.
exp: es una expresin que puede involucrar constantes, funciones, variables u otros atributos. El tipo
de datos de la expresin debe coincidir con el tipo de datos del atributo o variable.

Funcionalidad: Esta regla asigna el valor de la expresin exp como valor por defecto del atributo att
o variable var, cuando la Transaccin se ejecuta en modo Insert.

Esta regla no es vlida para atributos que forman parte de la clave primaria de alguno de los niveles
de la Transaccin, porque es disparada luego de que la clave es ingresada (ya que solo en ese
momento el modo es conocido y esta regla se dispara solo en modo Insert).

Error

Permite desplegar un mensaje de error si la condicin se satisface. Sirve para definir los controles
que deben cumplir los datos.

Sintaxis

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

Donde:

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

var: es el nombre de una variable de tipo character, que contiene un string con un mensaje de error
a desplegar.
character expression: es una expresin cuyo tipo resultante es character y que ser desplegada.
msgId: es un string (sin espacios en blanco ni comillas) que ser utilizado solo si la Transaccin es
definida tambin como business component1.
cond: es una expresin booleana (que puede contener los operadores lgicos and, or, not).
evento/momento de disparo: es uno de los eventos predefinidos de GeneXus disponibles para reglas
de Transacciones, que permiten definir el momento especfico de ejecucin de una regla.

Funcionalidad: Esta regla despliega el mensaje del parmetro msg, var o character expresion, si la
condicin cond que se evala resulta verdadera. El mensaje de error se despliega en el control Error
Viewer y/o un cuadro de texto, deteniendo cualquier actualizacin a la base de datos. Cuando la
Transaccin 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 condicin se satisface.

Sintaxis

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

Donde:

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

Funcionalidad: Esta regla se utiliza para presentar mensajes de advertencia al usuario. Despliega el
mensaje del primer parmetro, si la condicin se satisface, anlogamente a la regla Error; pero a
diferencia de esta ltima, permite continuar con la ejecucin si la condicin sigue satisfacindose.
Del mismo modo, si la Transaccin es Business 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 aceptarn valores por parte del usuario (sern 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 Transaccin.

cond: es una expresin booleana (puede contener los operadores lgicos and, or, not).

Funcionalidad: En una Transaccin, todos los atributos que pertenecen a las tablas base asociadas a
la Transaccin, por defecto son aceptados. Si queremos que algunos atributos con estas
caractersticas no sean aceptados, entonces contamos con la regla Noaccept.

Subtract
Sustrae el valor de un atributo al valor de otro atributo, si se satisface la condicin especificada.

Sintaxis

subtract(att1, att2) [if cond];

Donde:

att1, att2: son atributos pertenecientes a alguna de las tablas base asociadas a la Transaccin, o a
sus tablas extendidas (y deben estar declarados en la estructura)
cond: es una expresin booleana (que puede contener los operadores lgicos and, or, not).
Funcionalidad: La sustraccin se realiza teniendo en cuenta el modo en el que se est trabajando en
la Transaccin (Insert, Update o Delete).
En modo:
- Insert: se le sustrae al valor del atributo att2, el valor del atributo att1
- Delete: se le suma al valor de att2, el valor del atributo att1
- Update: se le sustrae al valor del atributo att2, la diferencia entre el valor nuevo y el viejo de att1
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 condicin especificada.

Sintaxis

add( att1, att2) [if cond];

Donde:

att1, att2: son atributos pertenecientes a alguna de las tablas base asociadas a la Transaccin, o a
sus tablas extendidas (y deben estar declarados en la estructura).
cond: es una expresin booleana.

Funcionalidad: La adicin se realiza teniendo en cuenta el modo en el que se est trabajando en la

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

Serial

Permite numerar serialmente atributos numricos.

Sintaxis

Serial( att1, att2, step);

Donde:

att1: es un atributo perteneciente a alguna de las tablas base asociadas a la Transaccin (es decir,
no inferido), que desea autonumerarse (debiendo estar declarado en la estructura).
att2: Tiene que pertenecer a una tabla directamente superordinada a la del atributo att1.
step: es el paso o incremento de la serializacin.

Funcionalidad: El propsito de esta regla es asignar un nmero correlativo a att1 cada vez que se
inserta un registro en la tabla a la que pertenece att1. Se toma el valor de att2 (att2 contiene el
ltimo nmero utilizado en la autonumeracin), se le suma el valor del parmetro step, y el valor

resultante se asigna tanto al atributo att1 del nuevo registro, como al atributo att2 para conservar
el ltimo nmero asignado.

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

Accept

Permite indicar que las variables aceptarn valores por parte del usuario en un nivel dado de la
Transaccin.

Sintaxis
Accept(&var [, att]);

Donde:

&var: es una variable presente en el form.

atti: es un atributo perteneciente a la Transaccin.
Funcionalidad: Esta regla permite al usuario el ingreso de valores en variables en el nivel de la
Transaccin 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 estn posicionados en la pantalla. Si no se
especifica un atributo en particular, se asume el primer nivel de la Transaccin.

Update

Posibilita actualizar en el form de una Transaccin atributos de la tabla extendida (inferidos).

Sintaxis

Update( att1[, atti ]);

Donde:

atti: es un atributo perteneciente a la tabla extendida de alguna de las tablas bases asociadas a la
Transaccin.

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

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 Transaccin
Web, en su lugar se aconseja utilizar default(Att,today()).

Lo mismo ocurre con la variable &time y la funcin Time() correspondiente.

Orden de Ejecucin de Reglas y Frmulas

La forma de programar el comportamiento de las Transacciones es definiendo reglas, las cuales se
escriben de forma declarativa. A su vez si hay clculos para efectuar, se puede optar por la
alternativa de definir atributos frmula.

El programador GeneXus en ningn momento especifica la secuencia de ejecucin de las reglas y

frmulas definidas en una Transaccin, sin embargo al momento de generar, GeneXus determina las
dependencias existentes entre las reglas y frmulas definidas.

En la mayora de los casos el orden de ejecucin 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 despus
de determinada accin, como la grabacin del cabezal, o de una lnea. 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 confirmacin de la Transaccin, ocurre una serie de acciones que es necesario

conocer para poder programar correctamente el comportamiento de las reglas.

Para una Transaccin de dos niveles, podramos enumerarlas como sigue:

Validacin de los datos del cabezal

Grabacin fsica del cabezal (ya sea insercin, modificacin o eliminacin)

Validacin de los datos de la primera lnea

Grabacin fsica de los datos de la primera lnea

Validacin de los datos de la segunda lnea

Grabacin fsica de los datos de la segunda lnea

Validacin de los datos de la n-sima lnea

Grabacin fsica de los datos de la n-sima lnea

Commit

La accin de validacin 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 correspondan a atributos del cabezal y que no tenan evento de disparo asociado.
Inmediatamente despus se grabar el registro correspondiente al cabezal.

Anlogo es el caso de las lneas: la validacin de los datos de una lnea ocurre cuando ya se han
validado todos y cada uno de los datos de la lnea, y tambin se han disparado todas las reglas

correspondientes segn el rbol de evaluacin. Inmediatamente despus de esta accin de

validacin, se grabar fsicamente el registro correspondiente a la lnea.

Cada Transaccin, al terminar de trabajar con un cabezal y sus lneas, realiza un commit (es
automtico); ser colocado en el cdigo generado por GeneXus, a menos que el analista especifique
lo contrario.

Los eventos de disparo de reglas permiten definir que se ejecuten antes o despus de alguna de las
acciones que acabamos de enumerar. Veremos cundo ocurre cada evento de disparo.

Evento de disparo: BeforeValidate

Este evento de disparo ocurre un instante de tiempo antes de que la informacin de la instancia con
la que se est trabajando (cabezal o lnea x) sea validada (o confirmada). Es decir, ocurrir un
instante de tiempo antes de la accin de validacin del cabezal o validacin de la lnea, segn
corresponda. Observar que aqu tambin se habrn disparado todas las reglas segn el rbol de
evaluacin que no estn 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 fsicamente cada instancia del nivel al cual est asociada la regla, en la tabla
fsica correspondiente, y despus 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 fsicamente (ya sea que se inserte, modifique o elimine) como registro en la tabla
fsica asociada al nivel.

Existen tres eventos de disparo que ocurren en el mismo momento que el AfterValidate, pero que ya
contienen intrnseco 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, quedarn claros los dos
sinnimos elegidos para este evento (AfterValidate y BeforeInsert para modo insert)

VALIDACIN DE LOS DATOS

AfterValidate BeforeInsert BeforeUpdate BeforeDelete
GRABACIN DEL REGISTRO (insert, update, delete segn 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 grabacin fsica de cada instancia de un nivel
(AfterValidate, BeforeInsert, BeforeUpdate, BeforeDelete), tambin existen eventos de disparo para
definir que ciertas reglas se ejecuten inmediantamente despus de que se inserten, modifiquen o
eliminen fsicamente instancias de un nivel. Estos eventos son AfterInsert, AfterUpdate y
AfterDelete.

El evento de disparo AfterInsert permite definir que una regla se ejecute inmediatamente despus
de que se inserte fsicamente cada instancia del nivel al cual est asociada la regla; el AfterUdate
luego de que se actualice fsicamente 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 despus de
terminar de iterar determinado nivel.

Si el atributo que se especifica a continuacin del evento de disparo AfterLevel pertenece al

segundo nivel de la Transaccin, la regla se ejecutar cuando se hayan terminado de iterar todas las
lneas del segundo nivel.

Y si el atributo que se especifica a continuacin 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 lneas y
se cierre la Transaccin (en ese momento se habrn 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 despus de abandonar el ltimo nivel.

Evento de disparo: AfterComplete

Este evento corresponde al instante de tiempo que sucede al commit.

Esquema de disparo

VALIDACIN DE LOS DATOS CABEZAL

AfterValidate BeforeInsert BeforeUpdate BeforeDelete
GRABACIN DEL REGISTRO (insert, update, delete segn corresponda)
AfterInsert AfterUpdate AfterDelete

VALIDACIN DE LOS DATOS LNEA

AfterValidate BeforeInsert BeforeUpdate BeforeDelete
GRABACIN DEL REGISTRO (insert, update, delete segn 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 Transaccin Win (para una Transaccin Web no tiene sentido) y lo har una sola vez, cuando
se cierra la Transaccin.

El evento Start y el evento Exit, c

omo mencionaremos luego, en una Transaccin Web estos eventos se ejecutarn una vez por cada
instancia de Transaccin con la que se trabaje.

Otro tema importante son las reglas que no tienen evento de disparo asociado, se ejecutarn 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 dispararn: primero en forma interactiva en la medida
que el usuario final vaya trabajando en el form, y luego nuevamente cuando el usuario final efecte
la confirmacin.

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 invocacin a un procedimiento que actualiza la base de datos, habr que optar por
alguna de las siguientes alternativas para evitar que se dispare ms de una vez:

asignarle evento de disparo especfico a la regla

bien decidir si configurar o no la propiedad confirmation

 o estudiar bien la lgica del procedimiento y tener en cuenta la doble o triple ejecucin del mismo

Por ltimo, si se configurara la propiedad Confirmation= Yes, las reglas sin evento de disparo
asociado tendran 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 programacin dirigida por eventos, que es un estilo de
programacin en el cual existe cdigo 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 cdigo asociado a cada evento
posible, y el mismo se disparar slo si el evento se produce.

La programacin 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 utilizacin de los mismos.

Evento Start (de Transacciones Web)

El evento Start es un evento del sistema, que ocurre automticamente.

En qu momento se ejecuta? Se ejecutar cada vez que se someta el form de la Transaccin, es

decir cuando se presione cualquier botn del form (Get, Apply Changes, botones de navegacin,
botn Select o cualquier botn 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 algn modo menos para actualizarlos, se debe tener en
cuenta que los nicos atributos que se tienen disponibles son los que se reciben por parmetro en la
regla parm. Ningn otro atributo tendr valor en este evento, pues todava no se ha editado ninguna
instancia de la Transaccin.

Evento Alter Trn (de Transacciones Web)

El evento After Trn de las Transacciones ocurre inmediatamente despus de la ejecucin de las
reglas con evento de disparo AfterComplete. Por consiguiente, el cdigo que se incluya en este
evento, se ejecutar luego de culminada cada iteracin completa por medio de la Transaccin (es
decir, luego de haberse grabado cada cabezal con sus correspondientes lneas como registros fsicos
en las tablas que corresponda y de haberse efectuado COMMIT).
Existen las siguientes alternativas para programar comportamientos que se deseen ejecutar luego de
cada iteracin completa por medio de una Transaccin:

Definir reglas individuales con evento de disparo AfterComplete y dejar el evento After Trn
sin cdigo

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 cdigo en el
evento After Trn

Como venimos explicando, primero se ejecutan las reglas definidas con evento de disparo
AfterComplete, e inmediatamente despus de las mismas se ejecuta el cdigo 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 Transaccin. Es decir, si bien ya se grabaron fsicamente los registros correspondientes al
cabezal y las lneas de cierta iteracin completa, e incluso se efectu COMMIT, an se tienen
disponibles los valores de los atributos del primer nivel, pudiendo estos utilizarse para pasarlos por
parmetro en una invocacin, o evaluar su valor, o usarlos de algn 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 seccin de reglas de una Transaccin, 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 adems, en lo que respecta al evento After Trn, en los eventos no se permite
realizar asignaciones a atributos.

Eventos de usuario (de Transacciones Web)

Adems 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 Transaccin de
los que soportan el OnClickEvent (botones, text blocks, imgenes, atributos) y/o a una tecla de
funcin.

En tiempo de ejecucin, el evento de usuario ocurrir luego de que el usuario haga clic sobre el
control o la tecla de funcin 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 automticamente:

Event Nombre Evento de Usuario [key]

EndEvent

2.

Dndole un nombre al control y en la seccin 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 botn, 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 automticamente) y es lo ltimo en
ejecutarse.

En qu momento se ejecuta? Ocurre una nica vez, al final de cada iteracin (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 algn modo salvo
actualizarlos, se debe tener en cuenta que los nicos atributos que se tienen disponibles son los que
se reciben por parmetro en la regla parm. Ningn 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 Transaccin, el orden de disparo de eventos y reglas es el siguiente:
1.
2.

Evento START
Reglas que no tienen condiciones de disparo

Al presionar el botn Get, el botn Confirm o cualquier botn 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 Frmulas segn rbol

7. COMMIT
8. Evento AFTER TRN
9. Evento EXIT

Propiedades de Transacciones Web

A continuacin veremos las propiedades ms comunes en una Transaccin Web:

Name: En dicha propiedad se especifia el nombre de la Transaccin.

Description: Permite el ingreso de una breve descripcin de la Transaccin. Tambin se

utiliza como ttulo 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 cul es el Style asociado a dicha Transaccin.

Theme: Permite indicar cul es el Tema asociado a dicha Transaccin.

Type: Permite indicar si la Transaccin ser un WebComponent (Component) o una

pgina Web (Web Page).

Master Page: Permite indicar cul es la MasterPage en la cual est basada la

Transaccin.

Encrypt URL parameters: Permite o denega la encriptacin de los parmetros enviados

en la URL.

Business Commponent: Permite indicar si es Business Commponent o no.

Commit on exit: Controla si se efecta o no el commit automticamente.

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 botn y la nueva pgina es mostrada. Toda modificacin a la
base de datos que se haga durante la vida debe ser confirmada o eliminada antes de que la Transaccin
Web muera y retorne la pgina resultante.
Como consecuencia, una Transaccin Web inicia una UTL (Unidad de Trabajo Lgica) 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 Transaccin Web, sta iniciar una nueva UTL.

No puede definirse una UTL compuesta por varias Transacciones Web. Una Transaccin 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 Transaccin.
El objeto que gobierna la UTL ser la Transaccin 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 ms 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 solucin.

Consideraciones Generales
Control de concurrencia
Las Transacciones Web utilizan el dilogo pseudo-conversacional. Esto implica que, mientras el usuario est
realizando modificaciones a los datos o simplemente vindolos, no existe ningn tipo de locks en la base de
datos.

El control de cambios (es decir la validacin entre la lectura inicial y la confirmacin) se realiza a nivel de
cada tabla involucrada en la Transaccin Web. Los valores ledos 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 tamao.

Prompts
Para cada Transaccin Web se genera un Web Panel que ser el Prompt por defecto (autoPrompt), y los
Prompts correspondientes a las claves forneas 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 generacin por defecto de los Prompts, se tiene la propiedad a nivel
del modelo: Generate Prompt Programs.

La cual permite o no la generacin de las referencias a los Prompts.

Valores:
Yes: Crea el Prompt asociado a la Transaccin que est siendo especificada as como las referencias en la
lgica interna de la Transaccin.
No: Elimina las referencias a los Prompts asociados a la Transaccin. La primera vez que la Transaccin se
especifique con esta opcin, 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

Tambin es posible definir Web Panels como Prompts tal como se ver a continuacin.

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 Transaccin 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.

Programacin de un Web Panel como Prompt

El Web Panel que ser utilizado como Prompt debe cumplir ciertas condiciones:

Debe tener uno o ms parmetros de tipo output. Puede tener de in, de inout tambin
pero lo importante es que tenga de output que son los que devolver.

Alguno de los atributos, variables, text blocks o imgenes del form debe tener la propiedad
de diseo ReturnOnClic en True. Puede tener habilitada esta propiedad en ms 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 parmetros definidos como de output) no se determinan al
realizar clic, sino al desplegarse la pantalla por lo que tienen que tener el valor vlido a
retornar en cada Load (si se muestra un grid, por ejemplo).

Si uno de los atributos, variables, text blocks o imgenes del form que tienen la propiedad de diseo
ReturnOnClic en True tambin tiene programado el evento Clic, el cdigo 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, tambin se implement la funcin
ReturnOnClic() (sin parmetros) 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 tambin cualquier Transaccin con
interfaz Web.
La posibilidad de definir una Transaccin 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 informacin relacionada, menues, etc..

La definicin y el uso de una Transaccin como Web Component es como lo vimos en el captulo
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 grabacin no se mantiene por cada componente. Esto significa que si el usuario ingresa
a un componente y realiza una operacin (por ejemplo modifica un atributo de la Transaccin y
oprime el botn Aplicar Cambios por primera vez) y no reconfirma la misma, al realizar una

operacin en otro componente (por ejemplo un GET), se pierden los cambios realizados en el
primero (es decir se refresca la pgina con el valor y estado que tena antes de modificar el atributo).

INTRODUCCIN
Las aplicaciones Web necesitan un look & feel bastante ms sofisticado que las aplicaciones Win y
los desarrolladores no tenemos las habilidades y el tiempo para lograr un diseo con esas
caractersticas.

Por esa razn, por lo general se opta por contratar servicios de diseo. Por lo cual, es necesario
luego integrar ese diseo con la aplicacin GeneXus. Esta integracin se logra a travs de los
Themes.

Para el diseo grfico contamos con el Editor de Themes, una herramienta de libre distribucin
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) deban 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 heredarn 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 diseo que se requiera hacer, se realizar en el Theme (sin necesidad de
generar/compilar absolutamente nada), de esta forma se logra la uniformidad esttica 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 captulo 2 se di una introduccin del objeto Theme e incluso se realizaron
algunos ejercicios para comprender su funcionamiento.

Veremos a lo largo de este captulo en forma ms completa, las diferentes funcionalidades que
brinda este objeto.

Generalidades de un Theme
El editor de temas es una herramienta de libre distribucin que se puede ejecutar en forma
independiente de GeneXus. Esto es para que la herramienta pueda ser usada por el diseador
grfico, y el desarrollo de la aplicacin se independice e incluso se paralelice con su diseo.

Se despliega como una estructura jerrquica de Clases, la siguiente es una imagen del editor de
temas:

Se puede observar que descendiendo en la estructura jerrquica, 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 cmo se
visualizar en ejecucin 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 excepcin de la Clase Messages, la cual no se corresponde a un control
GeneXus, el significado de esta clase se explicar ms adelante)

Cada clase rene un conjunto de propiedades configurables por el diseador, y constituye un

diseo para un tipo de control GeneXus.

Una clase podr ser asignada a un control en tiempo de diseo, y en tiempo de ejecucin a travs 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 estn asociadas a esta clase.

WarningMessages: todas las reglas messages estn asociadas a esta clase.

Para utilizarlas, se configuran de igual forma que las restantes clases. La diferencia est en que no se
tiene ningn control GeneXus asociado. La asociacin de estas clases es automtica.

Nota 1: Existen tambin clases especficas de botones, correspondientes a aquellos que son
generados en forma automtica 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 razn, 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:
Blobs:

ReadonlyX (descendiente de X)

BlobContentX (descendiente de X)
ReadonlyBlobContentX (descendiente e BlobContentX)
BlobInputX

BlobContentX y BlobInputX son clases asignadas en tiempo de ejecucin 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 diseo, la clase BlobContentX es asignada al contenido, y la clase
BlobInputX es asignada al control cargado.
Las configuraciones no se pueden hacer en diseo, solamente en tiempo de ejecucin.
La clase ReadonlyBlobContentX es asignada en tiempo de ejecucin a los blobs readonly, que en diseo
fueron asociados a la clase X.

Si una clase es renombrada, todas sus clases que se crearon antes, sern renombradas tambin. Por
ejemplo, si X es renombrada a Y, se obtendrn las siguientes clases:
Blobs:

ReadonlyY

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 botn 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 implcitamente vinculadas en una relacin de herencia con las clases de
las cuales derivan. Como consecuencia de esto, las modificaciones en las clases padre se vern 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 descripcin de la
misma. Adems dir Inherited: True o Inherited: False segn 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 ms, 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 explcitamente, ser la clase predefinida por GeneXus.

La clase por defecto es identificada en el editor de temas por un tringulo 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 fsico que corresponde al Theme o al Template.

Name: Nombre lgico 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 diseador grfico (quien usa el editor por fuera de GeneXus) tiene las imgenes 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 imgenes quedarn apuntando a c:\cliente\imagenes que no existe en la
mquina del usuario GeneXus y por lo tanto no se va a visualizar correctamente el Theme cuando se

incorpore a la base de conocimiento (adems del hecho de que el usuario seguramente tuviera que
cambiar ese path porque no ser vlido en produccin).

Si el diseador configura la propiedad (en el ejemplo, con el valor c:\cliente\imagenes), las imgenes
quedarn salvadas en forma relativa, luego el usuario GeneXus debe copiar las imgenes a e:\images
para poder visualizar correctamente el Theme al incorporarlo a la base de conocimiento, sin
necesidad de algn otro procedimiento (como sera ir a cambiar uno por uno las imgenes utilizadas
en el Theme para que apunten a la imgen correcta).

Notas:

El valor por defecto de la propiedad Base Image Path es el directorio de la base de

conocimiento.

Se crea automticamente 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 categora: GeneXus Attribute Control Propierties,como se visualiza en la figura:

Nota: Adems, 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 estn clasificadas de la siguiente manera:

Background Properties
Box
Classification
Extensions
GeneXus Attributes Control Properties
Mouse and Keyboard
Text

Esa es la clasificacin estndar de las propiedades de los CSS (Cascading Style Sheets), con la excepcin del
grupo GeneXus Attributes Control Properties, cuyo propsito es centralizar las propiedades que pueden ser
editadas en GeneXus, para el control correspondiente a la clase.

Clase Form

El control Form, se modifica segn la clase Form. Las propiedades bajo el grupo GeneXus Form
Properties son las que pueden ser editadas en las properties del control Form en diseo, ms
algunas propiedades que complementan la funcionalidad de aquellas y se encuentran en el estndar
de CSS, que son las siguientes:

Background

BorderColor

BorderStyle

BorderWidth

Font

TextColor

Height

Width

Las siguientes propiedades an 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 definicin 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 imgenes 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 imgenes).

En la documentacin 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 diseo
en GeneXus, es:

BorderStyle

Propiedades que estn en diseo en GeneXus, y no estn disponibles en el Editor de Themes:

BackColorStyle : Debe ser asignada en diseo.

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 diseo, 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 diseo 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 diseo 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 ms 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 tecnologa 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 cmo se visualizara 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, agregndole Custom Views, que son archivos
.HTML. Para eso, agregar una nueva vista a travs 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 Transaccin.

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 configuracin 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
caractersticas de un Tag HTML, en un determinado contexto. Es decir, siempre que se quiera
establecer la configuracin 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 configuracin de los Tags HTML, dada en el editor, se ve reflejada en la pgina Web si esos Tags
estn en el HTML de la pgina, en el mismo contexto con el cual fueron definidos en el editor.

El contexto est determinado por la jerarqua con la cul se definen los Tags.
Para el ejemplo que mencionbamos anteriormente, de definir las propiedades de los links dentro
de una tabla, se hara 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 sera definir un tag body y la propiedad ForeColor del mismo, con lo cual el
texto libre de la pgina tomar ese color.

Demo: Temas
Cuando se hace una aplicacin Web es necesario que el sitio se vea uniforme.
Esto implcitamente 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 habra que hacerlo en todas las pginas
del sitio para mantener la uniformidad del mismo. Antes, haba 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 automticamente.

Cuando se salva un Tema con el Editor de Temas ejecutado desde dentro de GeneXus, se obtiene un archivo
con extensin .CSS (Cascading Style Sheet) en el directorio Web del modelo.
En tiempo de ejecucin, ese archivo .CSS (que contiene la definicin de las clases) es referenciado en el
Header de las pginas 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 produccin, para que el usuario final perciba los cambios estticos realizados (no es necesario generar
ni compilar!!).
Veamos un ejemplo con la aplicacin del curso.
Observe que los objetos de la base de conocimiento del curso estn asociados al Tema Default (a travs de
la propiedad Theme del objeto), y los controles de cada uno de los objetos estn asociados a la clase
default correspondiente (propiedad Class de los controles).
Realizaremos algunos cambios a las clases de Tema Default y veremos cmo se reflejan los cambios en
ejecucin.
Note que en nuestro caso, el directorio de produccin coincide con el directorio Web del modelo, por lo cul
no es necesario copiar el .CSS a ningn lado.
Haga clic aqu para ver la demostracin
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 opcin Object / New
Object / Theme

Un nuevo Theme consiste de los siguientes elementos:

Un nombre (nombre del nodo raz)

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 diseo. 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 botn
Login para que sea BtnLogin.

Haga clic aqu para ver la demostracin

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 situacin.

Haciendo clic con el botn derecho sobre la propiedad correspondiente, aparece un men Inherit
Value. Seleccionando dicha opcin, la propiedad pasar a heredar el valor de la misma propiedad
del padre.

La derivacin de clases, y en particular la "herencia" le brinda al usuario facilidades en la tarea de

mantenimiento de las Clases y claridad en el diseo.

Por ejemplo si se define una clase Bullet derivada de Texblock, con el fin de definir las propiedades
de los textos en listas con vietas. Supongamos que ahora se quiere tener otra clase para los textos
anidados a aquellos que estn asociados a la clase Bullet, y se desea que tengan las mismas
caractersticas que la clase Bullet a excepcin de la indentacin. Llamemos a esa clase SubBullet
y cremosla 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 habindose
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 demostracin

Haga clic aqu para ver cmo 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 extensin .CSS (objeto
Theme de la base de conocimiento). Asimismo, dentro y fuera de GeneXus, el editor permite trabajar con
archivos con extensin XML.
Esta ltima funcionalidad (trabajar con archivos XML) permite la integracin entre el editor como aplicacin
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 disear un sitio utilizando el editor de temas independientemente de GeneXus; el
producto de su trabajo sern archivos .XML que otro usuario (posiblemente quien desarrolle la aplicacin)
podr integrar a la base de conocimiento, y salvar como objetos GeneXus Theme (archivos .CSS).

Por otro lado, tambin se podr desde la base de conocimiento salvar un Theme con extensin .XML de
manera de poder editarlo y modificarlo por fuera de GeneXus.
Con esto se logra independizar el trabajo de diseo de las pginas, del desarrollo de la aplicacin.
Dado un diseo en formato XML (un Template creado con el editor por fuera de GeneXus), se puede
incorporarlo a la base de conocimiento rpidamente siguiendo los siguientes pasos:

Abrir el Template usando el editor desde dentro de GeneXus (opcin File / Open Template)
Salvar el Template como un Theme (opcin File / Save As)

Opciones del Editor para el manejo de Themes y Templates

OPCIN SAVE AS
Cuando el Editor es ejecutado desde dentro de GeneXus, mediante la opcin 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 opcin 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 opcin 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 dilogo:

Mediante este dilogo 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 automticamente 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 mquina, 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 dilogo (men File / New del editor) se puede crear un nuevo Theme en base a
alguno de los Templates (incorporados mediante el dilogo 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 dilogo
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 extensin .XML) que podrn ser usados
opcionalmente como default. Estos quedan en el folder THEMES de la instalacin de
GeneXus.

Los Templates que son incluidos con la versin 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 diseo 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 dilogo
para los colores.

Esta configuracin se guarda por usuario.

Las opciones son:

Default

Designer

Si se usa el dilogo "Designer", y se definen Custom Colors (botn Add to Custom Colors), estos
valores son almacenados con el Theme.

De esta forma si se define un conjunto de colores bsicos para el Theme, estarn disponibles cada
vez que se quiera editar. Por ejemplo: si se crea un Theme Gold (toda una combinacin de amarillos
y naranjas), en los custom colors quedan los colores definidos como custom.

El editor como aplicacin independiente

Usando el editor desde fuera de GeneXus, se pueden salvar los Themes en archivos con extensin
XML.

Se puede llamar al editor desde fuera de GeneXus, haciendo doble clic en el GXThemeEditor.exe o desde
lnea de comandos pasndole como parmetro opcionalmente un archivo con extensin .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.

Creacin de un objeto Theme por defecto cuando se efecta la creacin 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 inicializacin de este objeto se utiliza el Theme definido como Default en el editor (Default
Template como se vio anteriormente).

Interaccin diseador desarrollador de la aplicacin Web

Debido a las exigencias de un buen diseo esttico del sitio, por lo general es necesario contratar el
servicio de un diseador grfico. De ah es que surge la necesidad de una buena interaccin entre el
diseador y quien programa la aplicacin, e incluso el hecho de paralelizar ambas tareas.

Veremos en un ejemplo prctico, como a travs del Editor de Temas, se logra independizar el diseo
de las pginas, del desarrollo de la funcionalidad de la aplicacin.

El diseador grfico (sin tener GeneXus instalado en su mquina), se instalar el Editor de Temas a
travs 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 aplicacin que estamos desarrollando.

Lo primero, es ejecutar el GXThemeEditor.exe. Una opcin es ejecutarlo desde la instalacin 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 aplicacin independiente a GeneXus, disearemos un
Template y lo salvaremos en algn directorio (es un archivo con extensin XML).

Haga clic aqu para ver como creamos el Template por fuera de GeneXus.

Una vez salvado el Template en algn directorio, vamos a ejecutar esta vez el Editor de Temas desde
adentro de la aplicacin GeneXus (mediante la opcin 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 extensin XML).

Para salvarlo como un Theme de la base de conocimiento, ir al men File / Save As, y estando
seleccionada la opcin GeneXus del dilogo, 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.

INTRODUCCIN
Los reportes definen procesos no interactivos de extraccin 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 interaccin con el usuario durante el proceso de extraccin. El proceso es solo de
extraccin: no pueden actualizarse los datos ledos.

En el presente captulo estudiaremos las particularidades de este tipo de objetos en ambientes Web.

Propiedades del objeto Report en Web

Una solucin para la generacin 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 tambin
grabarlo en el disco del servidor para luego procesarlo.

En este captulo profundizaremos en la generacin de reportes PDF.

Invocacin del reporte

El reporte se podr llamar desde el objeto Web tanto con el comando o funcin LINK como con el
comando CALL. Tambin es posible abrir el Acrobat Reader e ingresar directamente la URL.

Configuracin 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 funcin msg,
as como la regla ask.

Al definir que un objeto es main (en este caso un Reporte, pero podra ser una Transaccin, Web
Panel, etc.), GeneXus genera un programa ejecutable con la lgica 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 definicin 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 disear el layout del reporte como Usted lo crea ms conveniente)

Lo que haremos es navegar por la tabla FLIGHTS para el nmero de vuelo recibido por parmetro y
luego navegaremos por la tabla PRICES de dicho vuelo.

Es necesario configurar las siguientes propiedades al objeto reporte recin 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 demostracin

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 ejecucin del reporte

Se necesita el Adobe Acrobat Reader en el cliente, para visualizar el reporte PDF.

INTRODUCCIN
Una pregunta muy importante a la hora de desarrollar una aplicacin para Internet, es la siguiente:

Es segura nuestra aplicacin en Internet?

Como la seguridad es un concepto muy amplio, la respuesta a esta pregunta no es sencilla. Sin
embargo, dependiendo del tipo de aplicacin que se est desarrollando, este punto puede ser
crucial.

Se puede decir que al publicar una aplicacin 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 aplicacin

A lo largo de este captulo 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 estn enfrentando bsicamente los
siguientes riesgos:

Intercepcin de informacin enviada a travs de la red desde el browser al servidor o

viceversa

Errores o problemas de configuracin del servidor Web, que permitan a usuarios no

autorizados:
o
o

Acceder a informacin confidencial que se encuentra en el servidor

Ejecutar comandos que afecten el comportamiento del servidor y les permita
ingresar al sistema

Intercepcin de informacin

El protocolo TCP/IP no fue diseado para ofrecer servicios de comunicacin seguros. En

consecuencia, la informacin enviada desde el browser al servidor Web o viceversa puede ser

interceptada por alguien. Es por esta razn que se debe agregar tecnologa adicional para resolver
problemas de seguridad.

Desde siempre, existe una nica tecnologa 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 envan al browser, as
como desencriptar la informacin recibida del mismo.

El standard ms conocido de autenticacin y encriptacin de datos para el Web es el SSL. Este

standard fue propuesto por Netscape Communications Corporation y es el que soportan la mayora
de los browsers (Internet Explorer, Netscape).

Para habilitar la encriptacin 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 encriptacin de datos. Finalmente, para activar la encriptacin de los
datos a transferir, todo lo que el usuario debe hacer es realizar la solicitud del recurso a travs del
protocolo HTTPS: en lugar de HTTP.

La seguridad ofrecida por el servidor Web, depende en parte tambin del largo del certificado
soportado. Cuanto ms largo sea el mismo ms segura es la comunicacin de los datos. Hay que
destacar que los servidores seguros protegen nicamente la informacin 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 generacin automtica 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 pblico 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 intentarn entrar por la ventana abierta. Los resultados pueden

ser variados, desde el simple descubrimiento que la pgina principal del sitio Web fue cambiada,
hasta el robo de la base de datos que contiene la informacin de sus clientes.

Es entonces importante que el administrador del sistema defina polticas 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, instalacin de firewall).

Existe abundante documentacin sobre el tema, que es recomendable leer, para saber que pasos
debera seguir al publicar documentos, o aplicaciones en su sitio Web.

Bibliografa

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/enus/Default.asp?url=/resources/documentation/WindowsServ/2003/enterprise/proddocs/enus/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 tambin un punto sensible a la hora de publicar una
aplicacin 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
deberan estar negadas.

Desde el punto de vista de la configuracin del modelo de GeneXus, no se deben realizar

configuraciones especficas para mejorar la seguridad de la base de datos.

Seguridad a nivel de la aplicacin

A nivel de la aplicacin, la seguridad depende del tipo de aplicacin que se est desarrollando. La
implementacin de controles de seguridad, es importante en aplicaciones en las cuales los usuarios
acceden a informacin confidencial, como por ejemplo sus datos personales. La razn por la cual son
necesarios dichos controles, es que los parmetros que se pasan entre objetos Web (y entre pginas
dinmicas en general) viajan visibles al usuario, como por ejemplo:

http://www.artech.com.uy/cgibin/hmyapp.exe?1,NOMBRE.

Por lo tanto, por ms que se disponga de una pgina de login, donde se valida el usuario y su
contrasea para ingresar al sistema, el usuario eventualmente podra saltearse la misma, ingresando
en el navegador la URL de la siguiente pgina con un cdigo de usuario vlido.

Para evitar que se burle el control de acceso y permitir que se acceda a informacin confidencial, es
que se debe agregar algn tipo de control adicional de seguridad.
A continuacin, 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 Transaccin Security que almacena el usuario logueado, un nmero
randmico de sesin y la fecha y hora del comienzo de la misma. Mediante este nmero de sesin se controla
que un usuario no pueda acceder a los datos de otro usuario.

Cada vez que el usuario ingresa a una pgina del sistema, se chequea el nmero de usuario y el
nmero de sesin. 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 pgina donde se pide login y
password nuevamente. Este nmero de sesin es vlido por un tiempo determinado que se
configura en el procedimiento. Si el usuario est logueado por ms de dicha cantidad de tiempo, se
muestra la misma pantalla de error.

A continuacin se presenta un ejemplo del funcionamiento de las sesiones. La pgina principal de la

aplicacin es Login, donde se controla la validez del usuario y su contrasea.

La primera vez que un usuario ingresa al sitio debe registrarse al mismo, creando un nuevo usuario
(navegando a travs del link Click here to complete a brief registration form, el cual lo lleva a la
Transaccin 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 nmero randmico de sesin, la fecha y hora de la
registracin.

Luego se llama a la pgina donde se muestra la informacin 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 nmero de sesin 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 pgina de error, donde se explica al usuario la causa del mismo. Hay que darse cuenta
que en ese caso nunca llegara a visualizarse la pgina 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 nmero de sesin asignado al usuario, as como la fecha y hora de generacin
del mismo. Igualmente que en el caso anterior, en el Web Panel MainSearch se invoca al
procedimiento CheckSession para validar la sesin.

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 pequeos que se graban desde un Web site en las mquinas de los clientes.
Los programas CGI o cualquier aplicacin que corre en un servidor, puede leer o grabar las cookies
en el cliente.

El uso ms comn de las cookies es la identificacin de usuarios. Cuando un usuario se registra en un

Web site (Portal o E-Store), el sitio graba una cookie en la mquina del cliente con la identificacin
del cliente. De este modo la prxima 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.

Tambin existen otros usos de las cookies, como rotacin de contenido (especialmente avisos),
mantener estado de una aplicacin, etc. Incluso se pueden usar como mtodo de almacenar el
carrito de compras de modo que la informacin del mismo quede en la mquina 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 sesin, en otros para el usuario), aunque se podran poner todos los

valores de las preferencias en cookies. Lo ideal es tener una clave que viaje y con esta clave leer la
informacin del usuario. De este modo la informacin del usuario no viaja hacia el cliente, ni est en
la URL. (Ej. tarjetas de crdito, nombre, direccin) simplemente permanece en el servidor.

Hay que tener en cuenta que existe un lmite en cuanto a la cantidad de cookies que el cliente puede
aceptar. El mximo 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 aplicacin graba
ms de 20 cookies las ltimas van a borrar los valores de las primeras. Adems existe un lmite de
tamao de 4K por cookie, si una cookie supera ese lmite es truncada.

El usuario puede preferir no grabar la cookie permanentemente (por Ej. si est accediendo desde
una mquina pblica como podra 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
mtodo 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 ms 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 razn 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 ms relevante es la fecha de expiracin).
3. El browser recibe la respuesta y, si el valor de la fecha de expiracin 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 expiracin, las cookies se borran.

Para obtener ms informacin tcnica sobre cookies y su uso :

http://www.cookiecentral.com

Descripcin

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 vaco.

Sintaxis

&var_char = GetCookie(NombreCookie)

NombreCookie: carcter
&var_char: carcter

SETCOOKIE
Permite grabar una cookie. Devuelve 0 (cero) si el resultado es correcto, otro valor si hubo algn
error.

Sintaxis

&var_num = SetCookie(NombreCookie, Valor, [path], [exp-date], [domain-name], [secure])

Los parmetros entre parntesis rectos son opcionales. Si alguno de los parmetros va nulo se
asume el default.
&var_num: variable numrica
NombreCookie: Carcter. Indica el nombre de la cookie.
Valor: Carcter. Valor a almacenar.

Path: Carcter. Camino que indica para qu Web Panels la cookie es vlida. Si no se especifica, la
cookie es vlida para los Web Panels que estn en el mismo directorio que el que la grab, o en
directorios subordinados. Si se indica / la cookie ser vlida para todo el dominio.
Exp-date: Date/Datetime. Indica la fecha de expiracin de la cookie. Si no se especifica, la misma
expirar cuando se cierre la sesin en el browser.
Domain-name: Carcter. Dominio donde es vlida la cookie. Por defecto es el dominio desde donde
se cre.
Secure:Numrico. Si est en 1 la cookie se trasmite solamente si la conexin 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 lnea 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 configuracin del browser.

Ejemplos

Algunos ejemplos sencillos sobre cmo grabar una cookie son:

&Op= SetCookie(ID_USER, Str(UsrId), /, CTOD(01/01/2002) )

Aqu se est grabando una cookie -vlida 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 -vlida para los Web Panels de la misma aplicacin -de nombre
SESSION_ID_GX- con el valor correspondiente a la variable &Strsession. La cookie expirar al cerrar
la sesin del browser.

&Op= SetCookie(USR_PAIS, UY, /, ADDYR(&Today, 1), otrodom.artech.com.uy, 1)

Aqu se est grabando una cookie -vlida para todo el dominio otrodom- de nombre USER_PAIS con
el valor UY y que expirar exactamente dentro de un ao.

Tipo de Datos WebSession

WebSession es un tipo de datos de GeneXus que permite almacenar datos en una sesin de usuario
del servidor Web. De esta manera se pueden tener variables globales, accesibles mientras la sesin
est activa. Los mismos aplican a los siguientes objetos: Transacciones, Web Panels, Procedimientos;
para el lenguaje Java.

Descripcin

Los servidores Web permiten manejar el concepto de sesin. Una sesin se identifica por una clave
nica, que se mantiene mientras el usuario contine en el sitio Web. El objeto WebSession permite
almacenar informacin que ser visible desde cualquier objeto Web dentro de la sesin 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
mtodos y propiedades adecuados.

Propiedades

Id

Esta propiedad retorna un String que es el identificador de la sesin.

Ejemplo:
&Iden = &Session.Id

Mtodos
Set(key, value)

Permite hacer una entrada en la sesin 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 sesin.
Ejemplo:
&Session.remove(user)
Destroy()
Detruye el contenido de la sesin. 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 sesin 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 sesin. Esto
quiere decir que si se abre una instancia nueva del browser, se pierde la sesin, pero si se abre en
una ventana nueva se mantiene.
Los datos y el ID de una sesin 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 sesin
Si no se ejecuta el destroy(), el servidor Web destruye la sesin 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 informacin de la sesin tambin depende de la plataforma, y
condiciona la capacidad de tener la aplicacin en ms de un servidor Web. Bsicamente, si la sesin
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
sesin.

Encriptacin de Parmetros
Los objetos Web generados con GeneXus, permiten visualizar los parmetros que se pasan entre los
objetos en la barra de direccin del browser. Esto hace que, si se pasa informacin reservada como
parmetro entre objetos Web (Nmero de cliente, por ejemplo), las aplicaciones no sean muy
confiables en cuanto a la seguridad, porque un usuario podra simplemente cambiar el valor de
dicho parmetro en la URL y disponer de informacin sobre la que no debera 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 parmetros sin que el usuario de la aplicacin los conozca
o sea encriptar los parmetros.

En GeneXus se implementa la encriptacin de los parmetros de los objetos Web que van en la URL
en forma automtica y transparente para el usuario. Esto aplica a los siguientes objetos Web: Web
Panels, Transacciones Web.
Descripcin

Para poder realizar la encriptacin de parmetros en objetos Web se implementaron funciones

estndar que contienen las funciones bsicas de encriptacin y algunas funciones adicionales (las
que requieren manejo de parmetros y cookies).

Con respecto al diseo de los objetos la encriptacin de parmetros no implica ningn cambio, se
programan de la misma forma que hasta el momento.

Las ventajas del uso de la encriptacin de parmetros son:

Que los usuarios finales no sepan el o los datos que van en los parmetros

Que los usuarios finales no puedan modificar el o los datos que van en los parmetros

Se agrega la propiedad Encrypt URL Parameters a nivel de modelo, en el grupo Web Information
y tambin a nivel de objeto.

Para la propiedad a nivel de modelo los valores posibles son:

No: Indica que No se van a encriptar los parmetros que van en la URL de los objetos Web, siendo
ste el valor por defecto.
Session Key: Indica que se van a encriptar los parmetros que van en la URL, utilizando una clave
diferente para cada sesin. La encriptacin se realiza a travs 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 parmetros a otro usuario Y, ya que en este caso la URL
no va a funcionar porque se necesita la cookie correspondiente para la desencriptacin.
Site Key: Se encriptan los parmetros que van en la URL de los objetos Web, pero la clave de
encriptacin 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, adems de los valores mencionados tiene el valor Use models
property value. Este valor indica que se va a tomar el valor de la propiedad del modelo para realizar
la encriptacin de ese objeto. Este es el valor por defecto.

Consideraciones Generales

SESIONES DEL BROWSER

Una sesin del browser queda determinada por una instancia del mismo. Por ejemplo, si en un
mquina se ejecuta el browser de Internet y a partir de ese browser se abre otra sesin (a partir de

la opcin 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 sesin 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 harn con parmetros encriptados. Para tener nicamente las
llamadas entre algunos objetos con parmetros 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 parmetros, sta ltima tiene prioridad sobre la primera.

Cuando se utiliza la propiedad a nivel de objeto para encriptar parmetros, 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 pasndole
parmetros, y se quieren visualizar estos parmetros 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 ms 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 parmetros 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 encriptacin se debe ir
al servidor.

Ejemplos

Si se tiene un Web Panel que recibe parmetros y no se utiliza la encriptacin de parmetros, la URL
correspondiente al Web Panel ser del estilo:

http://localhost/HINGRESO_WebObj/hdospar.asp?2,3

Si, en cambio se utiliza encriptacin de parmetros (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==

Comparacin de alternativas de seguridad en la aplicacin

A continuacin se realiza una comparacin entre las soluciones disponibles para agregar seguridad
a una aplicacin Web.

Cookies

Ventajas

No es necesario el pasaje de parmetros 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

aplicacin.

Desventajas

Tienen limitaciones en cuanto al tamao mximo, cantidad de cookies que se pueden grabar.
Se tiene dependencia de la configuracin del browser.

Manejo de sesiones

Ventajas

Es independiente de la configuracin del browser del PC del cliente.

Desventajas

Mayor complejidad de programacin

Prdida de informacin: si el usuario pasa a una pgina esttica, 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 configuracin 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 informacin de sesin entre diferentes servidores, ya que es local al

servidor Web.

La destruccin de los datos depende del browser utilizado.

Encriptacin de la URL

Ventajas

No se requiere programacin alguna, simplemente se modifica el valor de una propiedad.

Desventajas

El tamao de la URL aumenta al ser encriptada, por lo tanto si el pasaje de parmetros es

importante, se puede llegar al mximo aceptado por el browser. Requieren del uso de cookies
en el caso de Session Key.

Caractersticas por Generador

Adems de los temas vistos anteriormente, existen algunas caractersticas 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 configuracin de seguridad para el assembly.

En cuanto a la propiedad SessionState, se refiere a la implementacin 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 sesin. Por ms informacin:
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 conexin
a la base de datos. El servidor Web solo sirve de "intermediario" como una capa ms 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 ms detalles tcnicos 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 vlido.

En caso de ser un usuario registrado y haberse identificado, se mostrarn los detalles del vuelo y
precios del mismo, pero en caso contrario se le dar al usuario un mensaje dicindole 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 aplicacin sea segura.

Utilizaremos cookies temporales para evitar que todo usuario que se registre al sitio desde el
mismo computador utilice la misma informacin de conexin.

Disponemos de un Business Object (security.xpz) que brinda los objetos necesarios para definir la
seguridad en las aplicaciones Internet utilizando cookies.

Implementacin de la seguridad en nuestra aplicacin

El control de la seguridad lo implementaremos utilizando:

Una tabla denominada Security donde se almacena para cada nuevo usuario el nmero
generado en forma aleatoria para su sesin, as como la fecha y hora de la ltima sesin
activa.
La estructura de la tabla sera entonces la siguiente:
SecId*
SecRnd (Nmero de sesin randmico)
SecDate (Fecha de Inicio de Sesin)
SecHour (Hora de Inicio de Sesin)

Una cookie denominada SECURITY que concatena (separados por una coma) el nmero
identificador del usuario (atributo UserId), as como un nmero generado en forma
aleatoria de la sesin de este usuario (atributo SecRnd).

Descripcin de Objetos del archivo security.xpz

A los efectos de una buena comprensin del xpz, se describen los objetos que lo integran y
utilizaremos.

SECURITY
Es la Transaccin que define la tabla de SECURITY.
INSERTSEC
Este Procedimiento da de alta en la tabla SECURITY la primera vez que el usuario inicia una sesin en
el Web.
CHECKSESSION
Este procedimiento valida el nmero de sesin recibido con el usuario que est logueado, y devuelve
el cdigo de validacin resultante. A la sesin se le da una validez de 1 da.
Se distinguen tres casos: cuando el usuario tiene iniciada una sesin vigente (valor S), cuando el
usuario tiene una sesin vencida (valor V) y cuando el usuario tiene una sesin, pero no coincide el
nmero randmico de sesin (valor I).
GENSESNUM
Este procedimiento actualiza el nmero randmico de sesin 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 nmero de usuario y el
nmero de sesin.
ERROR
Este Web Panel se invoca siempre que sea necesario cancelar la ejecucin de la aplicacin (por
ejemplo: cuando la sesin ya no est vigente se invoca automticamente a este Web Panel,
desplegndole al usuario el mensaje correspondiente).

Lo primero a hacer entonces es consolidar en la base de conocimiento del curso el archivo

security.xpz.
Dnde dentro de la aplicacin tenemos que grabar las cookies? o lo que es lo
mismo dnde dentro de la aplicacin tenemos que invocar a la funcin
SetCookie?
La cookie se debe grabar cuando el usuario se registra en el sitio por primera vez (en la Transaccin TUsers) y cada vez que se identifique.
1) Cuando el usuario se identifica,luego de chequear que el usuario y password ingresados son vlidos, tenemos que grabar una cookie (con
la funcin SetCookie), y luego en el evento Start del Web Panel Flights de acceso limitado a usuarios registrados tenemos que leer la
cookie (con la funcin 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 modificacin:

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 Transaccin 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 nmero de
sesin randmico. Para esto vamos a crear un procedimiento Login con el siguiente cdigo:
&SecRnd = Udp(PGenSesNum,&UserId)
&CookieVal = Concat(trim(Str(&UserId)),trim(Str(&SecRnd)),',')
&result = SetCookie('SECURITY',&CookieVal)
Este procedimiento debera recibir como parmetro la variable &UserId. En la Transaccin TUsers, deberamos agregar en las reglas:
Call(Plogin,UserId) on AfterComplete;
Hagamos entonces estas modificaciones necesarias

Dnde tenemos que leer las Cookies? Es decir dnde debemos invocar a la
funcin 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 quedara 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 sesin de dicho usuario est vigente

FlightDsc.Link = Link(Hflights, FlightId)

Else // si la sesin de dicho usuario no est vigente
Call(HError)
Endif

EndEvent
Haga clic aqu para ver la demostracin

Notas:

Observe que para el usuario de prueba que se estaba usando en los ejercicios anteriores, al
momento de creado no se tena 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 captulo, d de alta un nuevo usuario
a travs de la Transaccin Users.

El Web Component Login, es el que tiene la lgica de seguridad y es importante que el

usuario en cualquier parte del sitio se pueda logear, y navegar por toda la aplicacin 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.

INTRODUCCIN

Patterns es una herramienta, que se puede utilizar tanto desde GeneXus como en forma
independiente. Permitiendo aplicar a una base de conocimiento cierto patrn (pattern), y que se
generen todos los objetos GeneXus necesarios para implementar el patrn, para aquellas instancias
que se hayan seleccionado.

En este captulo 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 comn 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 comn:

grid en el form

un conjunto de variables para utilizar en filtros

ordenamiento de los datos que se muestran

acciones que se ofrecen de actualizacin de la base de datos, consultas, etc.

Esta situacin es llamada Pattern (patrn) 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 cdigo, aplicamos el concepto
de patrones a reusar conocimiento.

Hemos desarrollado un marco de trabajo con las siguientes caractersticas:

Activo: Se generan objetos GeneXus que implementan cierto patrn para una o varias
instancias elegidas.

Reutilizacin de conocimiento: Se trata de un nuevo nivel de reutilizacin de conocimiento,

ya que el mismo conocimiento puede utilizarse para diferentes situaciones.

Abierto: Cualquier persona puede crear un patrn o modicar uno existente.

De fcil uso: (A excepcin de la creacin de nuevos patrones).

Descripcin de la herramienta

Patterns es una herramienta que es parte de GeneXus 9.0 (Tools / Patterns), que puede ejecutarse
tambin como aplicacin independiente.

El objetivo de esta herramienta es el incremento de la productividad y calidad en las aplicaciones.

Bsicamente la herramienta Patterns permite aplicar a una base de conocimiento cierto patrn
(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 diseo 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 rpidamente.

A su vez la herramienta permite crear Patterns nuevos, siendo esta una tarea un poco ms compleja.

Requerimientos

Esta herramienta se puede utilizar nicamente con los generadores .NET y Java. Para obtener ms
detalles de los requerimientos de software de instalacinla ver la siguiente pgina:
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 Transaccin (o para todas aquellas
Transacciones que se deseen), todos los objetos necesarios para tener una aplicacin Web: trabajar
con, views, seguridad, etc..

Bill of materials: Permite generar a partir de una Transaccin, otra que representa la relacin
compuestocomponente.

OAV: Objeto-Atributo-Valor; genera a partir de una Transaccin otras dos Transacciones que
permiten extender la original, con el objetivo de permitir definir atributos en tiempo de ejecucin.

Adems, seguimos trabajando en la definicin de nuevos Patterns. Tenemos un catlogo con una
lista de Patterns, algunos de los cuales ya estn implementados y otros sugeridos para una futura
implementacin. Para acceder al catlogo:
http://wiki.gxtechnical.com/wiki/tiki-index.php?page=Business+Patterns+Catalog

Demo: Configuracin de Patterns y definicin de instancias

Una vez abierta la base de conocimiento en GeneXus, en el modelo de diseo, se dispone de la
opcin 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 patrn. 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 demostracin

2) A continuacin, mostraremos cmo hacer para modificar los Instance File. En este caso
quitaremos algunos atributos del grid de los Work With.

Haga clic aqu para ver la demostracin

3) Build / Configure GeneXus Integration. Desde esta pantalla configuraremos las opciones de la
integracin del resultado de aplicar el pattern Work With en nuestra base de conocimiento.

Haga clic para ver la demostracin

4) Procederemos a aplicar y generar los objetos resultantes de aplicar el pattern. Para ello,
marcaremos todas las Transacciones y con el botn derecho seleccionamos Generate, Apply and
Consolidate, como se muestra aqu.

Uso de la herramienta
A continuacin veremos los distintos pasos a seguir para el uso de la herramienta Patterns y como
obtener rpidamente una aplicacin Web ejecutando en este caso el Pattern Work With. Donde

los objetos generados estarn basados en la definicin que se realiz para ese patrn y a su vez
quedarn generados con cdigo 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 diseo, se dispone de la

opcin 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 dilogo cuyo ttulo es Workspace Configuration. Este dilogo 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
dilogo si se desea, y posteriormente es posible ingresar al mismo, mediante el tem Build /
Configure GX Integration (ver paso 8).

Paso 2

Se despliega informacin 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 informacin de la base de

conocimiento programticamente.

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 fcilmente.

Esto se puede lograr de dos formas posibles en el tab KB Explorer:

Teniendo una Transaccin (o varias) seleccionada(s) se presiona botn

derecho opcin Generate Instance File.

Doble clic en una Transaccin.

Llamamos proceso de instanciacin de un patrn al proceso de aplicar un patrn a una o varias

situaciones (instancias).
En el proceso de instanciacin de un patrn las entradas son:

Instance files: por cada situacin o instancia a la cual se quiera aplicar el patrn, habr que
crear un instance file con la informacin 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 implementacin del patrn y de su aplicacin a las instancias.

El resultado que se obtiene del proceso de instanciacin de un patrn (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 jerrquica, 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 ms amigable, sencillo de usar, y con interfaz en alto nivel que provee
mayor funcionalidad para ayudar en el proceso de edicin. Por todo esto el editor Tree View es el
ms 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 an se visualizan con el nombre: <Transaction
Name.Pattern>*. Una vez salvados se visualizan con el nombre: Transaction Name.Pattern (ej:
Country.WorkWith).
Dnde se almacenan fsicamente 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, sern 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 continuacin)

Estando posicionado en el tab Folder Explorer, luego de haber

seleccionado los Instance Files (.workwith files), con botn 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 opcin Apply and Consolidate se
efectuarn tambin las siguientes acciones:

Se configurar como Tema por defecto de la aplicacin al Tema Fantastic.

El directorio Images ser copiado automticamente bajo el directorio KBPath\Templates.

La propiedad del modelo de diseo "Base image path" se configurar con el valor anterior.

Tambin es posible seleccionar una Transaccin o un grupo de Transacciones estando posicionado

en el tab KB Explorer, y ejecutar la opcin Generate, Build and Import. Pero es importante entender
que seleccionando esta opcin, se generarn los Instance Files por defecto nuevamente para las
Transacciones seleccionadas, y luego de ello, se generarn los archivos <TransactionName>.xpz.xml
correspondientes y se consolidarn en la base de conocimiento. Si se est seguro de que los
Instance Files por defecto no necesitan ser editados, es posible seleccionar esta opcin
directamente.
Paso 8

Para hacer ms fcil 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 dilogo Workspace Configuration que se abre en el momento de

abrir la base de conocimiento con la herramienta Patterns, o seleccionando luego la opcin Build /
Configure GX Integration.

OPCIONES DISPONIBLES EN EL DILOGO

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 opcin, es posible ejecutar ms acciones adems de la
generacin de objetos y consolidacin. 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 versin de GeneXus correspondiente a la base de conocimiento se detecta

automticamente (puede ser 8.0 o 9.0). El modelo se especificar / generar con dicha versin.

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 especificacin / generacin a ser ejecutado al

seleccionar.

Specify and Generate: Las opciones disponibles son:

Full Specification

Check Specification

Force Generation

Run Command: En esta opcin se debe indicar la URL que se ejecutar si se seleccion la opcin
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

Cmo modificar los objetos?

En muchas oportunidades surge la necesidad de modificar los objetos resultantes de la aplicacin de
cierto pattern. A continuacin veremos las formas posibles de realizar las modificaciones.

Mediante GeneXus

Modificando los objetos GeneXus generados. Esta solucin 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, personalizndolo para que ofrezca configurar propiedades que

implementen las necesidades.

CMO MODIFICAR LAS PROPIEDADES DE LAS INSTANCIAS?

Tomando como ejemplo del pattern Work With, veremos cmo 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 generarn. A continuacin
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 cules modos se ofrecer invocar a la Transaccin. Las posibilidades y
sus valores por defecto son:

Insert: True
Update: True
Delete: True
Display: False
Export: True (exportacin a planilla Excel)

Para cada modo podr especificarse una condicin. Se proveen las siguientes propiedades para ese
propsito:

Insert Condition
Update Condition
Delete Condition
Display Condition

Si se define una condicin asociada a un modo, la invocacin para ese modo slo se habilitar si la
evaluacin de la condicin es verdadera (Ejemplo: CountryId=10).
Attributes

Este nodo permite definir cules 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 lneas mostrando los datos en el grid). Utilizando el botn derecho del mouse se puede definir un
nuevo orden (su nombre y composicin). 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 slo 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 informacin de un registro, que fue
seleccionado en el grid del Web Panel Work With (la informacin del registro es mostrada en una
solapa de un tab control, y adems hay una solapa con un grid por cada tabla directamente
subordinada, para mostrar la informacin 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 informacin necesaria para

permitir la ejecucin del mismo desde la Transaccin y mantiene el mismo estilo que los objetos
generados. Para invocar este objeto, se debe agregar la regla prompt() a la correspondiente
Transaccin.

Archivos de Configuracin
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 patrn predefinido (Work With, Bill of Materials, OAV) as como deber
haber un subdirectorio por cada patrn definido por el usuario.
Si deseamos tener un archivo de configuracin 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 aplicarn 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 configuracin, la herramienta Patterns ofrece el tem: Tools/Change
Pattern Configuration, tal como se muestra a continuacin:

En este archive se pueden configurar diversas propiedades tales como:

WW Configuration

THEMECLASSES
Esta opcin 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 visualizarn en el grid.
SaveGridState Indica si los Orders, Current Page y Filtros se guardarn para los Web Panels Work
With o no.
EnableDisablePaging Indica si los botones de paginado sern deshabilitados o no, cuando la
correspondiente accin no est habilitada (por ejemplo, el botn Next cuando se est visualizando
la ltima pgina).

TAB
MaxTabs Indica cuantos Tabs sern visualizados en un View. Si hay ms Tabs que los indicados en
MaxTabs, se generar un Scroll para permitir navegar a travs de los mismos.

StandardActions

DefaultMode Indica cuando incluir la accin 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 implementacin 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 caracterstica puede ser usada, por ejemplo,
para mantener informacin sobre el usuario conectado a la aplicacin (especialmente para la
autenticacin/autorizacin), la empresa corriente para sistemas multi-empresa, etc.. Se puede
modificar la variable y el procedimiento invocado, modificando la seccin 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 implementacin incluye
un procedimiento llamado IsAuthorized, que es invocado en el evento Start de cada Web Panel, para
controlar la autorzacin del acceso a dicho recurso. Si el procedimiento retorna false, significa que el
usuario no tiene autorizacin para ejecutar la aplicacin, y por lo tanto el Web Panel de usuario no
autorizado (NotAutorized) es invocado. En a implementacin de ejemplo, este procedure siempre
retorna True, se debera modificar segn las necesidades del caso. Es posible modificar el objeto
invocado,modificando la seccin Security en el archivo WorkWith.Config.

Demo: Patterns y Seguridad

Despus de haber aplicado el pattern Work With seguiremos avanzando en cuanto a la seguidad de
la aplicacin. Para lo cual, reutilizaremos el procedure IsAuthorized para mostrar como se
programara el acceso a los distintos objetos:

Call(PLoadContext, &Context)
If (&GxObject = 'TUsers' and &Context.Profile <> 'ADMINISTRATOR' )
&Authorized = Boolean.False
Endif. Veamos entonces como quedara dicho procedimiento:

Adems de la siguiente regla:

parm(in:&GxObject, out:&Authorized);

Haga clic aqui para ver la demostracin

INTRODUCCIN

Cada vez ms, 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
reingeniera a las aplicaciones existentes y tambin, en muchos casos, la necesidad de desarrollar
nuevas aplicaciones para Internet.

Existen varias diferencias entre los ambientes GUI (aplicaciones con Interfaz de Usuario Grfica) y
Web, las que debern evaluarse al momento de determinar la conveniencia del tipo de aplicacin a
desarrollar. La migracin no debera verse como una conversin objeto a objeto sino que
normalmente es una modernizacin de la aplicacin usando otras herramientas tales como Patterns,
GXPortal, GXFlow, Reporting, etc..

En este captulo veremos los principales aspectos a ser tenidos en cuenta por los usuarios GeneXus.

INTRODUCCIN
En el desarrollo de una aplicacin Web, la calidad de la interfaz con la que interacta el usuario
determina el xito de la aplicacin. La calidad de la misma est definida por una serie de pautas y
tcnicas. A este conocimiento se le llama Usabilidad.

La interfaz de una aplicacin Web est determinada a grandes rasgos por la estructura de la
aplicacin, el diseo de la misma y de su contenido.

Con estructura de la aplicacin nos referimos a la ubicacin 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 diseo.

El diseo de la aplicacin es la parte grfica de la misma, el conjunto de imgenes, colores, formas

que va a tener la aplicacin.

El diseo del contenido permite que el mismo sea cmodamente ledo y correctamente
interpretado.

A lo largo de este captulo desarrollaremos cada uno de estos puntos para lograr aplicaciones Web
exitosas y fciles de usar.

Estructura de la aplicacin

Diseo de la aplicacin

Diseo del contenido

Estructura de la Aplicacin
Con estructura de la aplicacin nos referimos a la ubicacin 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 diseo.

Es importante que la estructura del sitio est reflejada en todas las pginas 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 informacin a encontrar. Siempre que
pueda aprenda de sitios exitosos de su misma rea para realizar una estructura similar, que resulte intuitiva
para el mismo pblico objetivo.
Es recomendable:

Mostrar las barras de navegacin en todas las pginas.

No cambiar la ubicacin de las opciones de los menes segn cambien las pginas (mantener
consistencia).
Aplicar los mismos conceptos para las mismas acciones (links, botones, bullets, etc.).
No poner links a la misma pgina en la que me encuentro.

Permitir que el usuario siempre controle la navegacin: no deshabilitar botones estndares de los
navegadores ni botones del mouse.
Si usa un mapa del sitio (Sitemap) brinde la informacin de donde est el usuario en cada momento.
Puede incluir una pequea descripcin de qu ofrece cada opcin del men.

Navegacin
La navegacin de una aplicacin permite ir a las distintas partes, sectores, pginas de la aplicacin
rpidamente y en forma intuitiva. La estructura del sitio se debe reflejar en la navegacin permitiendo
contestar las siguientes interrogantes:
Dnde estoy?
Dentro del universo de sitios/ aplicaciones Web: Esto se logra mostrando el logo del sitio/ aplicacin Web
en todas las pginas. La ubicacin 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 pgina de inicio de la
aplicacin o la pgina principal del sitio.
Dentro de la estructura de la aplicacin Web. Para ello se recomienda:

Marcar la opcin seleccionada en la barra de navegacin.

Usar ttulos en cada una de las pginas, dentro del rea de contenido de forma
que el usuario sepa dnde se encuentra.

Nombrar las pginas en el cabezal de las mismas para que se identifiquen en el

grupo de pginas que tiene abiertas el usuario. En GeneXus esto se hace usando
la propiedad Caption del Form (Form.Caption). Para mostrar el nombre de la
aplicacin y de la pgina se puede usar un formato como los siguientes:

Sitio: pgina (Ej: GeneXus: Capacitacin)

Sitio pgina

Sitio > pgina

Usar nombres cortos para las pginas igual que para los sitios de modo que se
puedan visualizar bien en el cabezal de la pgina.

Dnde estaba?
Para indicar las pginas que el usuario ya visit, conviene dejar los colores de los enlaces con los colores por
defecto del navegador.
A dnde puedo ir?
Mostrar todas las opciones a donde puede ir el usuario desde la pgina actual, sin marearlo con demasiadas
opciones. Si las opciones son muchas, conviene agruparlas por reas o sectores y dentro de los mismos
mostrar submenes.

Herramientas de bsquedas (search)

Si usa una herramienta de bsqueda, sta debe de estar en todas las pginas del sitio, en un lugar siempre
visible sin tener que usar las barras de desplazamiento. El lugar ms intuitivo es el cabezal superior derecho, o
la columna del men izquierdo.
Se recomienda hacer esta funcionalidad lo ms simple posible de manera que sea fcil de usar. Lo ms sencillo
es tener una caja de texto y un botn 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 bsqueda debe ser claro, debe mostrar la cantidad de instancias encontradas, el texto usado
para realizar la bsqueda, el ttulo de cada pgina que contiene el texto buscado y un enlace en ese ttulo a la
pgina correspondiente.

Menes

MEN SUPERIOR
Tanto en sitios corporativos como en Intranets y Extranets se usa comnmente un men superior
que contiene por lo general las siguientes opciones:

1.

Pgina de Inicio

Si bien hay un enlace en el logo de cada pgina, nunca est de ms repetirlo ya que la pgina inicial es a
la que se retorna con ms asiduidad.

2.

Acerca de, Acerca de Nosotros, Acerca de La Empresa, La Empresa, Quines somos, etc.

Siempre es vlido un enlace a informacin sobre la empresa que representa ese sitio, el producto que se
vende a travs 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 pginas y contenido
dentro del sitio, la ubicacin de la herramienta de bsqueda y del mapa del sitio.

4.

Contacto, Contctenos, Contctese, etc.

Este enlace debe conducir a una pgina que contenga informacin para contactar a la empresa a
travs de telfonos, emails y direcciones fsicas. Esta opcin del men no debe ser un enlace a
un correo electrnico, ya que incomoda al usuario porque ejecuta su aplicacin de manejo de
emails.

En aplicaciones Web, este men generalmente contiene:

Enlace a la pgina de inicio de la aplicacin.

Enlaces a informacin importante, no relativa a la aplicacin en particular o a la parte de la aplicacin
desplegada en la pgina, pero que sirva para la aplicacin entera, que sirva de respaldo, etc..
Ejemplo: informacin de registro del usuario (a la izquierda), idiomas de la aplicacin, rea de ayuda,
contacto con soporte, pgina de la informacin de la empresa, etc..

MEN DE REAS
Muchas veces se usa el rea de cabezal para ubicar un men de reas o categoras dentro de la aplicacin o
del sitio. Generalmente se utiliza cuando hay demasiadas opciones para ubicar en el men izquierdo (ms de
10). Categorizar los enlaces y agruparlos en reas simplifica la navegacin hacindola ms intuitiva.

MEN IZQUIERDO
Este men contiene las opciones de navegacin del sitio, todos los lugares del sitio a donde se puede acceder.
En muchos sitios el men izquierdo cambia segn el rea en la que el usuario se encuentre.

Se debe mantener el mismo diseo del men, independientemente de las opciones, para que al usuario sepa
cmo usarlo ya que aprendi su uso en otras reas del sitio.

Links

Hay tres tipos de links:

Links estructurales (de navegacin)

Links asociativos. Los clsicos links que se asocian a una palabra para ver ms informacin
relacionada a la misma.
Links de informacin relacionada (Related links)

Algunas recomendaciones para la definicin de links:

Cuando se definen links subrayar las palabras importantes y brindar informacin suficiente
para que el usuario se sienta atrado a seguir el link.
Relacionar la informacin con links del tipo "ms 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
Informacin 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.

Diseo de las pginas de la aplicacin

El diseo de la aplicacin es la parte grfica de la misma, el conjunto de imgenes, colores, formas
que va a tener la aplicacin.

Se debe disear pensando en:

Velocidad de carga

Pblico objetivo

Uso de la aplicacin

Mximo aprovechamiento de los temas

Velocidad de carga

El tiempo que demora en cargarse la totalidad de una pgina determina la percepcin que va a tener
el usuario de ese sitio o aplicacin. Si la aplicacin 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 imgenes siempre que se pueda (Ej.: para los menes)
El formato de las imgenes siempre debe de ser .gif o .jpg, nunca .bmp, ya que este formato pesa
mucho ms que los anteriores.
Usar herramientas para disminuir el peso de las imgenes. Ej:
http://www.netmechanic.com/GIFBot/optimize-graphic.htm
No usar imgenes animadas.
No usar flash, ya que no slo demora ms la carga de la pgina, sino que muchas veces requiere que
el usuario instale la tecnologa.
No hacer pginas que requieran el uso excesivo de las barras de desplazamiento horizontal. Esto no
slo ahuyenta al usuario por el tiempo que le consume, sino tambin por la cantidad de contenido que
se le presenta. Es mejor hacer pginas ms cortas, con la informacin suficiente, o armar ms
pginas a partir de una.

Pblico objetivo

Debe tener en cuenta quin ser el pblico objetivo a quin se dirige, quines sern los usuarios- a
la hora de disear y elegir los colores, los tamaos de las letras y tamaos de las pantallas.

Por ejemplo, si el pblico objetivo est integrado por desarrolladores, se puede hacer un sitio o una
aplicacin con letras de tamao 8 puntos, pero no se recomienda usar este tamao para un pblico
masivo.

Uso de la aplicacin

Cuando est diseando tambin debe considerar cul es la finalidad de la aplicacin 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
pginas tengan sectores que llamen ms la atencin que el contenido principal de la pgina. Por
ejemplo, las imgenes animadas son centros de atencin. Es realmente molesto tener imgenes
movindose en distintas partes de la pgina cuando se tiene que leer. Se pueden usar imgenes
animadas si su movimiento se detiene una vez presentada la animacin. De esta forma, se logra
captar la atencin del usuario que ingresa a la pgina para transmitir el mensaje que se desea con
esas imgenes, y luego, se facilita al usuario la concentracin para la lectura del texto principal.

Si el sitio Web es un portal, donde se espera encontrar muchos focos de atencin (textos cortos,
muchos links) es ms adecuado usar imgenes animadas.

Mximo aprovechamiento de los temas (Themes)

Maximizar el uso de los temas permite ajustar el diseo en tiempo de ejecucin. Es recomendable
que cada tem que se use est definido en el tema, de forma por ejemplo, que todos los ttulos
tengan la misma apariencia y si ms tarde se quiere agregar espacio entre el ttulo y el contenido se
pueda modificar automticamente en todos los ttulos de la aplicacin. Esto es vlido para cada
tabla usada en la aplicacin, desde la que contiene las opciones del men hasta la que contiene el
contenido, los grids, las etiquetas de los formularios, etc..

Diseo del contenido

La forma de escribir en Internet difiere a la usada en publicaciones fsicas, principalmente porque es
ms difcil leer en la pantalla y el pblico es ms exigente con el tiempo que le consume obtener una
informacin. Debido a esto hay que escribir para Internet teniendo en cuenta las siguientes pautas:

Escribir lo ms corto y conciso posible. Se dice que en Internet hay que escribir entre un
50% y un 25% menos de lo que se escribira en papel.
Poner las conclusiones al principio y una opcin para ver el detalle de esa conclusin.

Tipo de letras

Se deben tener las siguientes consideraciones a la hora de elegir el tipo de letra a utilizar en una
aplicacin Web:

El tipo de fuente debe estar instalada en las mquinas destino

El tamao debe ser adecuado para el pblico objetivo y para la resolucin ms 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 mquinas son Arial, Verdana y Times New Roman.

Legibilidad

Definicin de Legibilidad: f. Capacidad o posibilidad de ser ledo, por su claridad.

La buena tipografa depende -entre muchas otras variables- del contraste visual entre una fuente y
otra, y entre los bloques de texto, los ttulos, y el espacio en blanco alrededor. Lo que ms atrae al
ojo es el contraste fuerte con patrones distintivos.

Seguir patrones que conserven la forma de organizar el texto y las imgenes en las distintas pginas
de un sitio o una aplicacin permite entender la organizacin de la informacin, intuir la ubicacin
de ms informacin y se aumenta la legibilidad de la misma.

La lectura va a ser ms cmoda 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 lnea de
cdigo.

Mrgenes

Los mrgenes definen el rea de lectura de una pgina, separando el texto principal de lo que lo
rodea.

Los mrgenes y el espacio en blanco se usan para delinear el texto principal de otros elementos de
una pgina, y usados de igual manera en todas las pginas proveen uniformidad a travs del sitio
creando una estructura consistente y una identidad visual.
Es recomendable que los textos principales tengan un margen de 5 a 10 pxeles. 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 pxeles entre el contenido y los bordes de la

celda.

La propiedad Cellspacing: especifica el ancho en pxeles de los bordes de la celda.

Alineacin de los textos

La alineacin izquierda de ttulos y contenidos es la ms recomendable para el pblico occidental.

Los usuarios en Internet en general no leen los textos palabra a palabra, sino que escanean las
pginas tomando algunas palabras de cada prrafo para entender la idea general de la pgina. La
alineacin izquierda facilita este tipo de lectura.

Links de inters
Usabilidad

Sitios con artculos sobre usabilidad y temas relacionados con mejora en los sitios Web:
EN ESPAOL
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 INGLS
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 IMGENES

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-bb3e2d5e1db91038&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 CDIGO HTML Y MS

http://zing.ncsl.nist.gov/WebTools/tech.html

INTRODUCCIN
Muchos aos atrs visualizamos que las soluciones Web seran la respuesta a muchos problemas
(distribucin, disponibilidad, accesibilidad, escalabilidad, etc). Por eso a partir de la versin 6.1 de
GeneXus incluimos generadores para esta plataforma.
La evolucin de la plataforma y el acompaamiento que GeneXus hizo de la misma, permiti que
dejara de ser una plataforma para "pginas estticas" y se convirtiera en una plataforma para
soluciones de negocio reales tanto Internet como intranets.

En la versin 9.0, adems de los generadores para esta plataforma con los cuales se cuenta desde
hace aos, se incluyen tecnologas de punta (como Ajax) viabilizando funcionalidades nuevas para el
ambiente Web, muchas de ellas "implcitas" en la versin (sin costo de desarrollo) y
extremadamente complejas de desarrollar "a mano".

El proceso de conversin de una aplicacin GUI (Interfaz de Usuario Grfica) a Web implica conocer
algunas caractersticas de esta ltima plataforma y su relacin con las funcionalidades y
caractersticas de las soluciones GUI.

Muchas veces no se trata de "convertir" la aplicacin o parte de la misma, sino del desarrollo de un
nuevo mdulo 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 captulo profundizaremos tanto en las diferencias como en la conversin de GUI a Web.

Comparacin GUI Web

Objetivo

El objetivo de este documento es brindar una herramienta de referencia, para asistir en la decisin
de migrar o desarrollar una aplicacin GUI, o una aplicacin Web. Para analizar las diferencias entre
los dos tipos de aplicaciones se compararn las ventajas y desventajas de las aplicaciones Web
frente a las aplicaciones GUI.

Existe otro artculo (Conversin de Aplicaciones GUI a Web) sobre esta misma temtica en donde se
dan los detalles tcnicos de cmo realizar esta tarea, por lo que aqu no se mencionarn esos
detalles.

Introduccin

APLICACIONES CON INTERFAZ DE USUARIO GRFICA

Las aplicaciones con Interfaz de Usuario Grafica (GUI) estn compuestas por uno o varios programas
GeneXus que utilizan objetos de tipo: Transaccin, 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 estructuracin de un documento. Si bien el

lenguaje es estndar, en la prctica, cada browser toma algunas partes de la especificacin, agrega e
ignora otras. Como consecuencia de esto una aplicacin Web puede quedar levemente distinta
segn el browser que se utilice.

Caractersticas de las aplicaciones Web

VENTAJAS DE LAS APLICACIONES WEB

Una aplicacin Web tiene diversas ventajas frente a las aplicaciones GUI.
Instalacin

Las aplicaciones Web presentan varias ventajas tanto en la instalacin y actualizacin como en los
requerimientos necesarios para utilizarlas.

Cliente fino. Para utilizar la aplicacin 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 comn 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 versin. 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 aplicacin solo se instala en el servidor. Generalmente la instalacin y actualizacin de

aplicaciones GUI en arquitecturas cliente / servidor implica, alguna instalacin en las computadoras
cliente. En el caso de aplicaciones Java GUI, esta instalacin es automtica, pero tambin existe ya
que es necesario bajar la aplicacin.

En el caso de una aplicacin Web no se requiere ninguna instalacin 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 aplicacin 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 concepcin de la aplicacin, no se tiene en cuenta la cantidad de

usuarios que van a utilizarla. Es decir que la misma aplicacin puede ser utilizada por algunos pocos
usuarios o varios cientos. El lmite estar determinado por el desempeo de la aplicacin, que
depende principalmente de la potencia de los servidores y de las caractersticas 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 aplicacin (por ejemplo los drivers de acceso a la base de datos se
pagan por cantidad de usuarios concurrentes).

Escalabilidad de servidores. El desempeo de la aplicacin depende directamente de la potencia de

los servidores en la que este instalada. Se puede migrar la aplicacin a servidores ms potentes, sin
necesidad de que los usuarios cambien el modo en que acceden a la aplicacin.

Independencia

Acceso. La aplicacin 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 pases.

Hosting Services Provider (HSP). La aplicacin puede ser instalada en un centro de cmputos propio
o puede contratarse un Hosting Service Provider (son empresas que proveen un centro de cmputos
para aplicaciones Web) e instalarla en los servidores del HSP. Para los usuarios, el acceso a la
aplicacin es independiente de donde est instalada.

Interfaz grfica

Uniformidad. La forma de navegar por la aplicacin Web ser siguiendo links o presionando botones
y si bien hay ms opciones, estas son las ms comunes y se mantendrn por toda la aplicacin. Si
bien este modo de interaccin es limitado con respecto a las aplicaciones GUI, al ser tan simple y
uniforme en toda la aplicacin, al usuario final le resultar sencillo e intuitivo aprender a utilizar
nuevas funcionalidades.

El diseo grfico es realizado por expertos. Un aspecto sumamente importante en la interfaz grafica
de una aplicacin Web es el diseo grafico. Este aspecto sumamente delicado se deja a cargo de
diseadores grficos especializados, que hacen que las aplicaciones tengan aspectos atractivos y
funcionales.

El trabajo con los diseadores grficos sigue pautas similares a la metodologa de prototipacin
utilizada en el desarrollo de aplicaciones GeneXus. Cuando los diseadores tienen listo un prototipo,
es conveniente que los desarrolladores lo evalen para validarlo desde el punto de vista del
desarrollo.
Para esto se cuenta a partir de la versin 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 interaccin con el diseador grfico, adems de todas las ventajas adicionales que
trae el uso de Temas en el diseo de la aplicacin Web. Por detalles sobre Temas ver el documento
Themes.

Al evaluar un diseo hay que tener en cuenta ciertos aspectos:

Impacto del diseo de las pginas Web finales. Si se utilizan demasiadas imgenes, con
muchos botones, el tamao final de la pgina, puede ser excesivamente grande, por lo que
se demorar mucho el acceso. La recomendacin es cuidar de que las imgenes sean de
pocos Kbytes. Los links de texto son muy livianos, en el caso de una aplicacin muy accedida,
puede ser conveniente utilizarlos. Los sitios Web de Amazon y Yahoo, son buenos ejemplos
de interfaces livianas, con pocas imgenes y muchos links de texto.

El diseo debe ser consistente. Por ejemplo la tipografa, los colores, la ubicacin de
botones, etc. debe seguir una pauta bien definida, que los desarrolladores deben respetar al
mximo.

El diseo debe ser simple y sencillo. El exceso de detalles grficos, puede complicar el
desarrollo y evolucin del sitio.

El diseo debe ser robusto de modo de poder soportar evoluciones, y nuevos

requerimientos.

Componentizacin. Es muy importante que la estructura de las pginas 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 pgina dividida en Web Components, permite

tratar cada componente en forma independiente. Esto no solo hace las interfaces ms robustas
frente a cambios y extensiones, sino que adems al cambiar un componente, se reflejan los cambios
en todas las pginas que lo incluyen. O sea que no es necesario reprogramar todas las pginas, solo
el componente adecuado, haciendo del mantenimiento de la aplicacin sencillo.

Integracin de nuevas aplicaciones. La interfaz con el usuario se puede personalizar dinmicamente,

de acuerdo a las caractersticas del usuario. Por ejemplo con menes donde las opciones se cargan
dinmicamente, segn las aplicaciones a las que puede acceder el usuario. De este modo se logran
aplicaciones ms integradas y donde es ms sencillo incorporar nuevas aplicaciones.

Interfaz multimedia. Es muy sencillo incluir en las aplicaciones Web caractersticas multimedia como
audio, video, imgenes, etc.

Application Service Providers y servicios Web

Los Application Service Providers (ASP), son empresas que brindan servicios y soluciones, basadas en
software, a travs 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.
Tambin habilita a contratar a otros ASP para potenciar las aplicaciones propias.

Integracin de aplicaciones Internet e Intranet

Las aplicaciones Web desarrolladas pueden ser utilizadas en Internet o en una Intranet, para uso
interno. Adems 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 interaccin con pginas Web se utiliza el lenguaje JavaScript. El
cdigo escrito en este lenguaje es incorporado en el HTML e interpretado por el browser. Java es un
lenguaje de programacin 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 travs de Internet. Por lo tanto se pueden
incorporar aplicaciones GUI desarrolladas en Java, para potenciar la aplicacin Web.

Mltiples formas de acceso

Mltiples tecnologas como computadores de bolsillo y telfonos celulares estn teniendo un fuerte
desarrollo, principalmente como formas alternativas de acceso a Internet. Las caractersticas de
hardware de estos dispositivos hacen que las aplicaciones Web sean las ms adecuadas. La principal
diferencia con las aplicaciones Web para estos dispositivos es el tamao reducido de la pantalla. Si
bien es necesario crear una versin particular para el dispositivo, se puede reutilizar mucho
conocimiento de una aplicacin Web ya desarrollada.

INCONVENIENTES DE LAS APLICACIONES WEB

En la siguiente seccin se discuten las desventajas que presentan las aplicaciones Web frente a las
aplicaciones GUI.

Es necesaria una reingeniera de la aplicacin. El lenguaje HTML presenta ciertas limitaciones que
implica que migrar aplicaciones GUI a aplicaciones Web no sea una tarea automtica. Entre los
puntos que deben tenerse en cuenta al realizar la reingeniera de la aplicacin se destacan los
siguientes:

Seguridad. Es imprescindible tener un esquema de seguridad en la aplicacin, 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
aplicacin puede requerir que algunas aplicaciones particulares necesiten un esquema ms fuerte de
seguridad y requieran pginas 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 Lgicas) en los objetos Web, se mantiene
nicamente durante la ejecucin del objeto. Cuando la ejecucin termina se deben hacer commit o
roll back. Por lo tanto no es posible definir una UTL a travs de varias Transacciones Web. Sin
embargo, es posible mantener la UTL a travs de varios procedimientos que se invoquen unos a
otros, siempre que se mantengan dentro de la misma ejecucin. En las aplicaciones GUI es comn
encontrar que durante varias transacciones se van ingresando datos y luego en la ltima transaccin
se hace el commit de todos los datos ingresados, por lo que se deben contemplar estos casos en la
reingeniera de la aplicacin. Las alternativas posibles a esta situacin son:

Unificar todas las Transacciones GUI en una sola Transaccin Web.

Dividir el proceso de ingreso en varias etapas y utilizar mltiples Transacciones Web. Al

finalizar el ingreso podra tenerse un procedimiento que valide que el ingreso en varias
etapas es consistente.

Ingresar toda la informacin en tablas temporales y luego ingresar la informacin a la base

de datos mediante procedimientos.

Limitacin entre la interaccin de objetos GeneXus. La interaccin entre objetos GeneXus, en

aplicaciones Web es ms limitada que la interaccin 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 aplicacin GUI, debe ser tratado en la reingeniera
de la aplicacin.

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 lneas del grid. En las aplicaciones GUI,
el tamao de los formularios se determina en el diseo de este y queda fijo en el momento de
ejecucin. En las aplicaciones Web, el tamao de la pgina Web se puede extender (horizontal o
verticalmente) si se presentan muchas lneas en los grids.

La seleccin de lneas es diferente. En las aplicaciones GUI, las lneas se seleccionan al hacer clic en
ellas, adems se puede seleccionar un rango de lneas, continuo o con lneas salteadas, todo esto sin
necesidad de programacin extra. En las aplicaciones Web, la seleccin mltiple de lneas debe
programarse mediante campos de chequeo.
Una posibilidad es permitir la seleccin de mltiples lneas y utilizar el carrito de compras (se
describe ms adelante).
Se puede usar la propiedad AllowSelection de los grids para que sea posible seleccionar de a una
lnea.

El modelo del carrito de compras. El carrito de compras, es muy utilizado en los sitios Web con ecommerce 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 dueo decide comprar alguno o todos los tems. Esta idea resulta prctica 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 informacin del carrito.
Si se quiere realizar alguna accin a una serie de lneas en un Trabajar con, se pueden ingresar en
el carrito y luego automticamente se van presentando una a una las pginas adecuadas para la
accin determinada, hasta vaciar el carrito.

Ejecucin en el servidor. En Web con el uso de la tecnologa Ajax las aplicaciones cada vez se
asemejan ms a Win, ya que se ejecutan acciones tanto en el cliente como en el servidor. Por ms
detalles ver Tipos de dilogo.

Infraestructura de hardware. La performance de una aplicacin Web depende en gran medida de la

cantidad de usuarios concurrentes accediendo a la aplicacin, el ancho de banda de la conexin 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. Tambin es imprescindible un
esquema fuerte de seguridad principalmente de la base de datos.

Una aplicacin Web debe estar disponible los 7 das de la semana, durante las 24 horas del da. Esto
implica un servicio de alta disponibilidad en el cual posiblemente se maneje redundancia de
servidores y de informacin.

Conclusiones

Las aplicaciones Web son una nueva alternativa a las aplicaciones de interfaz grfica. Ambos tipos de
aplicacin tienen sus caractersticas propias por lo que en cada aplicacin se debe evaluar si
conviene realizarla como Web o GUI. Los puntos discutidos en este artculo pueden ser considerados
como una gua para tomar esta decisin. Como requisito para tomar una decisin 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 creacin o migracin a aplicaciones Web son:

Requerimientos y proceso de instalacin de la aplicacin final.

Ambiente en donde se ejecute la aplicacin.

Requerimientos en el acceso.

Interfaz grfica en cuanto a facilidad de uso, diseo grfico atractivo y capacidades

multimedia.

Acceso desde mltiples plataformas como computadoras de bolsillo, etc..

Requerimientos de seguridad en la aplicacin.

Tipo de dilogo en las Transacciones GeneXus, especialmente en la validacin de datos y

disparo de reglas, considerar las acciones que se dispararn en el cliente y cuales en el
servidor.

Restricciones en la interaccin de objetos GeneXus. Debe ser evaluado cuidadosamente en

el caso de migrar una aplicacin GUI a Web.

Como punto final hay que tener en cuenta la evolucin de la aplicacin en cuanto a la creacin de
nuevos mdulos, cantidad de usuarios y mantenimiento.

Conversin de aplicaciones GUI a Web

Objetivo

El objetivo de este documento es describir los principales aspectos tcnicos a tener en cuenta al
momento de convertir una aplicacin GeneXus de tipo GUI-Windows a una aplicacin Web.

Introduccin

APLICACIN GUI
Entendemos como aplicacin GUI (Graphic User Interface) a toda aquella que tiene interfaz grfica
Windows, compuesta bsicamente por los objetos Transacciones, Work Panels, Procedimientos y
Reportes, generadas con los generadores GeneXus Visual Basic, Visual Fox, Java y .Net.

APLICACIN WEB
Una aplicacin Full Web tiene una interfaz HTML (HyperText Markup Language) y se ejecuta dentro
de un browser. Este tipo de aplicaciones se desarrolla bsicamente con los objetos Web de GeneXus:
Web Panels y Web Transactions. Se generan con cualquiera de los generadores Web: Java, .Net.

Reingeniera de la aplicacin

La premisa fundamental para convertir una aplicacin Win a Web es que los ambientes implicados
(grfico, html) son diferentes y por lo tanto la conversin implicar algo ms que la mera conversin
de los objetos. Deber programarse con estilo Web.

En este documento centralizamos consideraciones a tener en cuenta para los diferentes objetos y
modalidades de programacin.

La conversin de los objetos implica:

1.

Conversin de Work Panels

2.

Conversin de Transacciones

3.

Conversin de Reportes

1.

CONVERSIN DE WORK PANELS A WEB PANELS

Una posibilidad para realizar la conversin de los Work Panels a Web Panels es utilizar la facilidad de
SAVE AS que brinda GeneXus. De esta forma, se convierte en forma automtica el form grfico al
form HTML y se mantiene toda la lgica del objeto. Algunos controles Win no son soportados en
Web (por ejemplo el tab control), con lo cual no siempre es automtica la conversin de un form a
otro.

Otra posibilidad es crear un nuevo objeto (Web Panel) y copiar la lgica del Work Panel hacia el Web
Panel. Observe que se debe revisar la lgica ya que existen ciertas diferencias en la interfaz que
obligan a cambios en la programacin.

Se recomienda leer el documento Comparacin entre Web Panels y Work Panels donde se comparan
generalidades de ambos tipos de objetos.

Luego de convertir el objeto, se debe editar el cdigo 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
conversin 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.

CONVERSIN DE TRANSACCIONES A TRANSACCIONES WEB

Se cuenta con un form HTML default por cada Transaccin Web (con los atributos de la Transaccin,
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 grfica por lo tanto se
recomienda la lectura del documento Transacciones Web.

3.

CONVERSIN DE REPORTES

Una posibilidad para manejar reportes es programar un Web Panel, de forma que el usuario final
pueda imprimirlo con las opciones de impresin del browser.

Otra posibilidad como solucin 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 comn 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 lneas 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
accin en el evento clic.
3. Si se utiliza un grid Free Style, puede utilizarse en lugar de una imagen con el evento clic, un
botn 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. Transaccin 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 deberan utilizar
cookies que almacenen los filtros ingresados.
Refresh

En Work Panels Trabajar con, es comn tener un comando Refresh o Refresh keep dentro de un
evento, luego de llamar a una Transaccin. Cuando estos se convierten a Web Panels Trabajar con
el Refresh no es necesario, ya que al ejecutar el comando Return hay un Refresh implcito 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 lneas del grid ya que no existe
posicionamiento en ninguna parte del form. Para implementar la seleccin mltiple, se debe definir
una variable en el grid y asignarle un valor a cada una de las lneas que se quieren procesar. Luego,
se debe usar el comando For each line para procesar cada una de las lneas y filtrar por las que estn
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 seleccin de una lnea 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 programacin 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 lgica 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 redisear el
form.

Una alternativa puede ser definir un objeto por cada Tab Dialog.

Otra alternativa es usar cdigo HTML externo que permite simular estos tabs.

MASTER PAGE
En las aplicaciones Web se recomienda la utilizacin de Master Pages, de forma que permita
centralizar el diseo y el comportamiento de la aplicacin en un solo objeto y reutilizarlo en otros
objetos sin requerir programacin.

Para profundizar en los temas de conversin de aplicaciones GUI-Windows a aplicaciones Web se

recomienda acceder a la direccin:
http://www.gxopen.com/commwiki/servlet/hwiki?ConversionWinWeb

INTRODUCCIN
En este captulo veremos GXportal, herramienta que permite disear, administrar y mantener
portales escalables, sin necesidad de programar. Por lo tanto el usuario de GXportal no necesita
tener conocimientos especficos de programacin o diseo.

GXportal brinda una interfaz Web amigable desde la cual el usuario, en pocos pasos, construye y
publica la informacin en el portal.

La practicidad de GXportal asegura la reduccin de los costos de desarrollo y mantenimiento, as

como tambin de los tiempos en llevar las nuevas ideas al mercado (time-to-market).

GXportal ofrece un marco de trabajo para la integracin de conocimiento, informacin y aplicaciones

a travs de un portal, buscando unir los distintos actores de la organizacin y las comunidades.

GXportal
GXportal permite la integracin de su personal, clientes y socios de negocios a travs de la Web,
compartiendo informacin 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 travs de Internet en forma rpida, segura y eficiente. Construido
utilizando la tecnologa GeneXus, GXportal incorpora vistas de diseo y gestin de contenido
independientes, y funciones de gestin automtica del contenido y del diseo que lo hacen nico
dentro de las herramientas de colaboracin.

GXportal le permite a su organizacin integrar fcilmente conocimiento, contenido, y aplicaciones,

brindando una solucin integral para la gestin de su Front End y Back End en la Web.

Principales Caractersticas

SIMPLE
La administracin de la informacin del portal puede ser realizada por personal no especializado,
accediendo al Back End del portal desde cualquier PC conectado a Internet. El proceso de
administracin de contenido gua al usuario en el ingreso y mantenimiento de la informacin.
Permite definir dnde y cundo se publicar el contenido y cules son los roles para cada tarea, lo
que asegura el manejo confiable de la informacin.

DISEO Y CONTENIDO INDEPENDIENTES

El contenido y el diseo del sitio se gestionan en forma independiente. El proceso de diseo se basa
en plantillas de publicacin que se administran en forma independiente del proceso de ingreso y
publicacin del contenido. Las plantillas son estilos de pginas pre-definidas o definidas por el
usuario que se aplican a las pginas del portal. Cuando se modifica una plantilla, en forma
automtica se modifican las pginas que estn basadas en ella. El uso de las plantillas reduce el
mantenimiento y tiempo de desarrollo de las pginas del sitio.

GESTIN AUTOMTICA DEL CAMBIO

El uso de plantillas y componentes Web hace que la tarea de diseo se concentre en pocas pginas,
ya que al modificar una plantilla los cambios se propagan automticamente a todas las pginas
creadas en base a ella.

SINGLE SIGN ON
El mdulo Single Sign On permite la unificacin 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 mltiples servidores en diversas ubicaciones.

ADMINISTRACIN DE COMUNIDADES
GXportal cuenta con las siguientes herramientas para lograr un mbito de interaccin 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
presentarn las funcionalidades del Back End a las cuales puede acceder para realizar tareas de
administracin.

Figura 2: Seguridad Gxportal. El acceso a la informacin depender de los roles que se le asignen, es
posible restringir el acceso de los usuarios Web a contenidos, menes, pginas o canales. De esta
forma se logra controlar y segmentar el pblico del portal.

Principales Beneficios

DISEO WEB
El primer paso en la creacin de un sitio Web efectivo es la creacin de pginas visualmente
atractivas. El diseo de las pginas Web en GXportal se realiza en forma independiente del
contenido y de la funcionalidad del sitio. Los diseadores Web no necesitan tener conocimientos de
programacin ni limitaciones funcionales a la hora de disear el look & feel de su sitio.

El diseo se realiza en base a plantillas que pueden ser actualizadas en cualquier momento. Las
plantillas son estilos de pginas pre-definidas o definidas por el usuario que se aplican a las pginas
del portal. Cuando se modifica una plantilla, el diseo de las pginas que se basan en ella se actualiza
en forma automtica.

El diseo independiente del contenido y el uso de plantillas posibilita la creacin sitios cuyo look &
feel puede evolucionar junto con las necesidades de sus visitantes, al tiempo que reduce
drsticamente los costos y tiempos de desarrollo y mantenimiento del sitio.

GESTIN DE CONTENIDOS
El segundo paso en la creacin de un sitio efectivo es asegurar que la informacin que contiene sea
correcta, est actualizada, y sea pertinente para sus visitantes. Las funcionalidades de gestin de
contenido de GXportal permiten delegar las tareas de generacin de contenido a sus creadores.

Para ello, incorpora workflows para gestionar el proceso de creacin, edicin, y traduccin de
contenidos, y mecanismos de publicacin por fecha, de segmentacin de contenidos, y de
personalizacin del sitio por parte de sus visitantes.

La gestin de contenidos de GXportal permite obtener un portal totalmente actualizado, sin

intervencin de tcnicos ni procesos de subida de informacin en los servidores.
GESTIN DE COMUNIDADES
El tercer componente fundamental en la creacin de un sitio efectivo es la interaccin con sus
visitantes. GXportal cuenta con herramientas para lograr un mbito de interaccin ptimo entre los
miembros de su comunidad como newsletters, foros de discusin, encuestas, preguntas frecuentes,
etc..
Las herramientas de gestin de comunidades de GXportal le permiten interactuar con sus visitantes
en forma ptima.

INTEGRACIN DE APLICACIONES
El grado mximo de desarrollo de los sitios es el acceso cualquier aplicacin en forma remota y
segura a la vez.
Los conectores habilitan la integracin a sus pginas de componentes externos tales como cdigo
HTML, Flash, Javascript, XML, aplicaciones o pginas Web externas y Web services.

Descripcin del Producto

Figura 3: Descripcin de GXportal

CONTENIDO
El mdulo de contenido permite administrar y gestionar de forma gil, segura y ordenada los
contenidos que sern publicados en el portal. Gua al usuario en el proceso de ciclo de vida de la
informacin mediante un workflow asegurando la consistencia de los datos en el momento de su
publicacin.

Toda la gestin del contenido se realiza a travs de una interfaz Web permitiendo al usuario tener
una visin organizada y centralizada de la informacin independientemente de donde ser
publicada.

DISEO
GXportal ofrece a travs del mdulo de diseo una interfaz amigable e intuitiva mediante la cual el
usuario, sin necesidad de programar, puede disear las pginas del portal. Esta tarea se realiza
personalizando cada pgina, pudiendo reutilizar los diseos de otras.

El usuario puede definir sus propias plantillas y asociarle un conjunto de pginas. De esta manera se
obtiene una reduccin en los costos de mantenimiento y permite que los cambios se hagan de
manera rpida, pues los cambios en la plantilla impactan en forma automtica en todas las pginas
asociadas.

COMUNIDAD
Las comunidades surgen a partir de los intereses en comn que tienen las personas que navegan un
sitio. Por lo tanto, el sitio deber proveer de las herramientas que hacen posible la creacin y
funcionamiento de las comunidades, como ser: foros de discusin, lista de noticias, preguntas
frecuentes, encuestas, etctera.
GXportal cuenta con las herramientas necesarias para lograr un mbito de interaccin entre los
distintos integrantes de las comunidades.

SEGURIDAD
Contar con herramientas de segmentacin permite controlar a que tipo de informacin 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
definicin de roles que desee de manera de poder segmentar el pblico objetivo de la mejor manera
posible y adems de contar con el soporte de protocolo seguro que le d la tranquilidad al usuario
de que la informacin se enva de manera totalmente privada y segura.

Tecnologas Soportadas

Plataformas de ejecucin: Java, Microsoft .NET

Sistemas Operativos: LINUX, UNIX, Windows 2000/2003 Servers, Windows 2000/XP
Sistemas de Administracin 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. DISEO
En esta etapa se realiza un anlisis con el fin de determinar objetivos del portal, pblico o
comunidades a las cuales se dirigir el portal, que informacin se quiere publicar y de que forma se
segmentar dicha informacin. De este anlisis se debe obtener lo siguiente:

Visin del portal (modelo de negocio)

Mapa de navegacin del portal
Diseo grfico del portal
Gestin de contenido (workflow)
Arquitectura (hardware y software)

2. CONSTRUCCIN
Durante esta etapa se trabaja directamente desde el Back End de GXportal definiendo las plantillas
de diseo que surgieron del diseo grfico de la etapa anterior. Luego en base a estas plantillas se
crean las pginas del portal basndolas en las plantillas definidas. Adems 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 PRODUCCIN DEL PORTAL

Una vez que se tiene todo el diseo de las pginas del portal y todo el contenido que se quiere
publicar en el portal aprobado se puede realizar la publicacin del portal. Para esto simplemente se
debe utilizar la herramienta de publicacin del portal que permite a travs de la accin de un clic
publicar todo los componentes de diseo del portal. El contenido debe haber sido autorizado y
publicado anteriormente para que el portal muestre toda la informacin.

4. MANTENIMIENTO DEL PORTAL

Cuando una organizacin comienza a operar el Portal, es necesario hacer un seguimiento
postinstalacin para asegurarse que el mismo est siendo bien asimilado.

En esta etapa se debe culminar con la capacitacin de los usuarios involucrados en la administracin
del contenido. Y se debe hacer un seguimiento de la evolucin 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
evolucin y poder dar un mejor servicio a travs de l.

INTRODUCCIN
Existen otras caractersticas interesantes para el desarrollo de aplicaciones Web, que presentamos
en este captulo.

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 menes de opciones en las aplicaciones Web, bsicamente surgen dos formas
de implementarlos desde GeneXus. Una de las soluciones posibles es implementarlo con JavaScripts
y otra solucin es con grids FreeStyle. Siendo la primera la ms utilizada hasta el momento.

En la siguiente URL www.gxopen.com.uy se pueden bajar proyectos con menes 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
menes e incluso Patterns aunque no genera menes, si genera una serie de links que permiten
navegar por toda la aplicacin (tanto en el header y como los recents links).

Tipo de Datos HttpClient, HttpResponse y HttpRequest

Introduccin

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.

Descripcin

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 slo en
Procedimientos Web.

HTTPCLIENT
Este objeto refleja una conexin http. Puede usarse desde cualquier objeto GeneXus.

Propiedades
A continuacin 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 conexin.
Tipo- Integer
BaseURL
Indica la URL base de los request que se hagan al host.
Tipo- String
StatusCode
Retorna el cdigo de error HTTP.
Tipo- Integer
ReasonLine
Retorna el texto del error HTTP.
Tipo- String
ErrCode
Retorna si ocurri algn error en algn comando, en cuyo caso retorna un valor distinto de cero.
Tipo- Integer
ErrDescription
Retorna el mensaje del error si ocurri alguno en algn comando.
Tipo- String
Basic y Digest
Son constantes que determinan un tipo de autenticacin. Se utilizan en el mtodo AddAuthentication.
Basic=0 : Para autentificar se enva el usuario y password sin encriptar.
Digest=1: Para autentificar se enva el usuario y password encriptados.
ProxyHost y ProxyPort
Permiten especificar un proxy http. En ambiente windows se utiliza automticamente el que esta configurado
en la mquina.
ProxyHost- String
ProxyPort- Integer

Mtodos
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><Value>-

String
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 mtodo en la URL definida. Se pondra 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 autenticacin <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 mtodo 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 porcin de URL correspondiente el nombre del directorio virtual.
Tipo- String
ScriptName
Retorna el nombre del objeto con la extensin correspondiente que se esta ejecutando, tal como aparece en
la URL.
Tipo- String
Referrer
Retorna la URL del llamador.
Tipo-String
QueryString
Retorna la porcin de la URL que est despus del signo ?; o sea los parmetros.
Tipo- String
RemoteAddress
Devuelve la direccin del cliente.
Tipo- String
ErrCode
Retorna si ocurri algn error en algn comando, en cuyo caso retorna un valor distinto de cero.
Tipo- Integer
ErrDescrption
Retorna el menaje del error si ocurri alguno en algn comando.
Tipo- String

Mtodos

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 slo en el contexto de un
Procedimiento Web.

Propiedades
ErrCode
Retorna si ocurri algn error en algn comando, en cuyo caso retorna un valor distinto de cero.
Tipo- Integer
ErrDescrption
Retorna el menaje del error si ocurri alguno en algn comando.
Tipo- String

Mtodos
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

INTERACCIN CON XML

Estos objetos permiten la interaccin con los objetos XMLReader y XMLWriter. Para ello existen los
siguientes mtodos:

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 va http, pasndole parmetros en un
XML y recibiendo los mismos tambin 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 sera:

&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 sera el siguiente Procedimiento Web:

&Request de tipo HttpRequest

&Response de tipo HttpResponse

&Writer de tipo XMLWriter

&Reader de tipo XMLReader

// Leo los parmetros 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 parmetros 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 aplicacin obtendr

automticamente la configuracin 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 lnea de comandos del intrprete, por Ej.:

java -Dhttp.proxyHost=your.proxy.com -Dhttp.proxyPort=XX <mainclass>

Internet Mvil (WAP)

Introduccin

En los ltimos aos tanto Internet como la telefona celular han tenido un gran crecimiento y se han
hecho accesibles a millones de personas. Es posible ahora unir estas dos tecnologas accediendo de
forma fcil y rpida a la informacin que brinda Internet desde los telfonos celulares ( mviles).

GeneXus permite generar salidas para Internet mvil, 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 ms comn de Internet Mvil.
Internet mvil es el trmino comercial para acceder a informacin de Internet a travs de
dispositivos mviles. Los dispositivos mviles ms comunes son los telfonos celulares con
microbrowser pero tambin entran en esta categora, los dispositivos de tipo palm y cualquier
dispositivo de informacin porttil, que pueda disponer de una conexin inalmbrica.

Este protocolo consiste en un modelo de capas que incluyen un IP inalmbrico, capas de seguridad
(WSL) y lenguajes de descripcin 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 ms estricto
en la sintaxis.

WML VS HTML
Por el tamao de la pantalla, es imposible traducir o ver de forma satisfactoria una pgina de Web
normal (HTML) en un celular. El tamao, los tipos de letra, las imgenes y la cantidad de informacin
que se soporta en el Web no se puede soportar en un microbrowser y no es prctico hacerlo.
La navegacin, adems, es diferente, el usuario no tiene mouse, ni teclado por lo que el ingreso de
datos debe ser limitado y la navegacin, mucho ms simple.

MICROBROWSER
Es un software instalado en el telfono o dispositivo inalmbrico que interpreta el WML (y el
WMLScript, WTAI, etc.) y despliega la informacin en la pantalla. Es posible acceder a emuladores de
celulares y sus microbrowser. Algunos de los ms conocidos son UP Browser (Unwired Planet) de
Phone.com, RS380 Ericsson, Nokia, etc..

Arquitectura

La arquitectura es similar a Internet. El cliente es el telfono celular con MicroBrowser y en el

servidor se encuentra la lgica en objetos (ejecutables o ASP) con contenido WML o sea que al ser
interpretados por los browsers generan WML.

Descripcin

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 podrn ser vistos desde un browser WAP.
Requerimientos

Para testear esta caracterstica directamente en la mquina 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 registracin en dicha pgina.
El archivo ocupa aproximadamente 7 MB.
Diseo

Se deben definir los Web Panels como hasta el momento y configurar la propiedad Tag Language
en WML.

En el diseo del objeto se deben tener en cuenta las siguientes limitaciones del lenguaje generado
(WML):

Los objetos WML estn limitados en el tipo y cantidad de controles que se soportan as
como en el tamao de las pginas debido a la cantidad de memoria de los mviles y el
tamao de la pantalla.

Las pantallas permiten entre 4 a 8 lneas de texto, dependiendo del mvil, por lo que no se
recomienda que las pantallas superen estos tamaos. No es conveniente que se tenga scroll
en una pantalla de telfono celular.

Slo se soportan los siguientes controles:

Edit

Textblocks

Texto libre

Tablas simples

Grids Free Style simples

No se soportan:
o

Variables dentro de tablas

Ninguna anidacin de tablas y/o grids Free Style

Grids estndar

Campos LongVarchar

La letra

Tag <BR>

Botones

Cookies

Encriptacin de parmetros

Las propiedades de runtime soportados son:

o

Link

Ispassword

Visible

Enabled

El softbutton del telfono (botn que se encuentra en la parte superior izquierda), se asocia
al Evento Enter.

Ejecucin

Luego de generado el objeto se debe ejecutar desde el emulador celular, esto se realiza escribiendo
la direccin donde se encuentra el Web Panel en la barra de direcciones del mismo.

Ejemplo

Se desea desplegar un texto de prueba en un telfono 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 cdigo 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 direccin donde se encuentra el objeto (por ej. http://localhost/cgibin/hPrueba.exe) en Go, y presionar Enter o el Softbutton.

5.

En el telfono celular se visualizar el texto ingresado en el Web Panel.

6.

Si se producen errores en la pantalla del telfono 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 detrs del emulador).
Hay un ejemplo disponible en :
http://www.gxtechnical.com/main/Hdcenter.aspx?2,5,36,408

Errores comunes

Error

Sntoma

Error : Invalid element PCDATA in contents

of card.

Se debe a la ausencia de <P> en textblock o

variable.

Error : Invalid element br in contents of

card.

Se debe a un tag <BR> en el Source del objeto

Error : Uncompiled data from http <head>.

La pgina 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 lneas.

Error : Missing entity ntilde

Hay algn dato con la letra y el microbrowser

no lo puede interpretar.

Error : Invalid element P in content of p.

excpectde PCDATA | em | b

Se introdujo algun tag <P> anidado, esto no es

vlido 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
cdigo no vlido, es preciso en estos casos modificar el source en el editor de diseo de
GeneXus.

No es posible hacer cut & paste de controles y/o del Source.

Existen algunos Tags HTML (no vlidos en WML) generados por el editor. Por ejemplo el Tag
<BR> es generado por la combinacin de teclas Shift+Enter en el editor.

Textblock y variables deben generarse entre <P> y </P>. La generacin de estos Tags se da
con un enter al final del edit o modificando Cdigo en el Tab Source.

Grids o tablas no deben limitarse por tags <P>. Es posible generar este cdigo con algunas
combinaciones de teclas.

Igualmente no es recomendable modificar el cdigo WML (bajo el tab HTML Source )

pues pueden dar errores en ejecucin.

No se reciben correctamente variables por parmetro en los llamados realizados mediante

call.

INTRODUCCIN
Cada vez se escucha ms el concepto de Web Services, fundamentalmente relacionado con
Internet y el futuro de una arquitectura orientada a servicios. Es por esta razn, que GeneXus incluye
la posibilidad de desarrollar y consumir Web Services.

Comenzaremos con una introduccin al concepto de Web Services para luego realizar ejercicios
prcticos que permitan profundizar los conocimientos adquiridos.

Web Services
En los ltimos tiempos ha surgido con mucha fuerza el concepto de Web Services, incluso
afirmndose que el mismo cambiara 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 cmo es la arquitectura general del modelo,
adicionalmente se provee una introduccin de los estndares en los cuales se basa este modelo
como ser SOAP, WSDL y UDDI.

Qu es un Web Service?

Un Web Service es una aplicacin que puede ser descripta, publicada, localizada e invocada a travs
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 cmo fueron implementados. A
diferencia de la actual tecnologa de componentes, no son accedidos por medio de protocolos
especficos 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 trminos 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 programacin, slo tiene que poder crear y consumir los
mensajes definidos por la interface de los Web Services.

El modelo de Web Services

La arquitectura bsica del modelo de Web Services describe a un consumidor, un proveedor y

ocasionalmente un corredor (broker). Relacionados con estos agentes estn las operaciones de
publicar, encontrar y enlazar.

La idea bsica 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 estndar de representar los datos

XML es la opcin obvia para este requerimiento.

Un formato comn y extensible de mensajes

SOAP es el elegido en este caso; SOAP es un protocolo liviano para el intercambio de informacin.
Ms adelante en este documento lo veremos con ms detalle.

Un lenguaje comn y extensible para describir los servicios

La opcin en este caso es WSDL. Es un lenguaje basado en XML desarrollado en forma conjunta por
IBM y Microsoft. Lo veremos con ms detalle ms 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 ms
detalle ms adelante en este documento.

Ventajas y retos

Los Web Services apuntan a ser la piedra fundamental de la nueva generacin de sistemas
distribuidos. Estos son algunos puntos para fundamentar esta afirmacin:

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 tecnologas puede implementar o acceder Web Services. Muy pronto estarn
presentes en telfonos, autos e incluso mquinas expendedoras, las que avisarn 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 cmo est implementado, por lo cul la complejidad se reduce.

Fcil de utilizar

El concepto detrs de los Web Services es fcil de entender, incluso existen toolkits de vendedores
como IBM o Microsoft que permiten a los desarrolladores crear Web Services en forma rpida y fcil.

Soporte de la Industria

Todas las empresas de software importantes soportan SOAP, e incluso estn 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 podran ser consumidos por un
Web Service desarrollado utilizando VisualAge de IBM y viceversa.
A la vez hay ciertos retos tcnicos que los Web Services tienen que sortear para poder tener xito. Muchos
de estos retos estn relacionados con el ambiente abierto en el que tienen que sobrevivir. Estos son algunos
de esos puntos:

Descubrimiento
Cmo 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 estndares que manejan este punto.
Confiabilidad
Algunos Web Services son ms confiables que otros. Cmo 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 restriccin, pero muchos otros van a
necesitar autenticacin para que los utilicen slo los usuarios autorizados. Cmo autentifica a los
usuarios un Web Service? Lo hace a nivel del mtodo que lo implementa o utiliza otro Web Service para
realizar la autenticacin?
Responsabilidad
En caso de que el Web Service no sea de acceso libre, Cmo puedo definir cuntas veces un
consumidor puede acceder al Web Service una vez contratado? Cmo se cobra su uso? Cmo se indica
que un servicio ya no est ms en lnea?

Tecnologas asociadas

El modelo de Web Services est basado en ciertas tecnologas emergentes que es el resultado del
trabajo de varias compaas y organizaciones entre las cuales se destacan IBM y Microsoft. Estas
tecnologas son SOAP, WSDL y UUDI.

SOAP (SIMPLE OBJECT ACCESS PROTOCOL)

SOAP es un protocolo para el intercambio de informacin en un ambiente descentralizado y
distribuido. Es el protocolo ms utilizado para realizar el intercambio de informacin en el modelo
de Web Services.

Est basado en XML y potencialmente puede ser utilizado en combinacin con una variedad de
protocolos de comunicacin, siendo el ms utilizado HTTP. Por lo tanto se utiliza HTTP para
transportar la informacin, y XML para representar la misma.
El protocolo completo se puede encontrar en http://www.w3.org/TR/soap

El modelo de comunicacin de SOAP

El modelo de comunicacin 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 informacin solicitada o enviando un mensaje de error en caso de que el requerimiento
no haya sido vlido.

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
informacin acerca del requerimiento, mientras que el cuerpo SOAP contiene el mtodo llamado y
los parmetros con los que se llama al mismo.

Todo esto es un modelo de mensajes request/response con una forma de describir un conjunto de
mtodos y pasarle a los mismos parmetros. Esto parece la base del protocolo RPC y de hecho es el
uso ms comn 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 programacin.

A continuacin se muestra un mensaje SOAP embebido en un request HTTP:

Este ejemplo invoca al servicio StockQuote llamando al mtodo GetLastTradePrice con el smbolo
DIS por parmetro.
Esta es la respuesta al requerimiento anterior, el cual retorna el precio de la accin solicitada:

Si usted qued asustado por la aparente complejidad del protocolo SOAP pensando lo engorroso
que sera armar los mensajes de requerimiento y parsear los mensajes de respuesta despreocpese;
la mayora de los lenguajes de programacin proveen o proveern soporte para realizar esto. La idea
fundamental consiste en utilizar algn objeto al cual se le brinda un WSDL y se le indica qu mtodo
se quiere llamar y con qu parmetros. Esto arma en tiempo de ejecucin el mensaje SOAP, lo
manda y parsea el resultado adjudicndoselo a alguna variable en forma trasparente para el usuario
como si hubiera hecho un call comn.

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 estandarizacin.

Un archivo con formato WSDL provee informacin de los distintos mtodos (operaciones) que el
Web Service brinda, muestra cmo accederlos y qu formatos deben de tener los mensajes que se
envan 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 slo si el cliente enva 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 mayora de los casos es conveniente que est acompaado por un
documento escrito en lenguaje natural que brinde informacin de qu es lo que hace cada uno de
los mtodos brindados por el Web Service as como tambin ejemplos, tales como los mensajes
SOAP que espera y responde el servicio.

En forma resumida podramos 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 dnde mandar los mensajes.

Formato de un archivo WSDL

A continuacin se muestra cmo es el formato bsico de un archivo WSDL. La especificacin

completa de este lenguaje se puede encontrar en http://www.w3.org/TR/wsdl.html.

Un archivo con formato WSDL bsicamente contiene los siguientes elementos:

Type: Describe los tipos no estndar usados por los mensajes (Message).

Message: Define los datos que contienen los mensajes pasados de un punto a otro.

PortType: Define una coleccin de operaciones brindadas por el servicio. Cada operacin tiene un
mensaje de entrada y uno de salida que se corresponde con algn Message antes definido.

Binding: Describe los protocolos que se utilizan para llevar a cabo la comunicacin en un
determinado PortType; actualmente los protocolos soportados son SOAP, HTTP GET, HTTP POST y
MIME, siendo SOAP el ms utilizado.

Port: Define una direccin (URL) para un determinado Binding.

Service: Define una coleccin de Ports.

El siguiente es un ejemplo de archivo WSDL:
El mismo define dos mensajes (Simple.foo y Simple.fooResponse), luego define un mtodo llamado
foo el cual recibe el mensaje Simple.foo y retorna el mensaje Simple.fooResponse. A continuacin
se define un binding para el mtodo foo asocindolo con el protocolo SOAP. Por ltimo se da una
URL fsica que implementa lo antes descrito.

Interfaz e implementacin

La estructura bsica de archivo con formato WSDL podra ser dividido en dos partes lgicas: la
interfaz del servicio, y la implementacin del mismo.

Esta divisin lgica divide los elementos de la siguiente forma:

Interfaz del servicio

Type, Message, PortType, Binding.
Contiene una definicin abstracta y reusable del servicio que puede ser instanciada y referenciada
por distintos proveedores del mismo.

Implementacin del servicio

Port, Service.
Contiene una implementacin de una determinada Interfaz del servicio.

A partir de esta divisin lgica se puede definir por medio de una Interfaz del servicio un estndar
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
despreocpese; la mayora de los lenguajes de programacin proveen o proveern herramientas
para generar en forma automtica el archivo WSDL a partir de un determinado mtodo o funcin.

UDDI (UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION)

UDDI (www.uddi.org) es un proyecto inicialmente propuesto por Ariba, Microsoft e IBM; es un
estndar para registrar y descubrir Web Services. La idea es que las distintas empresas registran su
informacin acerca de los Web Services que proveen para que puedan ser descubiertas y utilizadas
por potenciales usuarios.
La informacin es ingresada al registro de empresas UDDI, un servicio lgicamente centralizado, y
fsicamente distribuido a travs de mltiples nodos los cuales replican su informacin en forma
regular. Una vez que una empresa se registra en un determinado nodo del registro de empresas
UDDI la informacin es replicada a los otros nodos y queda disponible para ser descubierta por otras
empresas.

El esquema UDDI

El modelo de informacin base utilizado por los registros UDDI es definido en un esquema XML. Este
esquema define cuatro tipos bsicos de informacin, cada uno de los cuales proveen la clase de
informacin que un usuario necesita saber para utilizar un Web Service de otra empresa.
Los cuatro tipos de informacin son:

Informacin del negocio

Este tipo de informacin est definido en el elemento businessEntity. Contiene informacin de la
empresa, como ser su nombre, los contactos, el tipo de empresa, etc.

Informacin del servicio

Dentro del elemento businnessEntity se encuentran los elementos businessServices, estos
elementos contienen informacin sobre Web Services generalmente agrupados por procesos de
negocio o categoras de servicios.

Informacin del enlace (binding)

Dentro de cada elemento businessServices se encuentran los elementos bindingTemplate.
Cada uno de ellos brinda una direccin fisica para hacer contacto con los servicios
descriptos anteriormente.

Informacin sobre las especificaciones del servicio

Cada bindingTemplate tiene asociado un tModel, el cual brinda informacon sobre las
especificaciones del servicio, por ejemplo, cmo 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 especificacin del servicio. Utilizando entonces los tModels se pueden
encontrar todas las empresas que brindan tal servicio.

Por ms informacin sobre el esquema UDDI:

http://www.uddi.org/pubs/ProgrammersAPI_v2.pdf

API UDDI
El acceso al registro UDDI, ya sea para realizar bsquedas o para ingresar o modificar un registro, se puede
realizar a travs de una pgina Web que implemente el acceso o utilizando ciertas interfaces (Web Services)
que provee la especificacin de UDDI. Estas interfaces estn descriptas en una API, que puede ser dividida en
dos partes lgicas, la API de consultas y la API de publicacin.

Por ms informacin 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 podra pagar por utilizar los servicios brindados por un proveedor, o el proveedor podra
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 continuacin.
El ejemplo es tomado de la vida real y es sobre la compaa area Southwest. En su portal
http://www.southwest.com/ , esta compaa area permite hacer reservas de boletos, pero adems
como valor agregado a los clientes permite hacer reservas de hoteles y reservas de alquileres de
autos. Los datos para poder realizar estas reservas estn 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 compaa de aviones le brinda un valor agregado a sus
clientes, y los hoteles y rentadoras de autos estn expuestos a ser contratos por potenciales clientes.
Es ms, estas empresas no publicaron sus servicios para que fueran exclusivamente utilizados por la
compaa area, 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 tendrn
las empresas que los sepan utilizar en forma adecuada con respecto a las otras. Imagnese en este
caso si usted fuera a reservar boletos de avin y pudiera elegir por una compaa que adems de
reservar los boletos le permitiera hacer la reserva de hotel, y otra que no; por cual hara la reserva?
Por otro lado imagine que usted es dueo de una rentadora de autos y sabe que su competencia
est brindando sus servicios en un portal de una compaa area y usted no, qu hara?

XML
Introduccin

Hoy en da, se pueden encontrar muchsimos sitios Web que brindan servicios on-line como por
ejemplo reservas de asientos para espectculos, aviones, reportes meteorolgicos, etc.; para poder
brindar estos servicios a los usuarios, los diseadores y los programadores Web deben combinar los
datos y la presentacin en un documento HTML. Muchas veces el proveedor de determinada
informacin no es quien la va a procesar (sea esto publicarla en un sitio, ingresarla en una
aplicacin, etc).

La necesidad de generar grandes cantidades de datos dinmicos y complejos por un lado y la

necesidad de procesarlos y publicarlos por otro, han provocado la definicin de un formato de datos
universal: XML.

Descripcin

La idea principal detrs de XML es el desarrollo de un lenguaje estndar 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 aplicacin en el servidor del servicio
meteorolgico 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 automtica, sin necesidad
de ingresarlo dentro de la aplicacin del sitio Web cada da o convertir la informacin 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 adems pueden contener en forma
opcional, uno o ms atributos. Los atributos son usados para adjuntar informacin secundaria a los
elementos.

A continuacin 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 podra
redefinirse, de forma que la informacin correspondiente al rea estuviese representada por
atributos, como se representa a continuacin:

<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 informacin acerca de cmo deben ser presentados
los datos. As, como HTML provee etiquetas especficas para formatear un documento, XML provee
un marco para crear etiquetas.
Resumiendo, XML es un lenguaje estndar definido por el Consorcio World Wide Web para permitir
grabar y leer datos en forma estructurada con formato estndar independiente de aplicaciones y
vendedores.

En GeneXus, se cuenta con funciones para el manejo de XML: XMLWriter, XMLReader.

Protocolo SOAP
Introduccin

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 ms utilizado.

Su especificacin describe el contenido que debe tener un mensaje XML para ser usado en una
invocacin remota.

Cualquier aplicacin que cumpla la especificacin puede invocar y proveer servicios sin importar en
que lenguaje o plataforma est implementado, lo nico necesario es que la aplicacin 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.

Descripcin

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 ningn 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 invocacin http, procesan el mensaje SOAP que enva el Cliente
con sus parmetros, realizan la accin requerida, y generan otro mensaje SOAP de respuesta
(eventualmente con los parmetros modificados).

Cliente
Los objetos que van a invocar al servicio Web, a los que llamaremos Clientes, pueden ser cualquier objeto
GeneXus. La invocacin se hace con el comando call() de GeneXus.
Los programas Clientes realizan las tareas necesarias para ensamblar el mensaje SOAP, hacer la invocacin
http, y desensamblar la respuesta, obteniendo los parmetros modificados en forma automtica. Todo esto
se realiza en forma automtica y transparente para el usuario.

Locations

Para indicar cual va a ser la ubicacin 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
ejecucin 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

ejecucin 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 ejecucin no se cancelar y se podr obtener el
cdigo numrico de error con la funcin GetSOAPErr(), y el mensaje de error mediante la funcin
GetSOAPErrMsg().
CDIGOS DE ERROR EN EL CLIENTE
Los posibles cdigos de error que pueden ser retornados mediante la funcin GetSOAPErr() son los
siguientes:

0: Operacin completada con xito.

Mayor que 0 y menor que 10000: Algn parmetro retornado por el servidor no tiene el
nombre esperado. El cdigo de error indica la posicin del parmetro 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 cdigo de error el resultado corresponder a un cdigo de error del
objeto XMLReader. De todas formas, getSOAPErrMsg() retornar una descripcin del error.

Menor que -10000: Sucedi un error en la comunicacin HTTP. Si se toma el valor absoluto
del cdigo de error y se le resta 10000 el resultado corresponder a un cdigo de error del
objeto HTTPClient. De todas formas, getSOAPErrMsg() retornar una descripcin del error.

-20001: La respuesta recibida es un XML vlido pero no es un mensaje SOAP vlido.

-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 cdigo y el mensaje de
error retornados por el servidor. Si el servidor es un procedimiento o reporte GeneXus,
retornar alguno de los cdigos de error descriptos ms abajo.

-20006: Sucedi un error no identificado. En este caso getSOAPErrMsg() retornar un

mensaje conteniendo el cdigo y el mensaje de error retornados por el servidor.

-20007: Nombre de location no vlido. Sucede cuando se llama a la funcin

GetLocation(Nombre) con un nombre de location que no est definido para ningn objeto
en la base de conocimiento.

CDIGOS DE ERROR EN EL SERVIDOR

Un procedimiento o reporte GeneXus que es llamado mediante SOAP puede retornar alguno de los
siguientes cdigos de error:

-20000: No se recibi un mensaje SOAP.

-20001: El mensaje recibido es un XML vlido pero no es un mensaje SOAP vlido (igual que
en el cliente).

-20002: El mtodo llamado no es el esperado. (El mtodo SOAP de los objetos GeneXus
siempre se llama Execute).

CONSUMIDORES A WEB SERVICES EXTERNOS

El WSDL Inspector permite importar la definicin del servicio que se desea consumir. Por ms
detalles ver WSDL Inspector.

Web Services con GeneXus

A continuacin 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 parmetro wsdl a la URL del mismo. Por
ejemplo:

http://server/baseurl/aservice.aspx?wsdl

Consumir

Se utiliza el WSDL Inspector, que permite importar la definicin 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 sern agregados a
la base de conocimiento al importar la definicin con el WSDL Inspector.

Adems, 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 ubicacin del mismo (host, port, etc.).

Prctico: Creacin de Web Service Genexus

En esta seccin crearemos un Web Service GeneXus, y veremos como consumirlo desde una
aplicacin GeneXus.

Supongamos que quisiramos publicar un servicio de nuestro sitio Web, por ejemplo un ranking con
los 10 destinos ms elegidos.

Vamos a definir entonces un Web Service al que llamaremos Ranking.

Lo primero es definir un SDT con las siguientes caractersticas, que nos permita almacenar la
informacin 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 pas en particular, qu cantidad de veces que ha sido
elegida en vuelos que la tienen como ciudad destino. De esa forma, obtendremos las 10 ms
elegidas.

Definiremos una variable que nos permita contar la cantidad de ciudades: &Qty, ms una variable
que permita almacenar toda la coleccin de destinos ms elegidos (Destination) junto con una
variable que cargue cada uno de los items de esa coleccin 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

automticamente por GeneXus, digitando la siguiente URL en el browser:
http://localhost/practico/aranking.aspx?wsdl

Creacin del Consumidor del Web Service

A continuacin 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 continuacin.

1.

Creacin de una nueva base de conocimiento, de nombre Consumer.

2.

Desde diseo, 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 botn
Inspect

Observe que el mtodo del Web Service es Execute y el tipo de datos que
devuelve es Destinationsdt.

Cuando se hace clic en el botn Add Reference se definen los tipos de datos
adems de toda la informacin necesaria para poder consumir el Web Service.

Pasar a prototipo forzando el impacto.

3.

Creacin 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
(coleccin
de
destinos),
Destinationsdt_DestinationsdtItem
(cada
item
de
la
coleccin)
y
org_tempuriaction_.Ranking (Web Service) se crearon automticamente 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 continuacin:

Event Refresh
&Destination = &Rank.Execute() //aqu se invoca la ejecucin del Web Service y se
carga la coleccin en la variable &Destination
EndEvent // Refresh

Event Grid1.Load
for &DestinationItem in &Destination //se recorre la coleccin 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 informacin requerida.

Demo: Cmo consumir un Web Service externo

Una de las caractersticas 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 pginas Web.

Lo que queremos ver en esta seccin es como incluir un Web Service externo no GeneXus en nuestra
aplicacin (ya hemos visto en este captulo un ejemplo de como crear y consumir un Web Service
hecho con GeneXus).

Lo que haremos es importar un Web Service que prove Google. Google es una compaa
especializada en la bsqueda de informacin en la Web. En su pgina 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 definicin 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 diseo).

2.

En Web Service URL ingresar: http://api.google.com/GoogleSearch.wsdl

3.

Presionar el botn Inspect.

Notar que el WSDL Inspector determin que el Web Service tiene los siguientes
mtodos: 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 botn 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 diseo.

Haga clic aqu para ver la demostracin

A continuacin 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 estn 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 invocacin al mtodo doGoogleSearch del Web Service. Los resultados
son devueltos en una Collection de un tipo de datos estructurado, el que es definido
automticamente 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 demostracin

Especificar, generar, compilar y ejecutar el Web Panel GoogleSearch.

Haga clic aqu para ver la ejecucin

Nota: La especificacin del Web Service del ejemplo, se puede leer de:
http://www.google.com/apis/reference.html

Debug de una llamada SOAP

Introduccin

Cuando se produce un error al realizar una llamada SOAP desde GeneXus, es bastante difcil 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 situacin
de este tipo, as como tambin se detalla el uso de un utilitario de libre distribucin que puede
resultar de utilidad.

Se recomienda la lectura previa de los documentos Protocolo SOAP y Locations.

Aunque este documento est orientado especficamente a las llamadas SOAP, tambin aplica en
forma general a la deteccin de problemas utilizando los tipos de datos HTTP.

Descripcin

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 cado 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 Edicin de las noticias de ARTECH, sera:

http://www.gxtechnical.com/cgi-bin/adevedicion.exe?wsdl

Deber visualizarse un archivo XML vlido 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/cgibin/adevedicion.exe?wsdl" xmlns:wsdlns="http://www.gxtechnical.com/cgibin/adevedicion.exe?wsdl" xmlns:typens="http://www.gxtechnical.com/cgibin/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/cgibin/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.

Podra suceder que el archivo LOCATION.XML no estuviera en el directorio correcto en tiempo de

generacin o ejecucin (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
configuracin se hiciera mediante cdigo en tiempo de ejecucin).

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 funcin GetLocation(). Se pueden entonces evaluar las propiedades, asignndolas 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 extensin agregada al nombre del objeto, esto depender del
generador asociado al main correspondiente.

Para tener la seguridad de que la invocacin se est realizando con la extensin correcta, remitirse al
punto 4.

3) Obtener la descripcin del error

La descripcin del error tambin nos da una pista del problema la mayora de las veces. Es posible
obtener el cdigo y descripcin del error utilizando las funciones GetSOAPErr() y GetSOAPErrMsg(),
invocndolas luego del call(). Combinndolo con el ejemplo del punto anterior, quedara:

.
.
&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 solucin 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 distribucin que puede obtenerse en
http://www.pocketsoap.com/tcptrace/. El mismo no necesita instalacin, es solamente un
ejecutable.

Al ejecutar el archivo tcpTrace.exe se presenta el siguiente dilogo:

Se deber completar lo siguiente:

Local Port #

- un nmero 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 continuacin se deber ejecutar la llamada SOAP, modificando previamente los parmetros 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 configuracin utilizado).

Al efectuar la llamada, en la ventana del tcpTrace se visualizar:

En la ventana de la izquierda aparecer una lnea por cada llamada. Al hacer clic sobre una lnea, en
las ventanas de la derecha se mostrarn el Request y el Response HTTP para la llamada
correspondiente.

Mirando el header del Request se puede verificar que la URL base y la extensin que se estn
generando sean correctas. El body (lo que esta despus de la lnea que comienza con Contentlenght) 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 algn error HTTP, el
mismo se puede visualizar en el header del mismo, y en el body se muestra alguna descripcin. En el
caso de que el servicio finaliz en forma exitosa, se devuelve un cdigo 200, y en el body aparece el
Response SOAP (a partir de la lnea en blanco posterior al header). El mismo tambin deber ser un
XML bien formado (para verificar esto se puede copiar y pegar el contenido, salvarlo como un
archivo con extensin XML, y abrirlo con un browser).

WSDL Inspector
Introduccin

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 definicin del mismo.

Descripcin

El WSDL de un Web Service es un archivo que describe al mismo; brinda toda la informacin
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 mtodos del
Web Service en forma transparente.

Para acceder al WSDL Inspector hay que ejecutar la opcin 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 botn Inspect, con lo cual en caso de
no existir ningn error se mostrar la informacin de los distintos mtodos que brinda el Web
Service, junto con los tipos de datos necesarios para poder consumirlos.

Para poder importar la informacin necesaria dentro de la base de conocimiento que permita
consumir el Web Service se debe presionar el botn Add Reference.

En la imagen anterior se muestra la informacin de un Web Service simple, el cual cuenta con un
solo mtodo llamado BabelFish que recibe dos parmetros de entrada de tipo Character y retorna
otro parmetro de tipo Character.

El siguiente ejemplo muestra otro caso en el cual el Web Service cuenta con ms de un mtodo y se
necesita definir nuevos tipos de datos (ArrayOfNewsCategoty, NewsCategoty,
ArrayOfBusnessShortNews, BusnessShortNews):

Add Reference

Como se mencion anteriormente al presionar el botn 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 mtodos de la misma poder invocar a los distintos mtodos que el Web
Service provee. Si para consumir el mtodo se necesitan tipos de datos estructurados hay que crear
variables con los tipos de datos estructurados creados por el Inspector.

Invocacin de los mtodos de un Web Service

MTODO 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 botn 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 mtodos 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 definicin del mismo; solamente se
tuvo que dar la ubicacin de su WSDL y GeneXus se encarg de esconder la complejidad y definir un
tipo de datos que represente al Web Service.

MTODO 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 definicin:
ZodiacSign

Character(9999)

DailyForecast Character(9999)

Un tipo de dato estructurado llamado ArrayOfZodiacSigns con la siguiente

definicin:
ArrayOfZodicSigns collection of ZodiacSigns

Para consumir el Web Service se tiene el siguiente cdigo:

&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 numrico 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
parmetros de la invocacin 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 Horscopo 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 slo se toma en cuenta en tiempo
de ejecucin.

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 grficas), Babelfish (traductor de textos) y GetJoke (provee chistes
agrupados por categoras).
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 opcin 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). Adems, 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 especificacin:

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
Introduccin

Se busca permitir configurar las invocaciones a objetos main GeneXus en forma remota, cuando se
utilizan diferentes protocolos, por ej. llamadas va 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.
Descripcin

Cada programa main de GeneXus tiene asignado un location. ste es un nombre lgico al que se le
hace corresponder una ubicacin vlida para el caso de que el objeto sea invocado, segn el
protocolo que se utilice.

Necesitamos entonces describir las caractersticas de este location, para lo que se utiliza el siguiente
esquema:

En primer lugar, se asigna al objeto a ser invocado un nombre lgico, configurando el mismo en la
propiedad Location de dicho objeto.

Ser necesario entonces poder configurar los locations, segn los diferentes protocolos que se
utilicen para la invocacin del objeto. Existen tres instancias posibles para realizar esto:

1)

En tiempo de generacin.
Mediante el archivo location.xml, ubicado en el directorio raz de la base de
conocimiento y cuya estructura es descripta ms abajo. Este archivo debe ser creado
por el usuario GeneXus.

2)

En tiempo de ejecucin, mediante un archivo.

Mediante el archivo location.xml, ubicado en el directorio corriente durante la
ejecucin 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 ejecucin, mediante cdigo.

Mediante variables de tipo Location, cuya estructura es descripta ms abajo.

Es decir que las propiedades especificadas en tiempo de ejecucin mediante cdigo tendrn
preferencia sobre las especificadas en tiempo de ejecucin mediante un archivo y stas a su vez
tendrn preferencia sobre las especificadas en tiempo de generacin para permitir mayor
dinamismo en la configuracin de los locations.

Propiedades

Se describen a continuacin las propiedades disponibles para describir el location en el archivo XML:

Propiedad

Subelemento
XML

Elemento XML

Tipo

Protocolo

Host

Host

Character

HTTP

Port

Port

Numeric

HTTP

BaseURL

BaseURL

Character

HTTP

Secure

Secure

Numeric
(0|1)

HTTP

Timeout

Timeout

Numeric

HTTP

Authentication

Authentication

Numeric
(0|1)

HTTP

AuthenticationMethod

Authentication

Method

Numeric

HTTP

AuthenticationRealm

Authentication

Realm

Character

HTTP

AuthenticationUser

Authentication

User

Character

HTTP

AuthenticationPassword

Authentication

Password

Character

HTTP

HOST
Especifica la direccin del servidor correspondiente al location.

El valor por defecto es localhost.

Ejemplo por cdigo

&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 cdigo

&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 cdigo

&Location.BaseURL = /mydirectory/soap/

Ejemplo en XML
<BaseURL>/mydirectory/soap/</BaseURL>

SECURE
Especifica si los llamados al location se harn 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 cdigo

&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 cdigo

&Location.Timeout = 1

Ejemplo en XML
<Timeout>1</Timeout>

AUTHENTICATION
Especifica si se utilizar autentificacin con el servidor o no.

El valor por defecto es 0.

En XML se especifican las propiedades de la autentificacin dentro del elemento <Authentication> y

por lo tanto no se especifica valor para este elemento. La simple mencin del elemento
<Authentication> indica que esta propiedad tendr valor 1.

Ejemplo por cdigo

&Location.Authentication = 1

Ejemplo en XML
<Authentication/>

AUTHENTICATIONMETHOD
Especifica el mtodo de autentificacin 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 cdigo

&Location.AuthenticationMethod = 1

Ejemplo en XML
<Authentication>
<Method>1</Method>
</Authentication>

AUTHENTICATIONREALM
Especifica el realm para la autentificacin con el servidor, en caso de utilizarla.

El valor por defecto es .

Ejemplo por cdigo

&Location.AuthenticationRealm = MyRealm

Ejemplo en XML
<Authentication>
<Realm>MyRealm</Realm>
</Authentication>

AUTHENTICATIONUSER
Especifica el nombre de usuario para la autentificacin con el servidor, en caso de utilizarla.

El valor por defecto es .

Ejemplo por cdigo

&Location.AuthenticationUser = Name

Ejemplo en XML
<Authentication>
<User>Name</User>
</Authentication>

AUTHENTICATIONPASSWORD
Especifica la contrasea para la autentificacin con el servidor, en caso de utilizarla.

El valor por defecto es .

Ejemplo por cdigo

&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 tendrn prioridad sobre estas.

En esta versin, el nico protocolo soportado es HTTP.

Obtencin de locations en tiempo de ejecucin

Para poder modificar las propiedades de un location en tiempo de ejecucin es necesario definir una
variable de tipo Location y asignarle alguna de las locations existentes. Esto se puede hacer con la
funcin getLocation( LocationName) que toma como parmetro una cadena con el nombre de algn
location existente y devuelve un tipo Location.

Por ejemplo si definimos la variable &Loc de tipo Location y tenemos algn 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 tendrn 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 generacin como en tiempo de ejecucin),
los locations Location1 y Location2 tendrn las siguientes propiedades:

Propiedad

Location1

Location2

Host

www.soapserver1.com

www.soapserver2.com

Port

80

8080

BaseURL

/soap/services/

/webservices/

Secure

Timeout

30

Authentication

AuthenticationMethod

AuthenticationRealm

(vaco)

(vaco)

AuthenticationUser

(vaco)

UserName

AuthenticationPassword

(vaco)

Password

Tipo de Datos XMLWriter

Introduccin

El objetivo del tipo de datos XMLWriter es proveer la posibilidad de grabar archivos XML de un modo
ms sencillo que las funciones incluidas en versiones anteriores. El documento XML contiene una
introduccin a dicho lenguaje.

Se recomienda leer tambin 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.

Descripcin

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 mtodos necesarios para crear
los nodos que lo componen.

Mtodos

MTODOS BSICOS

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
invocacin
a
WriteStartElement(<ElementName>)
o WriteElement(<ValueName>,
<ElementValue>).

<AttriName> - Character
<AttriValue>

- Character

WriteEndElement()
Cierra el ltimo elemento abierto.

Close()
Cierra el documento.

OTROS MTODOS

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 seccin Cdata con el valor <DataValue>.
Si el contenido especificado para la seccin 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 declaracin de XML usando la versin 1.0 y codificacin ISO-8859-1.
Opcionalmente se puede indicar un entero (0/1) como valor booleano para usar en la
declaracin standalone y un encoding.
Este mtodo debe ser llamado al comienzo de la generacin del documento (luego del
open() y antes de cualquier otro mtodo).

Ejemplo:

WriteStartDocument() genera lo siguiente:

<?xml version=1.0 enconding=ISO-8859-1 ?>

Enconding - Character
StandAlone Integer (0/1)

WriteDocType(<DocName> [,SubSet])
Escribe la declaracin DOCTYPE del documento XML. Si se incluye un SubSet se ingresa
entre corchetes al final de la declaracin.

Ejemplo:

WriteDocType(<book>, <!ENTITY ge entity>) genera lo siguiente:

<!DOCTYPE <book> [<!ENTITY ge entity>]>

<DocName> - Character
SubSet Character

WriteDocTypeSystem(<DocName>,<uri> [,SunSet])
Escribe la declaracin DOCTYPE del documento XML con una declaracin de tipo
SYSTEM. Si se incluye un SubSet se ingresa entre corchetes al final de la declaracin.
Ejemplo:
WriteDocTypeSystem(<book>, file.dtd) genera lo siguiente:
<book> SYSTEM file.dtd>

<DocName> - Character
<uri> - Character
SubSet Character

WriteDocTypePublic (<DocName>,<PubId>, <uri> [,SunSet])

<!DOCTYPE

Escribe la declaracin DOCTYPE del documento XML con una declaracin de tipo
PUBLIC. Si se incluye un SubSet se ingresa entre corchetes al final de la declaracin.
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 cdigo generado. Por defecto es 2.

IndentChar
Define el carcter que se utiliza para indentar el cdigo 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 generacin
del documento XML.

ErrDescription
Contiene la descripcin 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 mtodo OpenToString().
El documento retornado puede ser incompleto si se invoca a la propiedad antes de la
ejecucin del mtodo close().

Soporte para Namespaces

En esta seccin se describen las funcionalidades disponibles para generar documentos XML que
utilizan namespaces.

MTODOS
WriteNSStartElement(<LocalName> [,Prefix, NameSpaceURI])
Este mtodo es anlogo al WriteStartElement.
Si se indica un NameSpaceURI que no est en el mbito de definicin del elemento, o este
tiene un prefijo diferente del parmetro Prefrix, se crea automticamente el atributo
xmlns:prefix=URI

<LocalName> - Character

Prefix - Character
NameSpaceURI - Character
WriteNSElement(<LocalName> [,NameSpaceURI [,Value]])
Este mtodo es anlogo al WriteElement.
El prefijo se determina automticamente en base a los prefijos definidos en el mbito del
elemento. Si ningn 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 mtodo WriteAttribute tiene un
comportamiento especial para algunos atributos. Si el nombre del atributo es xmlns o
comienza con xmlns: se registra la definicin del atributo como la definicin de un
namespace.
De esta forma, en futuras invocaciones de un mtodo 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
reunin, 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('Descrpcin de la reunin')
&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>
<!-- Descrpcin de la reunin-->
<![CDATA[ Reunion del equipo de desarrollo de la aplicacin.
La reunin 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 documentcin de la aplicacin]]>
</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

Introduccin

El objetivo del tipo de datos XMLReader es proveer la posibilidad de leer el contenido de los archivos
XML. El documento XML contiene una introduccin a dicho lenguaje.
Se recomienda leer tambin 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.
Descripcin

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 mtodos y
propiedades necesarios para obtener la informacin de los nodos que lo componen.
La idea bsica del funcionamiento es la siguiente: existe un mtodo 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 mtodo Read() se navega a lo largo del documento en
forma secuencial obteniendo los distintos nodos del mismo.

Mtodos

MTODOS BSICOS
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 operacin.
<FileName> Character

OpenFromString(<DocXML>)
Permite abrir un documento XML contenido en un string.
<DocXML > Character

Read()
Este mtodo 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 mtodo Read(), este mtodo 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 restriccin <NodeTypeConstraint> especifica cuales son los tipos de nodos que

quiero leer. Se especifica indicando las constantes del tipo de nodo concatenadas
por medio del carcter +
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 posicin <Index> del nodo actual obtenido por el
mtodo Read o ReadType.
Solo es vlido 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
mtodo Read o ReadType.
Solo es vlido para nodos de tipo Element.

<Name> Character

ExistsAttribute(<Name>)
Retorna 1 si el atributo de nombre <Name> del nodo actual obtenido por el mtodo Read o
ReadType existe y 0 en caso contrario.

Slo es vlido para nodos de tipo Element.

<Name> Character

Close()
Cierra el documento.
OTROS MTODOS
SetDocEncoding (<Encoding>)
Permite establecer explcitamente la codificacin de caracteres utilizada en el
documento. El valor indicado tiene precedencia sobre la propiedad encoding de la
declaracin <?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 codificacin 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 vlido para nodos de tipo Element.

ReadRawXML()
Permite obtener texto XML plano a partir del inicio de un elemento.
Solo es vlido 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 mtodo tiene prioridad sobre el atributo schemaLocation del
documento XML (en caso de que exista).
Para utilizar este mtodo hay que indicar en la propiedad ValidationType que se
realice validacin por esquema o automtica.

<URI> Character

Namespace Character

Propiedades

PROPIEDADES BSICAS
Nodetype
Retorna el tipo de nodo actual obtenido por el mtodo 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 mtodo ReadType.

Name
Retorna el nombre del nodo actual obtenido por el mtodo Read o ReadType.
Solo es vlido para nodos de tipo Element y EndTag.

Value
Retorna el valor del nodo actual obtenido por el mtodo Read o ReadType.
Solo es vlido para los nodos de tipo Text, Comment, ProcessingInstruction, DocumentType
y Element

IsSimple
Indica si el nodo actual obtenido por el mtodo 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 mtodo Read o
ReadType.
Solo es vlido 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 posicin dentro de la misma respectivamente en caso de que
ErrCode sea distinto de cero.

ErrDescription
Retorna la descripcin 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 lnea 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 ledo.
Los valores posibles son:
0 No se realiza validacin
1 Validacin automtica
2 Validacin por medio de DTD
3 Validacin por medio de un Schema
4 Validacin 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
validacin, pero el xml est bien formado.

Si el valor es 0 el mtodo Read() retornar 1 aunque haya habido un error de validacin 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 seccin se describen las funcionalidades disponibles para procesar documentos XML que
utilizan namespaces.

MTODOS
Los siguientes mtodos retornan los distintos componentes del nombre de un atributo indicado por
<Index>.

Slo son vlidos 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 slo son vlidas 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 automticamente
reemplazando las referencias por sus valores. El procesamiento de las externas sin embargo puede
ser desactivado usando la propiedad ReadExternalEntities.

Se dispone adems de las siguientes funcionalidades:

MTODOS
Los siguientes mtodos permiten acceder a la notacin y entidad referenciadas por un atributo de tipo
ENTITY.
El atributo puede especificarse por medio de su posicin en el texto o por su nombre y no se verifica que sea
de tipo ENTITY. Si ninguna declaracin fue hecha en el DTD del documento para el valor atributo se devuelve
una cadena vaca.

Slo son vlidos para nodos de tipo Element.

Las posiciones se numeran desde 1.

GetAttEntityValueByIndex(<Index>)
GetAttEntityValueByName(<Name>)
GetAttEntityNotationByIndex(<Index>)
GetAttEntityNotationByName(<Name>)
<Index> <Name> -

Integer
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>
<!-- Descrpcin de la reunin-->
<![CDATA[ Reunion del equipo de desarrollo de la aplicacin.
La reunin 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 documentcin de la aplicacin]]>
</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 reunin.

&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 reunin.

&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 slo se implement la validacin por medio de DTD

El mtodo AddSchema solo est implementado para el generador .NET

Glosario
Las siguientes definiciones fueron extradas de Extensible Markup Language (XML) 1.0 (Second
Edition); por ms informacin 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

Introduccin

WebWrapper es un tipo de datos de GeneXus que permite encapsular la ejecucin de los objetos
Web (el cdigo 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.
Descripcin

Para poder enviar el contenido de un Web Panel va mail desde un objeto GeneXus es necesario
definir una variable de tipo WebWrapper, para luego aplicar los mtodos y propiedades necesarios.
La idea es capturar el contenido de un Web Panel en su cdigo HTML, y enviar ste va 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 cdigo del Web Panel.

PROPIEDADES
BaseURL: Es la direccin Base del Web Panel.

La direccin base determina el servidor y directorio virtual al que apuntarn los links y a donde se ir
a buscar el Web Panel en caso de que se presione algn botn. La direccin base es agregada al
cdigo HTML que devuelve el mtodo GetResponse.

Object: Objeto Web a encapsular en la variable de tipo WebWrapper.

A la propiedad Object debe asignrsele siempre el resultado de la funcin Create: Create(Objeto,

Parmetros)

MTODOS
GetResponse: Retorna el cdigo HTML que devolvera el objeto Web especificado en la propiedad
Object con los parmetros 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 parmetros al Web Panel Hnotify. Tambin tiene entre sus atributos
secundarios a UserName, con el nombre del usuario, y UserMail, con la direccin de correo el
electrnico 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 estticos, por este motivo al enviarlos va mail, en
realidad se est enviando una imagen esttica. Por lo tanto cualquier evento que se produzca en el
Web Panel que realice un post al servidor (por ejemplo hacer clic en un botn, disparar un
procedimiento, etc.) producir que se abra el Web Panel en el browser, en la direccin especificada
en la propiedad BaseURL.

Si se desea hacer un WebWrapper de un Web Panel que incluya imgenes, se puede hacer de dos
maneras:

Poner en el Web Panel las imgenes 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 imgenes relativas y mandarlas como archivos adjuntos en el mail. En
este caso la ruta de la imagen no debe incluir directorios (por ej.: /imgenes/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 botn o evento clic, el comportamiento al apretar dicho botn (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
redireccin, 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 pgina para mostrarla.
Pero dicho get se hace solamente si no haba una redireccin 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 botn 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
botn 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 botn modifica la base de datos y hace un call a otro Web Panel.
En Outlook 2000 y Outlook XP, al apretar el botn se hace la modificacin a la base de datos y se
abre un browser donde se muestra el Web Panel llamado. En Outlook XP se hace la modificacin 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 programacin 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 tendra 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 hara la modificacin a la base de datos por la cual se

chequea en la condicin. HGracias es el Web Panel al cual se quera hacer la redireccin al procesar
el evento.

INTRODUCCIN
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
informacin a travs de parmetros.
En el siguiente cuadro se muestran las invocaciones vlidas 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 vlidas. Verificar las combinaciones vlidas
en el documento Invocacin desde un objeto a otro.

Invocacin 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/funcin LINK y la funcin 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 seccin de reglas, eventos, u otra parte del objeto) para llamar
a un objeto GeneXus o a un programa externo, siendo posible pasarle parmetros.

UDP (User Defined Procedure) Es una funcin que permite llamar a un objeto GeneXus o
programa externo al cual se le podrn pasar parmetros, y retornar al menos un valor
como resultado de su ejecucin.

LINK - El comando o funcin link es equivalente al comando CALL para llamar a pginas
estticas o redireccionar a una URL. Este comando puede ser utilizado dentro de cualquier
evento de un objeto Web con excepcin del evento Load. El resultado de la utilizacin de
este comando es el redireccionamiento en forma automtica 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 invocacin, se pasar el control al programa llamado, y al finalizar ste su
ejecucin, devolver el control al llamador en el caso en que el objeto llamado no tenga form, retornndole
parmetros 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 tena cdigo por ejecutar el llamador luego de esta invocacin, 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 ejecucin de dicha llamada
cancelara 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
parmetros, como pasndole.
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 pginas estticas o redireccionar a una URL y en el caso que corresponda
permite pasarle parmetros.
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 parmetros que recibe la URL.
El pasaje de parmetros 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 Transaccin Web o va HTTP (por
ej.: con la propiedad Call Protocol en HTTP), podr tambin invocar con un CALL o LINK a una
URL HTTP (por ej.: llamar a un Web Panel o a una Transaccin Web).
Se debe considerar que dicha invocacin no ser ejecutada sincrnicamente. Ser ejecutada como
un redireccionamiento al objeto invocado al final de la ejecucin Web.

Un procedimiento llamado desde la lnea de comando, por ejemplo, no puede invocar a un Web
Panel. Pero s se puede utilizar la funcin opendocument() para abrir una URL en el browser.

Ejemplo

En este ejemplo se muestra como se realiza la ejecucin 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", despus 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 cul,
al final de la ejecucin en el servidor, la redireccin ir.

INTRODUCCIN
En este captulo veremos los requerimientos necesarios para los generadores .NET y Java. Tanto para
el desarrollo de aplicaciones Web como para la puesta en produccin.

Tambin profundizaremos en las propiedades necesarias para una aplicacin Web, ya sean
propiedades propias de cada generador como tambin propiedades independientes del generador.

Requerimientos .NET
Adems de los requerimientos bsicos de GeneXus 9.0 (espacio en disco, cantidad de memoria, etc.)
para cada equipo de desarrollo, se debe contar con el software mencionado a continuacin.

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 versin 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 implementacin 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
versin 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 versin 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 versin 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 versin del DBMS puede ser 7.0 o Informix
Foundation 2000. En el cliente debe estar instalado el cliente con la versin 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.

INTRODUCCIN
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 utilizacin 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 pgina HTML comprimida, para que sea descomprimida en tiempo real por el
browser. La compresin se realiza slo si el browser indica que es capaz de descomprimirlo. Esta
opcin 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
pginas, 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
Adems de los requerimientos bsicos 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
compilacin y ejecucin 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 Mquinas Virtuales)

Para la compilacin y ejecucin 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 versin 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 ms. En ese caso se podr usar
el compilador del JDK de Sun (javac.exe), que es gratuito.
Para determinar si el intrprete est instalado, puede ejecutarse lo siguiente:

C:\WINDOWS\system32>jview

Se mostrar la versin disponible del compilador y de la mquina virtual, respectivamente, por

ejemplo:

Cargador de lnea de comandos de Microsoft (R) para Java

Versin 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>
de clase

antepone la ruta a la ruta

/cp:a <ruta>
clase

agrega ruta a la ruta de

/n <nombre del espacio>

ejecutar

nombre del espacio en el que

/p
ocurre un error

pausa antes de finalizar si

/v
/d:<nombre>=<valor>
sistema
/a

comprueba todas las clases

define las propiedades del
ejecuta AppletViewer

Nombre de clase:
Archivo .CLASS a ejecutar.

Argumentos:
Argumentos de la lnea de comandos para pasar al
archivo de clase

Generalmente el intrprete de Microsoft ( jview.exe ) es parte de la instalacin de todas las

plataformas Windows, aunque no est instalado el SDK de Microsoft.

Si no est disponible o est desactualizado (esto es, con una versin anterior al 5.00.3805), entonces
se puede obtener con Windows Update.

La otra alternativa es usar el intrprete 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 intrprete de Microsoft ( jview.exe ).

COMPILADOR JIKES DE IBM

IBM provee slo el compilador Java, en forma open-source. Para instalarlo, se debe bajar la versin
para windows, que es un archivo zip.

Para la instalacin simplemente se debe descomprimir el zip hacia una carpeta, y mover sta hacia
donde quiera hacerse la instalacin. El directorio de instalacin 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 versin 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 continuacin.

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 continuacin junto con otros tipos de driver.

Los nmeros de tipos de driver corresponden a una numeracin que fij SUN.

Tipo 1: Java -> ODBC

Esta arquitectura, tiene como ventaja importante que permite la utilizacin de drivers ODBC
existentes, pero la desventaja de que hay que instalarlos en cada mquina, 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 informacin de conexin)

CLIENTE DBMS

La aplicacin GeneXus-Java se comunica con los DRIVERS JDBC. A los DRIVERS JDBC se les configura
un parmetro para indicar que la conexin es a cierto Data Source. Y finalmente con la informacin
definida en el Data Source, se establece la conexin 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
utilizacin en ambientes de produccin. 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 aplicacin Java en 2 capas, en esos casos, sera mediante este tipo de driver
llamado tambin Bridge JDBC-ODBC.

Tipo 2: Java -> Protocolo DBMS

Con esta implementacin, 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 tambin requiere que se instale en
cada mquina cliente, los DRIVERS JDBC y CLIENTE DBMS.

En general los drivers tipo 2, tambin llamados Native-API Partly-Java, se comunican muy rpido
con la base de datos, siendo en teora, los ms 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 implementacin del Servidor JDBC se realiza mediante la instalacin 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, tambin conocido como net-protocol all-Java, es que no requiere
instalacin en los clientes, segn el DBMS. Como contrapartida, este driver requiere la instalacin 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 resolvera la
conexin. En este caso, sera posible efectuar conexin 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 mquina del cliente al servidor del DBMS y es una solucin
prctica para el acceso a Intranets.

Requieren ms cdigo, por lo que si se usa en 2 capas hay que bajar ms cdigo 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 ms
comn, y el que se usa ms 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, tambin denominado native-protocol all-Java, no requiere instalacin en los

clientes, segn 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 conexin con otra
mquina que no sea el servidor de donde provino.

Browser
Para utilizar el generador Java, no es necesario tener ningn un browser instalado, sin embargo, se
recomienda tener tanto Internet Explorer como Netscape para probar el correcto funcionamiento de las
aplicaciones.
Dependiendo de la versin del Java Development Kit que se utilice, el browser puede requerir el Java Plug-In,
por lo que sera necesario disponer de este software tambin.

Visualizacin 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 fsico,
o no) para poder ejecutar Servlets.

En teora, las aplicaciones GeneXus pueden ejecutarse con cualquier Motor de Servlets que sea
compatible con la especificacin 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 automticamente con la instalacin del
Motor de Servlets, y permite que el desarrollador pueda compilar los Servlets (objetos Web de
GeneXus).

A continuacin explicaremos los pasos en orden, que se deben seguir para configurar y utilizar estos
requerimientos. Explicaremos en forma conceptual y genrica cada punto, y tomaremos a modo de
ejemplo, la opcin de utilizar el Motor de Servlets RESIN para Windows, en forma local, con el fin de
mostrar un ejemplo prctico concreto.

Configuracin de un Motor de Servlets

Para ejecutar una aplicacin Web Java, se debe configurar un motor de servlets; para ello se deben
realizar algunos pasos, que si bien varan un poco segn el motor de servlets que se vaya a utilizar,
bsicamente 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 abreviacin
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
ejecucin de una aplicacin Web.

Los tipos de archivos involucrados en la ejecucin de una aplicacin Web, pueden ser los servlets
(archivos .class), contenido esttico y libreras 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 cul 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
instalacin haya sido correcta, as como comprobar que el motor haya levantado
bien.
b. Ejecutar el servlet: com.genexus.Webpanels.gxver, que devuelve la versin de las
clases standard de GeneXus. Mediante la ejecucin de este servlet se puede
comprobar primeramente que se estn encontrando las clases standard de GeneXus
y luego, que se trata de la misma versin 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

instalacin .ZIP en algn 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 estn tomando las clases standard de GeneXus y cul versin,
se debe ejecutar:
http://localhost:8080/servlet/com.genexus.Webpanels.gxver

Propiedades de ejecucin .NET

A continuacin se detalla el significado de cada una de las opciones que figuran en el dilogo de
configuracin de la opcin del men Build / Run (F5).

Compiler Path: Determina el path del compilador (csc.exe), este se encuentra bajo el directorio de
instalacin del Framework en:
C:\WINNT\Microsoft.NET\Framework\v1.1.4322

Virtual Directory: Determina la URL base de ejecucin, esta contiene el directorio virtual a ser
creado (si no existe) por GeneXus en el Internet Information Service (IIS) local. El momento de la
creacin es luego de la compilacin y reorganizacin.

Propiedades de ejecucin Java

Para la ejecucin de aplicaciones Web con Java, se debe configurar las siguientes propiedades:

Platform

Se debe seleccionar el ambiente de compilacin y ejecucin, es decir cul Java Development Kit se
utilizar. Las posibilidades son:

Microsoft SDK

Sun JDK

IBMs 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, adems, 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 ubicacin 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 ubicacin del programa de make que se desea utilizar. La funcin 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 intrprete de Sun se llama java.exe mientras que el de Microsoft se llama jview.exe. Ambos
intrpretes se encuentran en el subdirectorio BIN del JDK / SDK. El intrprete de Microsoft es uno los
programas bsicos 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 ejecucin es en Windows, se suele
elegir el intrprete de Microsoft, de lo contrario el de Sun.

Normalmente se recomienda utilizar plataforma y compilador de Sun, pero con el intrprete 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 ejecucin de los
objetos Web.

Propiedades avanzadas

WEB BROWSER SETTINGS

Esta seccin aplica solamente a la ejecucin de Applets. Si se marca la opcin Use Default Browser,
se ejecutarn los Applets utilizando el browser que se tenga por defecto en el sistema.
Si no se marca dicha opcin, se puede ingresar el path del browser a utilizar. Adicionalmente, los
JDK/SDKs incluyen un programa llamado appletviewer que permite ejecutar Applets.

COMPILES OPTIONS
Permite especificar parmetros que se desee pasar al compilador elegido cada vez que GeneXus lo
llame. El compilador especificado en Compiler Path debe poder reconocer estos parmetros. Por
defecto, est dado el parmetro O, que permite generar cdigo optimizado para la ejecucin, sin
informacin para el programador.

Si se dispone del SDK de Sun y se desea ver las opciones posibles para el compilador, puede
invocarse desde lnea de comandos como:
javac -help

En la configuracin ms recomendada (plataforma y compilador de Sun, ms intrprete y nmake de

Microsoft), las opciones a pasar al compilador deben ser las siguientes:

-O 1.1 -target
INTERPRETER OPTIONS
Anlogo al anterior, permite especificar parmetros opcionales que quieran pasarse al intrprete.
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 diseo 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 produccin que
lo utilice).

Propiedades generales

Estas propiedades se definen a nivel del modelo de Diseo. Se setean mediante la opcin File / Edit
Model / Properties teniendo abierto el modelo de diseo. Las relacionadas con objetos Web son:

Base Image Path

Propiedades a nivel del Generador

A nivel de cada modelo, existen algunas propiedades (en la seccin Web Information) que aplican
exclusivamente a los objetos Web.

FOCUS CONTROL
Esta propiedad permite determinar si los objetos Web, al mostrar su pgina, intentan posicionar el
foco en el primer control de entrada (no read-only) o dejan librado al browser la posicin del foco.

Los valores posibles son:

First input att/var on the page

Browser dependent

Existe tambin la propiedad a nivel de objeto con los mismos valores que la propiedad del modelo y
tambin 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 pginas 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 parmetros que se envan entre objetos
y que son visibles en la URL del browser.
Por ms informacin referirse a la documentacin: Encriptacin de parmetros.

ON REQUEST SSP SERVER DIRECTORY

La propiedad On request SSP server directory es requerida cuando se generan SSP (Smart Static
Pages) en forma dinmica. Por ms informacin referirse a la documentacin 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 dinmica. Por ms informacin referirse a la documentacin de Smart Static Panels.

BEFORE CONNECT
La propiedad Before Connect ha sido implementada para cambiar las propiedades de la conexin
en forma dinmica en tiempo de ejecucin.
Para utilizar esta caracterstica, se requiere un Procedimiento GeneXus. Este Procedimiento debera
establecer las propiedades de conexin en tiempo de ejecucin; ser ejecutado inmediatamente
antes que el pedido de cualquier conexin sea ejecutado por la aplicacin 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 salvarn
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 despus de ser
asignada la conexin en una aplicacin. Esta implementacin permite apoyarse en los mecanismos
de auditora.

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 produccin el Web Service.

Propiedades de .NET
Estas propiedades se definen a nivel del modelo .NET y se setean mediante la opcin File / Edit
Model / Properties teniendo abierto dicho modelo.
.NET aplication Namespace

Determina el namespace de la aplicacin. 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 algn 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 configuracin 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).
Adems 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 estndar provistos por el generador tienen strong names independiente del valor de
la propiedad.

Assemblie versin number

Determina el nmero de versin a asignar a los assemblies que tienen strong name. La propiedad
slo aplica cuando la propiedad Generate strong named Assemblies est en Yes.
Valor por defecto: 1.0.0.0

Compiler Flag

La informacin de esta propiedad se incluir en el .rsp que se usa para compilar los assemblies. Es
til por ejemplo, para generar informacin de debug (incluyendo el string /debug) o para incluir
una dll dentro del namespace (/r:xxx.dll ).

Config HttpHandlers Section

La informacin de esta propiedad determina cmo se mapean los assemblies en ejecucin.

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 ms rpido en ejecucin pero ms lento en la carga inicial.
Adems permite tener objetos (*.aspx) no generados con GeneXus, con HttpHandlerFactory esto
no es as.
HttpHandlerFactory es ms rpido para prototipar pero ms lento en cada llamada porque el
mapeo se resuelve en cada requerimiento. Esta opcin puede enviar mensajes de error poco
descriptivos, lo que dificulta la prototipacin.
El valor ASHX, es similar a Handler Factory, crea un archivo fsico con el nombre del objeto y
extensin ashx, el cual es invocado en ejecucin.
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 mtodo de acceso
especificado ser utilizado para acceder a cada uno de los data stores.
Valores:
ODBC: Acceso va ODBC
ADO.NET: Acceso va 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 diseo.
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/produccin.
Time to Time: Valor que se define a nivel de modelo prototipo/produccin.
Valor por defecto: Pretty Often

Log Level

Esta propiedad permite configurar el nivel de trace de acceso a la base de datos con conexin
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 tambin se escribe el tag <trace
enabled=true />.

Propiedad Maximum Cached cursors per connection

Uno de los costos ms importantes en las operaciones ODBC/ ADO.NET es el de preparar las
sentencias SQL. La preparacin incluye la compilacin y validacin 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 tamao por defecto es de 100 cursores. Si se desea cambiar este
nmero, se puede cambiar el valor de esta propiedad.
Valor por defecto: 100

Propiedades del modelo Java

A continuacin se explican las propiedades que deben configurarse para la generacin 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 especfico de la
estructura obtenida al instalar el Motor de Servlets. La misma vara en cada caso, dependiendo del
Motor de Servlets que se utilice.

Propsito

Permite especificar el directorio donde se transferirn los Servlets generados. En tiempo de

compilacin 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 generacin 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 copiarn adems de los archivos .class, los archivos .cfg, los cuales contienen la
informacin de las propiedades ingresadas; por lo tanto, si se modifica algn valor de las
propiedades del modelo, es necesario volver a generar y compilar algn objeto Web.
Adems, 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 mquina 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

Propsito

Indica el directorio donde los servlets buscarn el contenido esttico (imgenes, 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 aplicacin, sino solo un objeto Web. Si est
en produccin, slo basta con modificar el archivo client.cfg.

Ejemplo de valores

Si se crea un directorio llamado images bajo el directorio raz del webapp donde se instalaron los
servlets, y a l se copian todas las imgenes necesarias, y en diseo slo se especifica el nombre de
la imagen, entonces en esta propiedad habra que poner /images.

Propiedad Static Content directory seen from client

Propsito

Permite especificar el directorio donde se transferirn los JavaScripts (archivos *.js) que se generan
para los menubars de objetos Web y Web Panels generados como estticos. En tiempo de
compilacin, el generador los copiar al directorio especificado.

Notas:

En este mismo directorio tambin habrn archivos de imgenes que se utilicen en los
objetos Web. Los mismos se deben copiar manualmente a este directorio, y en los
programas generados se referenciarn utilizando el valor de la propiedad Static Content
Base URL concatenada con el nombre de cada imgen.

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 mquina, mapeada con el drive X y
es el directorio images el utilizado para dejar el contenido esttico.

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 imgenes.

Propiedad Auto Compress HTTP Traffic

Propsito

Los objetos Web, en Java, pueden enviar la pgina HTML comprimida, de modo que sea
descomprimida en tiempo real por el browser. La compresin se realiza solamente si el browser
indica que es capaz de descomprimirlo.

Valores

Yes: envan la pgina comprimida.

No: no envan la pgina comprimida. Es posible que algunos navegadores no reporten
correctamente su capacidad para descomprimir las pginas, y no puedan desplegarlas
correctamente.

Default Value = Yes.

Generation Mode
Esta propiedad permite especificar si los objetos Web del modelo se generarn como objetos
dinmicos (acceden a la base de datos) o como pginas HTML inteligentes (Smart Static Panels).

Tambin 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 parmetros 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 ms informacin referirse a la documentacin de Smart Static Panels

Existe tambin la propiedad a nivel de objeto con los mismos valores que la propiedad del modelo y
tambin el valor Use model's property value.

Puesta en Produccin 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 instalacin 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

Instalacin en el servidor

En una aplicacin Web es necesario copiar al servidor:

El directorio bin del modelo (donde se encuentran las dlls de cada objeto)

Los java script ( *.js)

Las imgenes, htmls, *.css y cualquier contenido esttico deseado

El archivo Web.config

Si se usan tipos de datos de Office, es necesario registrar la gxoffice2.dll

Instalacin en el Cliente

Cliente Web, solamente alcanza con un browser. Para el caso de Internet Explorer la mnima versin
soportada es I.E. 6.0. Para poder visualizar los Resportes PDF debe tener instalado el Adobe Acrobat
Reader.

Puesta en Produccin Generador Java (War Deployment)

Introduccin

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
dnde colocar el contenido esttico. Adems, una vez que se hace funcionar todo en un ambiente
de prototipo hay que llevarlo a produccin, 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 slo archivo, todo lo necesario, para la instalacin y ejecucin de
una aplicacin Web Java, en los distintos motores de servlets, o servidores J2EE, de forma sencilla.

El War Deployment genera archivos con extensin .WAR (Web Archive Resource), los cuales son
bsicamente archivos .JAR a los cuales se les cambia la extensin a .WAR. Estos archivos
empaquetan servlets, contenido esttico, libreras adicionales y un archivo con formato XML, al cual
se le llama descriptor, que contiene cierta informacin de la aplicacin Web como por ejemplo el
nombre de la aplicacin, nombre de los servlets, mapeos, etc.).

Configuracin

Para distribuir una aplicacin Web, se debe ejecutar el Deployment Wizard, a travs del Win
Developer Menu. Este, permitir seleccionar los objetos Web main para los que se desee armar el

deployment, y luego automticamente 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, ms 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 aplicacin 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 aplicacin 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

funcin de ello se arma el descriptor correspondiente (se profundiza
ms adelante).

Web Application Name

Este es el nombre que identifica a la aplicacin 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 libreras adicionales para ejecutar la

aplicacin; el caso ms comn es el de los drivers JDBC.

Additional Files

Esta es una estructura de directorios (que por defecto es vaca) en la

cual se puede agregar todo el contenido esttico que se necesite para
ejecutar la aplicacin.

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 esttico a los Additional Files en el

directorio seleccionado.

Remove Files

Permite borrar un contenido esttico 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
Descriptor

Deployment

Al chequear esta opcin se permite modificar el

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 propsito de este anexo es explicar una serie de conceptos sobre cmo 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 intencin de este captulo es establecer el lenguaje comn que utilizaremos a lo largo del
curso en lo que a Internet se refiere, trataremos de dar una visin intuitiva de los temas para no
aburrir al lector con detalles innecesarios.

Definiremos los siguientes conceptos:

Internet

WWW

Pgina Web

URL

Protocolo HTTP

HTML

Aplicacin Web

Tecnologas de las aplicaciones Web

o

Servlets

Asp.net

Javascript

Intranet

Comencemos entonces con definiciones bsicas.

Internet
Internet es el nombre genrico que recibe la unin de todas las redes de comunicacin a nivel
mundial. Se podra 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 comnmente, Internet no es sinnimo 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 informacin con interfaz grfica, fcil de usar, que emplea la red Internet como
medio de transmisin y permite navegar para buscar documentos en Internet. Estos documentos,
como tambin los links que existen entre ellos forman un "Web" de informacin.
El Web permite saltar o "hyperlink" de una pgina 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 electrnicos) y las pginas Web son como las
pginas especficas de estos libros. Estas pginas pueden contener noticias, imgenes, sonidos, 3D,
etc. Adems pueden estar ubicadas en computadoras de cualquier parte del mundo.
Los libros electrnicos mantienen el concepto bsico del libro, y adems, 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 informacin.

Algunos de los servicios disponibles en Internet aparte de la Web son el acceso remoto a otras
mquinas (SSH y telnet), transferencia de archivos (FTP), correo electrnico (SMTP), boletines
electrnicos (news o grupos de noticias), conversaciones en lnea (IRC y chats), mensajera
instantnea (MSN Messenger, ICQ), transmisin de archivos, etctera.

Pgina Web
Una pgina Web es un documento de la World Wide Web normalmente en formato HTML .
Una pgina Web tpicamente, incluye texto, imgenes y enlaces hacia otros documentos de la red,
pudiendo adems contener animaciones, sonidos, programas en Java, y cualquier otro tipo de
documento, por medio de plugins y otras tecnologas.
Actualmente las pginas Web ya no estn nicamente enfocadas para ser visualizadas, sino que cada
vez son ms dinmicas permitiendo que el visitante participe en ellas mediante menes interactivos,
encuestas, votaciones, etc.

En el Web se distinguen bsicamente dos tipos de pginas. Las pginas estticas y las pginas
dinmicas.

Las pginas estticas son las ms sencillas, se crean usando un editor de pginas Web o bien
escribiendo directamente el cdigo HTML.
Mientras que se ajustan muy bien a los requerimientos iniciales de hacer promocin 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 pginas son: Informacin general, Marketing, Informacin similar a la que
se distribuye en folletos y documentos. Tienen la ventaja de brindar un acceso rpido y cmodo a
informacin y brindar direcciones de correo electrnico para informacin y soporte.

Las pginas dinmicas son creadas en el momento en que son referenciadas por el usuario. Si bien
tienen un estilo base, la informacin desplegada en las mismas es dinmica.

Son interactivas, ya que permiten que la pgina a visualizar pueda ser creada en base a la
informacin ingresada por el usuario. Por ejemplo, una consulta de los pedidos pendientes de una
orden de compra.

Las pginas dinmicas 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 pginas, la actualizacin se realiza en forma automtica, pues al acceder a la
pgina se accede a la base de datos con la informacin actualizada.

Algunos ejemplos que se prestan para una aplicacin que utilice pginas dinmicas:

Home Banking: operaciones varias sobre cuentas bancarias.

Divulgacin de informacin: acceso a informacin publicada por la empresa dependiendo

del rol. Por ejemplo sin costo en el caso de que la informacin sea pblica y con costo para
aplicaciones en el que se exigen una validacin de usuario.

Comunicacin 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 artculos desde la casa, similar a la compra por catlogo.

Las aplicaciones Web desarrolladas con GeneXus generan normalmente pginas dinmicas (porque
acceden a la base de datos).

Intranet
Una Intranet es una red de rea Local (LAN) privada empresarial o educativa que proporciona
herramientas va Internet, las cuales tienen como funcin principal proveer lgica de negocios para
aplicaciones de captura, reportes, consultas, etc. con el fin de auxiliar la produccin de dichos grupos
de trabajo; es tambin un importante medio de difusin de informacin interna a nivel de grupo de
trabajo. No necesariamente proporciona Internet a la organizacin; normalmente, tiene como base
el protocolo TCP/IP de Internet y, por ser privada, puede emplear mecanismos de restriccin de
acceso a nivel de programacin como lo son usuarios y contraseas 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.

Aplicacin Web
Una aplicacin Web es aquella que los usuarios usan accediendo a un servidor Web a travs de
Internet o de una Intranet.
Son populares debido a la practicidad del navegador Web como cliente ligero. Otra razn
importante de su popularidad es la habilidad para actualizar y mantener aplicaciones Web sin
distribuir e instalar software en miles de potenciales clientes.

Tecnologas
Para poder comprender mejor la tecnologa escondida detrs de las aplicaciones desarrolladas para el Web,
es necesario aclarar algunos conceptos adicionales.
Los diferentes lenguajes utilizan diferentes tecnologas para generar las pginas dinmicas.
Inicialmente surgi la tecnologa 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 tecnologas 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 refera a pequeos programas escritos en Java que
se ejecutan en el contexto de un navegador Web. Por contraposicin, un servlet es un programa que se
ejecuta en un servidor Web.
El uso ms comn de los servlets es generar pginas Web de forma dinmica a partir de los parmetros de la
peticin que enve el navegador Web.
ASP.NET es otra alternativa de Microsoft para el desarrollo de aplicaciones Web. Esta tecnologa se
desarroll para la nueva plataforma .NET y se trata de una evolucin de las ASP o Active Server Pages.
Tambin en este caso se trata de aplicaciones que ejecutan en el servidor y envan el HTML resultante al
cliente. Los programas en el servidor son .dlls que se invocan con extensin .aspx.
Las aplicaciones Web utilizan tambin cdigo JavaScript para permitir mayores funcionalidades.

JavaScript
JavaScript es un lenguaje interpretado orientado a las pginas Web, con una sintaxis semejante a la del
lenguaje Java.
Se ha convertido en un verdadero lenguaje de programacin que aporta la potencia de clculo del navegador
para aumentar la usabilidad de aplicaciones Web con tcnicas avanzadas como Ajax.

Ajax
Ajax es una arquitectura y no una tecnologa. Ajax stands for Asynchronous JavaScript XML.
Incorpora:

Basado en estndares de presentacin usando XHTML y CSS;

Despliegue e interaccin dinmica usando Document Object Model;

Intercambio y manipulacin de datos usando XML y XSLT;

Recuperacin asincrnica 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 pgina, en una
experiencia continua y unida, donde los usuarios interactan con una interfase que rpidamente
responde, sin importar las conexiones al servidor que pasana ser invisibles al usuario..

URL
Bsicamente una URL es una direccin Web.

Cuando visualizamos una pgina Web con Netscape, Internet Explorer o cualquier otro navegador,
los links (visualizados subrayados y generalmente en color azul), contienen informacin oculta que
apunta a la ubicacin del recurso al que se hace referencia.

Se puede pensar una URL como un puntero estndar a un recurso Internet. El recurso podra ser un
grfico, un sonido o simplemente un archivo de texto.
Las URLs tambin pueden usarse para iniciar sesiones telnet, ftp y otros servicios.

En muchos casos es conveniente conceptuar una URL como el equivalente de estndar DOS para
nombre y path de un archivo.
De hecho una URL puede apuntar a un archivo en la mquina local y tambin puede apuntar a un
archivo especfico de un directorio especfico en una mquina 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: Ubicacin y nombre del documento en el servidor.

[parm1,...,[parmn]] Informacin 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
especfica del esquema.
Una URL relativa comprende slo la parte especfica del protocolo de una URL, o de algn
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 transaccin de la Web
(WWW). El hipertexto es el contenido de las pginas Web, y el protocolo de transferencia es el
sistema mediante el cual se envan las solicitudes de acceder a una pgina Web (desde un Web
browser), y la respuesta de esa Web (desde un programa http Server), remitiendo la informacin
que se ver en pantalla. Tambin sirve el protocolo para enviar informacin 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 informacin sobre
conexiones anteriores. Al finalizar la transaccin todos los datos se pierden.
Est basado en el modelo cliente-servidor: un cliente HTTP abre una conexin y realiza su solicitud al
servidor, el cual responde generalmente el recurso solicitado y la conexin se cierra.

Se establecen 4 pasos bsicos en el protocolo HTTP:

1) Conexin: Durante la conexin, el Web browser intenta conectarse al servidor. Si el browser no

logra la conexin 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 conexin al servidor HTTP ha sido establecida, el browser enva 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 conexin: 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:

<Lnea inicial>
Header-1: value-1
...
Header-n: value-n

<Cuerpo del mensaje (Opcional)>

La lnea inicial es diferente en las solicitudes y en las respuestas.

En las solicitudes van tres campos separados por un espacio en blanco: "Mtodo recurso
VersinDelProtocolo". Por ejemplo: "GET /path/to/file/index.html HTTP/1.0".
La lnea inicial de una respuesta tiene tres campos separados por un espacio: "versinDelProtocolo
cdigoRespuesta Mensaje". Por ejemplo: "HTTP/1.0 200 OK" o bien "HTTP/1.0 404 Not Found".

Los encabezados estn normados en el protocolo, e incluyen, en el caso de una solicitud,

informacin del navegador y eventualmente del usuario cliente; en el caso de una respuesta,
informacin 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 parmetros de la llamada archivos enviados al servidor. Cabe sealar que los principales
navegadores Web no muestran al usuario los encabezados HTTP del recurso.

La caracterstica 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 conexin con l, y de esta

forma reconocer a un visitante que ya estuvo en ese sitio anteriormente. Gracias a esta
identificacin, el sitio Web puede almacenar gran nmero de informacin sobre cada visitante,
ofrecindole as un mejor servicio. (Ms adelante profundizaremos en cookies.)
Existe tambin una variante de este protocolo, que brinda comunicaciones seguras en Internet
denominado https. Tambin profundizaremos en este concepto ms adelante en este curso.

HTML
Es el lenguaje en el cual estn escritos los documentos del WWW. Es un subconjunto especializado
del lenguaje ms general SGML (Standard Generalized Markup Language).
El lenguaje HTML est compuesto por una serie de cdigos o tags ubicados dentro de un documento
ASCII, que son traducidos por un Web browser como Netscape, Internet Explorer, etc., en
instrucciones especficas para formatear el documento que se va a desplegar en la pantalla. Entre
dichos tags estn 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 ttulo al documento y donde se indican otros parmetros
que el browser podra 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 cmo desplegar el texto. Los tags tambin referencian
archivos de efectos especiales como imgenes y sonido e indican los hot spots que enlazan el
documento a otros documentos.

Un ejemplo de cdigo HTML podra 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 vera 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 diseado para transferir pginas 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 peticin 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 peticin
HTTP al servidor de dicha direccin. El servidor responde al cliente enviando el cdigo HTML de la
pgina; el cliente, una vez recibido el cdigo, lo interpreta y lo muestra en pantalla. Como vemos con
este ejemplo, el cliente es el encargado de interpretar el cdigo HTML, es decir, de mostrar las
fuentes, los colores y la disposicin de los textos y objetos de la pgina; el servidor tan slo se limita
a transferir el cdigo de la pgina sin llevar a cabo ninguna interpretacin de la misma.

Sobre el servicio web clsico podemos disponer de aplicaciones web. stas son fragmentos de
cdigo 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 mquina del usuario. Son las aplicaciones tipo
Java o Javascript: el servidor proporciona el cdigo 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 (tambin llamadas scripts). Normalmente, los navegadores
permiten ejecutar aplicaciones escritas en lenguaje javascript y java, aunque pueden aadirse ms
lenguajes mediante el uso de plugins.
Aplicaciones en el lado del servidor:
el servidor web ejecuta la aplicacin; sta, una vez ejecutada, genera cierto cdigo HTML; el servidor
toma este cdigo recin creado y lo enva al cliente por medio del protocolo HTTP.
Las aplicaciones de servidor suelen ser la opcin por la que se opta en la mayora de las ocasiones
para realizar aplicaciones web. La razn es que, al ejecutarse sta en el servidor y no en la mquina
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
bsico puede utilizar este tipo de aplicaciones.

Ejemplos de servidores web son Apache, IIS, Websphere.

Web Browser

Un navegador web o web browser es una aplicacin que permite al usuario recuperar y visualizar
documentos de hipertexto, comnmente descritos en HTML, desde servidores web de todo el
mundo a travs de Internet.
Los navegadores actuales permiten mostrar o ejecutar: grficos, secuencias de vdeo, sonido,
animaciones y programas diversos adems del texto y los hipervnculos o enlaces.
El seguimiento de enlaces de una pgina a otra, ubicada en cualquier computadora conectada a la
Internet, se llama navegacin; que es de donde se origina el nombre de navegador. Otra
denominacin es explorador web inspirada en uno de los navegadores ms 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 lgica del programa, por lo tanto depende principalmente del servidor central
para las tareas de procesamiento.
La palabra liviano se refiere a lo pequea que es la imagen de arranque, quizs no ms grande que la
requerida para conectar a la red y arrancar un navegador web.