Bienvenido al curso “Desarrollo de aplicaciones para

Internet con GeneXus”

Este curso - actualizado a la versión GENEXUS 8.0 - lo va a capacitar en el
desarrollo de aplicaciones para Internet utilizando los objetos web GENEXUS.

Para poder realizar el curso debe contar con la versión 8.0 de GENEXUS o
superior. El curso consta de los conceptos teóricos necesarios para el desarrollo de
una aplicación web, así como la puesta en práctica de los mismos en una
aplicación ejemplo. El desarrollo de esta aplicación podrá ser visualizado paso a
paso a lo largo del curso mediante videos incluidos en el mismo. La idea es que
Ud. vaya realizando esta aplicación en paralelo (a medida que avanza capítulo por
capítulo en forma ordenada).

En caso de estar interesado en consultar a un docente del curso las dudas que le
vayan surgiendo, y/o dar un examen final de forma tal de obtener (en caso de
aprobación) un certificado de haberlo realizado en modalidad no presencial,
diríjase a nuestro sitio de capacitación a distancia:

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

contratar estos servicios.

INTRODUCCION AL CAPITULO 1
Para poder entender cómo funciona el Web, necesitamos primero conocer el
significado de ciertos conceptos que vamos a usar frecuentemente a lo largo de
todo el curso. Por lo cual, comenzaremos con estas definiciones para luego sí
introducirnos en el desarrollo de aplicaciones para Internet.

Comencemos entonces con algunas definiciones …

¿Qué es INTERNET?
Internet es el nombre genérico que recibe la unión de todas las redes de
comunicación a nivel mundial. Se podría definir como una red global en la que se
unen todas las redes que utilizan protocolos TCP/IP y que son compatibles entre
sí.

¿Qué es el WEB o WWW?

El Word Wide Web (Web o WWW) brinda una interfaz gráfica, fácil de usar que
permite navegar para buscar documentos en Internet. Estos documentos, como
también los links que existen entre ellos forman un "web" de información.

El WEB permite saltar o "hyperlink" de una página web (o web page) a otras.
Puede pensarse en el WEB como una gran biblioteca. Web sites son como los
libros (libros electrónicos) y las páginas web son como las páginas específicas de
estos libros. Estas páginas pueden contener noticias, imágenes, sonidos, 3D, etc.
Además pueden estar ubicadas en computadoras de cualquier parte del mundo.

Los libros electrónicos mantienen el concepto básico del libro, y además, brindan
la oportunidad de disponer de una estructura no lineal, la que permitirá, entre
otras cosas, decidir el orden en el que se desea recibir la información.

EN EL WEB SE DISTINGUEN, BASICAMENTE,

DOS TIPOS DE PAGINAS
o Páginas estáticas
o Páginas dinámicas

Páginas estáticas
Las páginas estáticas son las más sencillas, se crean usando un editor de páginas
Web o bien escribiendo directamente el código HTML.

Mientras que se ajustan muy bien a los requerimientos iniciales de hacer

promoción y obtener alguna venta ocasional, o bien la venta masiva de muy pocos
productos, no se adecuan a la mayor parte de las necesidades de la venta.

La desventaja que presentan es que el mantenimiento de las mismas implica un

alto costo si se realizan cambios con frecuencia, ya que una persona debe realizar
las modificaciones correspondientes.

Algunos ejemplos de estas páginas son: Información general, Marketing,

Información similar a la que se distribuye en folletos y documentos. Tienen la
ventaja de brindar un acceso rápido y cómodo a información y brindar direcciones
de correo electrónico para información y soporte.

Páginas dinámicas
Las páginas dinámicas son creadas en el momento en que son referenciadas por el usuario. Si
bien tienen un estilo base, la información desplegada en las mismas es dinámica.

Son interactivas, ya que permiten que la página a visualizar pueda ser creada en base a la
información ingresada por el usuario. Por ejemplo, una consulta de los pedidos pendientes de
una orden de compra.

Las páginas dinámicas permiten interactuar con una base de datos, por lo que son una
poderosa herramienta para impulsar los negocios de la empresa.

Al utilizar este tipo de paginas, la actualización se realiza en forma automática, ya que al

acceder a la página se accede a la base de datos con la información actualizada.

A continuación se presenta una lista de ejemplos que se prestan para una aplicación que utilice
páginas dinámicas:

 Home Banking: operaciones varias sobre cuentas bancarias.

 Divulgación de información: acceso a información publicada por la empresa.
* sin costo en el caso de que la información sea pública

* con costo para aplicaciones en el que se exigen una validación de

usuario.
 Comunicación con proveedores: para hacer órdenes de compra, verificar existencia
de stock.
 Intranet: Aplicaciones internas de la empresa. No pueden ser accedidas desde fuera.
 Venta directa: Compra de artículos desde la casa, similar a la compra por catálogo.

APLICACIÓN 3 CAPAS WIN VS APLICACIÓN WEB

Anteriormente se clasificaban las soluciones en Internet según la frecuencia con la
que los usuarios las accedían.
Para usuarios casuales, se recomendaba una solución Web.
Para aplicaciones con usuarios frecuentes, y más avanzados, a los cuales se les
podía capacitar en el uso de una aplicación más sofisticada, se recomendaba una
aplicación 3 capas (usando Java por ejemplo).

Hoy día una aplicación web ha alcanzado el mismo nivel de sofisticación de interfaz
que cualquier aplicación Win, y debido a las ventajas que presenta (facilidad en la
instalación de la aplicación, solo se requiere un cliente “fino”: un browser, y alta
escalabilidad), ha marcado una tendencia en lo que a soluciones de software se
refiere.
Por lo tanto, la clasificación en base a la frecuencia de uso de la aplicación pasa a
ser obsoleta, y los parámetros de decisión en cuanto a que tipo de solución
implementar giran en torno a otros factores.

Si la aplicación se va a crear de cero, lo que se recomienda es implementar una

solución Web.

En caso de que se disponga de una solución 2 capas, y se quiera migrar a una

arquitectura 3 capas:

Si el tiempo es un factor relevante en la migración del proyecto, pasar a Win 3

capas es más rápido que a Web.
Migrar a Web implica un costo de conversión vinculado al cambio de ambiente. Más
adelante en el curso se tratarán temas más específicos en cuanto a la comparación
GUI – WEB. Son ambientes diferentes (GUI - HTML) y es necesario tener en cuenta
ciertas consideraciones cuando se hace la conversión. Detalles de estas
consideraciones se verán también más adelante en el curso.

ALGUNAS DEFINICIONES
Para poder entender cómo funciona el web, necesitamos definir ciertos conceptos,
que son los que se van a manejar de ahora en adelante:

URL: Uniform Resource Locator

HTTP: HyperText Transfer Protocol
HTML: HyperText Markup Language

URL
Básicamente una URL es una dirección WEB.

Cuando visualizamos una página Web con Netscape, Internet Explorer o cualquier
otro browser, los links (visualizados subrayados y generalmente en color azul),
contienen información oculta que apunta a la ubicación del recurso al que se hace
referencia.

Se puede pensar una URL como un puntero estándar a un recurso Internet. El

recurso podría ser un gráfico, un sonido o simplemente un archivo de texto. Las
URL’s también pueden usarse para iniciar sesiones telnet, ftp y otros servicios.

En muchos casos es conveniente conceptuar una URL como el equivalente de

estándar DOS para nombre y path de un archivo. De hecho una URL puede
apuntar a un archivo en la máquina local y también puede apuntar a un archivo
específico de un directorio específico en una máquina remota.

Sintáxis  protocol://host/path/filename[?parm1,…,[parmn]]

protocol: Especifica el protocolo de acceso.

Ejemplos: file, ftp, http, telnet

host: Nombre del host al cual deseamos conectarnos.

Ejemplo: www.genexus.com
 path/filename:
Ubicación y nombre del documento en el servidor.

[parm1,...,[parmn]]
Información opcional para consultas

Protocolo HTTP
Como vimos antes, un documento WWW HyperMedia es servido por el protocolo
HTTP. Esto significa que los browsers WWW y los servidores WWW se comunican
entre sí para procesar las solicitudes del usuario utilizando un conjunto de
mensajes y respuestas que son únicos para el cliente (web browser) y el servidor
(programa HTTP server). Aunque existen algunas diferencias entre browsers y
servidores WWW, todos se comunican a través del protocolo HTTP.

Se establecen 4 pasos básicos en el protocolo HTTP:

1) Conexión: Durante la conexión, el Web browser intenta

conectarse al servidor.
Si el browser no logra la conexión en una determinada cantidad
pre-configurada de tiempo, se desplegará un mensaje de error y la
consulta del usuario cancelará.

2) Solicitud: Una vez que la conexión al servidor HTTP ha sido

establecida, el browser envía una solicitud para el recurso deseado
en el servidor.

3) Respuesta: Si el servidor encuentra el recurso, éste es enviado

al browser y se pasa al último paso. De lo contrario, un mensaje de
error es enviado y se pasa al último paso.

4) Se cierra la conexión.

Si el servidor retornó el recurso solicitado, el browser realizará la

carga del mismo y será desplegado al usuario.
HTML
Es el lenguaje en el cual están escritos los documentos del WWW. Es un
subconjunto especializado del lenguaje más general SGML (Standard Generalized
Markup Language).

El lenguaje HTML está compuesto por una serie de códigos o tags ubicados dentro
de un documento ASCII, que son traducidos por un web browser como Netscape,
Internet Explorer, etc, en instrucciones específicas para formatear el documento
que se va a desplegar en la pantalla. Entre dichos tags están incluidos los tags de
hyperlinks, que permiten especificar enlaces hacia otros recursos en el Web.

Un documento HTML consiste de texto que compone el contenido del documento y

tags, los cuales definen la estructura y apariencia del documento. La estructura de
un documento HTML es simple.

Cada documento tiene un cabezal (head) y un cuerpo (body), delimitados por los
tags <head> y <body>. El cabezal es donde se indica un título al documento y
donde se indican otros parámetros que el browser podría utilizar en el momento
de desplegar el documento. El cuerpo es donde se coloca el contenido
propiamente dicho del documento HTML. Esto incluye el texto a desplegar y otros
controles que indican al browser cómo desplegar el texto. Los tags también
referencian archivos de efectos especiales como imágenes y sonido e indican los
hot spots que enlazan el documento a otros documentos.

Un ejemplo de código HTML podría ser el siguiente:

<HTML>

<HEAD>

<TITLE>This is my first page </TITLE>

</HEAD>

<BODY>shows in a very <I>simple</I> way,the basic structure of

an HTML document.

</BODY>

</HTML>

el cual se vería en un browser de la siguiente forma:

Para poder comprender mejor la tecnología escondida detrás de las aplicaciones
desarrolladas para el web, es necesario aclarar algunos conceptos adicionales, los
cuales definimos en orden de aparición histórica:

CGI: Common Gateway Interface

WEB CLASSES

SERVLETS

ASP.NETCGI

CGI es un estándar que define la interfaz entre aplicaciones externas y servidores

de información (Web Servers y HTTP).

Con CGI el servidor Web puede realizar llamadas a programas externos, pasando
datos específicos del usuario al programa. El programa luego procesa esos datos y
el servidor devuelve la respuesta del programa al Web browser.

Un programa CGI puede ser escrito en diferentes lenguajes como: C/C++, Visual
Basic, PERL, etc.WEB CLASSES
A partir de Visual Basic 6.0 existen nuevas facilidades para generar aplicaciones
para Internet, la más notoria es la llamada WebClasses Designers. Estos
objetos son programados en Visual Basic y al compilarlos se crea un ActiveX DLL,
que será ejecutado por el Web Server (Microsoft Internet Information Server), y
un archivo .ASP (Active Server Page) que sirve como punto de entrada para cada
clase en la DLL.
SERVLETS
Junto con JAVA aparecieron componentes para el web con la misma funcionalidad
mencionada anteriormente en relación a CGI y ASP denominados servlets. Son
clases JAVA que ejecutan en el servidor y permiten obtener información en forma
dinámica que luego envían al cliente.

ASP.NET
ASP.NET es otra alternativa de Microsoft para el desarrollo de aplicaciones web. Esta
tecnología se desarrolló para la nueva plataforma .NET de Microsoft y se trata de una
evolución de las ASP o Active Server Pages. Tambien en este caso se trata de aplicaciones que
ejecutan en el servidor y envian el HTML resultante al cliente. Los programas en el servidor son
.dll’s que se invocan con extensión .aspx.

ARQUITECTURA GENERAL
En la imagen que mostramos a continuación se puede observar un esquema
simplificado de la topología de Internet.

Por un lado se tiene la red de la empresa (Intranet), donde se tiene un Servidor

Web en el cual se publican las páginas Web. Este servidor puede ser también el
servidor de base de datos, o se puede tener un servidor específico para realizar
esta tarea.

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

Por otro lado, los usuarios de la empresa (Intranet) podrán acceder a las páginas
públicas y a las páginas privadas de la empresa.
REQUERIMIENTOS BASICOS PARA PUBLICAR
PAGINAS (ESTATICAS O DINAMICAS) EN
INTERNET
Se debe disponer de una red TCP/IP, es decir, que tanto el servidor como el cliente deben
tener instalado el protocolo de red TCP/IP.

El servidor debe tener un software que lo habilite como servidor Web, normalmente es a este
software al que se denomina Servidor Web o Web Server.

El cliente únicamente necesita un browser para poder visualizar las páginas Web.

Más adelante, se especificará el software adicional necesario, dependiente del generador, para
poder desarrollar los objetos Web. Los requerimientos de software para el desarrollo varían
dependiendo de la plataforma y generador en la cual se esté trabajando.

Resumiendo, los requerimientos básicos, independientes de plataforma y generador, serían los

siguientes:

EN EL SERVIDOR

 TCP/IP - protocolo de comunicación que conforma la red.

 Servidor Web - software que se instala en el servidor y permite hacer públicas las
páginas.

EN EL CLIENTE

 TCP/IP
 Browser - nos permite visualizar las páginas.
¿QUE ES UN SERVIDOR WEB?
El servidor web, es un software que habilita al servidor para la publicación de
páginas web, también es denominado Web Server.

Debe ser configurado, de forma que permita el acceso de usuarios que se

conectan a través de Internet. La imagen que se muestra a continuación, es
simplemente un ejemplo de Servidor Web.
Debe tenerse en cuenta que si bien la información a configurar es siempre la
misma, el diálogo de configuración varía dependiendo del Servidor Web que se
esté utilizando.

La imagen muestra en la consola del IIS (Internet Information Server), como se

ha definido un alias de nombre “services”.

En la figura a continuación se pueden ver las propiedades del alias “services”

definido, en particular el directorio físico al cual se corresponde (Local Path).
Básicamente, la configuración consiste en determinar un alias que será utilizado
por los usuarios de Internet para el directorio raíz, y su correspondiente directorio
físico en el Servidor.

En particular en el caso del generador .Net (que hemos elegido para ejemplificar
los ejercicios prácticos del curso), el directorio virtual y su alias son creados
automáticamente y no es necesario que el usuario lo haga por su cuenta en etapa
de desarrollo.

Para poder publicar páginas dinámicas, es común definir uno o varios directorios adicionales
con permisos de ejecución.

También se pueden definir múltiples directorios virtuales con permisos de lectura para colocar
diversas páginas estáticas, imágenes, etc.

Los conceptos de directorio virtual y alias son manejados en todos los servidores
Web, lo que varía es la interfaz que provee cada Web Server para realizar la
configuración correspondiente.

El alias es el nombre que utilizarán los usuarios de Internet para acceder a las
páginas web. Estas páginas están físicamente almacenadas en un directorio
(conocido como directorio virtual).

Veamos un ejemplo para ilustrar esto:

Podemos tener en el directorio c:\empresa\prensa\publicaciones páginas web en
formato .htm las cuales queremos publicar en la web. Entonces, con un directorio
virtual podemos colocarle un alias a esta dirección (denominado “PUBLICO”).

De esta forma, los usuarios web mediante la url

http://ServerWeb/publico/prensa.htm accederán al archivo físico que se
encuentra ubicado en c:\empresa\prensa\publicaciones\prensa.htm del disco local
de la máquina que tiene el servidor Web instalado (ServerWeb).

PLATAFORMAS Y ALTERNATIVAS PARA EL

DESARROLLO DE APLICACIONES WEB
Los generadores disponibles para generar objetos web son:

 C/SQL
 .Net
 Java
 Visual Basic

Por lo tanto, pueden ejecutarse en un servidor Web Windows (usando C/SQL, .Net, Java o VB),
en servidores UNIX (usando C/SQL o Java) o en servidores Iseries (Java).

Los objetos web podrán usar cualquier manejador de base de datos, dentro de las plataformas
soportadas por cada uno de los generadores GeneXus.

Gráficamente, las alternativas serían las siguientes:

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

INTRODUCCION AL CAPITULO 2
Identificamos como “objetos web” a los objetos que se utilizan para desarrollar aplicaciones
web con GENEXUS: Web Panels y Transacciones con form HTML.

A continuación, se enumeran las principales diferencias de dichos objetos con respecto al resto
de los objetos GENEXUS:

 Se utiliza un editor WYSIWYG (What You See Is What You Get) orientado a páginas
para la edición de objetos web (Web Objects).

 Los objetos ejecutan en el servidor.

 El trabajo se realiza a pantalla completa (diálogo full screen en lugar de campo a

campo)

A lo largo del curso profundizaremos sobre estos aspectos.

En este capítulo, comenzaremos a trabajar con el editor de objetos web y veremos sus
principales características…

FUNCIONAMIENTO - ARQUITECTURA
Al utilizar objetos web las páginas se crean en tiempo de ejecución, basadas en el
input del usuario.

Para comprenderlo mejor, veamos un ejemplo:

1. Supongamos que tenemos un documento Web que permite al usuario ingresar

un número de cliente y, de regreso, el servidor formatea y despliega el estado de
la orden del cliente. Para realizar esto, es necesario incluir en el documento un
form input que solicite al usuario el ingreso del número del cliente.

2. Cuando esta información es ingresada, el número de cliente es enviado al

servidor para ser procesado. Para poder realizar dicho procesamiento, es
necesaria una consulta a una base de datos y los resultados deben ser
capturados, formateados apropiadamente (en HTML) y retornados al usuario.

En este proceso, el servidor Web está actuando como un gateway entre la base de
datos y el cliente de browser. En realidad el servidor Web simplemente está
pasando el número de cliente al objeto web que realizará la consulta a la base de
datos, formateará los resultados y retornará los datos formateados al servidor, el
cual, a su vez, pasará esta salida al browser para que sea desplegado al usuario.

3. Los datos que devuelve el objeto web (en nuestro ejemplo, el estado de la
orden del cliente) al servidor, son simplemente escritos por el mismo utilizando el
método normal de retorno de información del lenguaje utilizado.

4. El servidor luego captura esa información y se la pasa al browser, el cual la

despliega al usuario.Gráficamente, el ciclo sería el siguiente:
Dado que los diferentes generadores utilizan diferentes tecnologías para solucionar el acceso
a la base de datos. Analicemos esto, para cada uno de los generadores.

C/SQL
En el caso de C/SQL se utiliza CGI para los programas que devuelven la
información requerida de la base de datos.

.NET
Los objetos web generados con .Net son .dll’s que son invocados con extensión
.aspx. La tecnología utilizada en este caso se denomina ASP.NET.

VISUAL BASIC
Los objetos web generados con Visual Basic, utilizan la tecnología denominada
WebClasses Designer. Estos objetos son programados en Visual Basic y al
compilarlos se crea un ActiveX DLL que será ejecutado por el Web Server y un
archivo ASP que sirve como punto de entrada para cada clase en la DLL.JAVA

Si se generan objetos web con JAVA, se utilizan servlets para acceder a la

información. Una de las grandes ventajas que presenta esta tecnología es que
permiten mantener conexiones abiertas, como también compartir conexiones a la
base de datos.

Mas adelante veremos en mas detalle cada uno de los generadores.

EDITOR HTML DE OBJETOS WEB

Introducción
La finalidad de este editor es potenciar y simplificar la edición del form HTML de los objetos
web, permitiendo crear fácilmente sitios web vistosos y potentes. Este editor es del tipo
"WYSIWYG" (What you see is what you get) lo que permite al desarrollador visualizar en
diseño la página web que se va a publicar. Para esto se licenció un editor similar al Front Page
de Microsoft, que fue diseñado siguiendo el estándar de las herramientas Microsoft Office, lo
que permite que los usuarios puedan utilizarlo rápidamente y en forma intuitiva.

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

Complementando este editor, existe el Editor de Temas, que permite definir clases para los
controles usados en una aplicación web GeneXus y configurar de una forma sencilla las
propiedades de estos controles simplificando el desarrollo y mantenimiento de las aplicaciones
web.

Descripción del Editor HTML

El uso de este editor es muy sencillo, de forma que todo el diseño realizado se puede visualizar
en ejecución sin necesidad de incluir código HTML en el Form. A modo de ejemplo, si se desea
modificar el tamaño de la font utilizada en el objeto web, simplemente se selecciona el texto y
se cambia al tamaño deseado.

El editor facilita el formateo de textos (tamaño de letra, tipo de letra, color, etc.), y permite la
inserción de controles GeneXus (Controles edit, grid, botones, etc.).

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

Diseño de Objetos Web

A continuación se documentan las características más importantes para el diseño de objetos
web. Para trabajar con objetos web se dispone de dos barras de herramientas, una habilita las
funcionalidades del editor, mientras que la otra permite la inserción de los controles. A
continuación se documentan las operaciones que se pueden realizar con cada una de ellas, así
como las características de los controles disponibles en objetos web.

Insertar controles y sus propiedades

Los controles que se pueden utilizar dentro de los objetos Web podemos clasificarlos en dos
grupos:

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

 Atributos
 Variables
 Botones

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

 Imagenes
 Grilla
 Texto
 Text Block
 Tabla
 Grilla Free Style
 Error viewer
 Web Components
 Embedded Pages

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

Más adelante se detallan los controles disponibles, así como las opciones disponibles en esta
barra de herramientas.

Formateo de texto
La barra de herramientas disponible para realizar estas operaciones es la siguiente:
Las operaciones que se pueden realizar son las estándares de edición y formateo de texto.

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

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

Design VS. Source

En el borde inferior de la pantalla cuando se visualiza el form de un objeto web, se pueden
observar varias secciones, entre ellas ‘Web Form’. Al hacer clic sobre esta sección se puede
diseñar la pantalla del objeto web, es decir se insertan los controles y se visualiza el aspecto
que va a tener en ejecución el mismo.

Si se presiona el botón derecho del mouse dentro del formulario del objeto web, además de la
opción Properties (que permite configurar las propiedades del form) se visualizan dos
opciones: ‘View Source’ y ‘Edit HTML Source’. Al seleccionar la opción ‘View Source’ se abre
una ventana donde se puede visualizar el código HTML que se va a generar al ejecutar dicho
objeto. Al cerrarla, se vuelve al formulario del objeto web.

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

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

CONTROLES Y SUS PROPIEDADES

En este capítulo iremos viendo los diferentes controles de los objetos web y las propiedades de
cada uno de ellos.
Es importante resaltar que la asignación de las propiedades puede hacerse directamente en el
control o en una clase de un Tema.

En ambos casos, se asigna el valor a la misma, pero lo que varía es el costo de mantenimiento
posterior que implicarán cambios a las mismas.

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

mismo.

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

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

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

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

Por detalles de la forma de configurar las propiedades de los controles, referirse a:

Orden de precedencia de las propiedades

CREACION DEL MODELO DE PROTOTIPO

Vamos entonces a crear el modelo de prototipo para poder ejecutar nuestra
aplicación. Como ya vimos antes, los generadores disponibles para generar
objetos web son: C/SQL, Java, .Net y Visual Basic.

Como primer paso, deben crearse la Base de Conocimiento (en GeneXus 8.0 o una
versión superior) y consolidar el archivo initial.xpz el cual contiene todas las
transacciones y procedimientos de los cuales partimos.

El generador que vamos a utilizar en el curso es .Net con SQL Server como DBMS,
pero ud. puede elegir el generador que desee y disponga. Les recordamos leer en
el Capítulo 15 ”Requerimientos y configuraciones necesarias por generador” para
conocer los detalles correspondientes al generador que ud. haya elegido, antes
de crear el modelo de prototipo.

Vamos a crear entonces el modelo de prototipo...

CREACION DEL PRIMER WEB PANEL

Vamos entonces a crear nuestro primer web panel, para ver cómo es el editor HTML
y cuál es la forma de trabajar en él.

A lo largo del curso vamos a ir desarrollando una aplicación web, un Sitio de ventas de películas
en sus diferentes formas (videos, DVD, etc.) del cual se tienen ya definidas las estructuras de
las transacciones y procedimientos necesarios y nos concentraremos únicamente en el
desarrollo de los objetos web.

Las Transacciones que ya se tienen definidas son las siguientes:

MoviesType
MovieTypeId*
MovieTypeDsc Tipo de película (Video, DVD)

Actors
ActId*
ActLastName
ActName

Customer

CustId*
CustName
CustLastName
CustUsr
CustPsw
CustEmail
CustNews Si desea suscribirse a la lista de noticias del sitio (Y/N)

MovieGenre

MovGenId*
MovGenDesc
(MovieId*
MovieTitle)
Movies
MovieId*

MovieImg Path de la imagen de la película

MovieTitle

MovieSumry

MovieStck Cuantas películas hay en stock

MovieQtity Cantidad de películas vendidas

(MovieTypeId*

MovieTypeDsc

(MovieLinDate*

MovieLinPrc))

(ActId*

ActLastName

ActName)

Purchase Order
PurOrdId*

PurOrdSts (Status de la orden – Pendiente, Finalizada)

CustId

CustNameCustLastName

PurOrdDate
PurOrdTot= SUM(PurOrdLinTot)  fórmula

PurOrdLastLin

(PurOrdLinId*
MovieId

MovieTitle

MovieTypeId

MovieTypeDsc

PurOrdQtity
 PurOrdLinUnPrc = udp(PUnitaryPrice, MovieId, MovieTypeId)  fórmula

PurOrdLinTot = PurOrdQtity * PurOrdLinUnPrc  fórmula

La forma de trabajo que vamos a tener a lo largo del curso es ir mostrando

primero cómo definir cada objeto web de la aplicación, e inmediatamente después
de terminar de definirlo, Uds. deberán hacer lo mismo, siguiendo los pasos
indicados.

Comencemos por crear el web panel de "Venta de películas" (”SaleMovie”).

Lo primero que haremos es definir en el Web form la interfase para permitir el

ingreso de usuario y password.

Haga clic aquí para ver la demostración

Qué es un Tema?

A partir de GeneXus 8.0 se cuenta con un nuevo objeto para el diseño de aplicaciones web, los
“Temas”; y una herramienta para el mantenimiento del nuevo objeto, que es el Editor de
Temas.

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 (propiedad “Theme”), los controles de ese objeto
podrán ser asociados a alguna clase del Tema correspondiente.

Cuando un control es asociado a una clase éste pasa a heredar la configuración de las
propiedades dada en la clase.

El siguiente documento, describe las características esenciales del Editor de Temas:

Generalidades del Editor de Temas.

Los objetos a los que se les puede asignar un Tema son Web Panels y Web Transactions.

Los Temas se asocian a un objeto GeneXus de la siguiente forma:

  Al objeto directamente, mediante “Object Properties -> Theme”. “Propiedad
Theme”.
 Al modelo, configurando la propiedad “Theme” (File -> Edit Model ->
Properties).
 A la base de conocimiento (File -> Edit Model -> Properties -> Theme, en
diseño)

El valor default de la property “Theme” del modelo es el valor de la misma property de la KB, y
el valor default de la property “Theme” de un objeto es el valor de la property “Theme” del
modelo.

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

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

Observe lo dicho anteriormente, en el web panel creado.

La forma de asociar una Clase de un Tema a un control, es a través de la propiedad “Class”. La

propiedad Class es una propiedad del control, y es posible también cambiarla en runtime.

Vamos a modificar el Tema “Default”, de forma de ejemplificar como se trabaja con los Temas.

Haremos las siguientes modificaciones:

► Darle un valor a la propiedad BackColor y ForeColor de la clase Attribute.

► A la clase Button, le asignaremos un BackColor y un Height.

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

Es posible también definir la configuración de los HTML Tags involucrados en el HTML de la

Web page. En el curso, a medida que se vayan realizando los ejercicios prácticos, se explicarán
más detalles del objeto Tema y su funcionalidad, incluyendo casos de uso de los HTML Tags, y
las ventajas que presenta a la hora de realizar el diseño estético del sitio web.Form
HTML
Al form de los objetos web se le pueden asignar propiedades haciendo clic y seleccionando la
opción Properties del menú.

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

control.

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

en

tiempo de diseño y algunas de ellas pueden modificarse en tiempo de ejecución (programando

los eventos del objeto).

Propiedades del form HTML en diseño

Las propiedades para el form son las siguientes:
 1. Class: La propiedad Class solo se encuentra disponible si el form pertenece a un
objeto que tiene un Tema asociado.
2. BackColor
3. TextColor
4. Background
5. Background Properties
6. TooltipText
7. Word Wrap
Propiedades para el color de los Links:

8. Active Link Color

9. Visited Link Color
10. Not Visited Link Color
Propiedades para los márgenes

11. Top Margin

12. Bottom Margin
13. Left Margin
14. Right Margin

Propiedades del form HTML en tiempo de ejecución

En ejecución se pueden modificar las siguientes propiedades del Form:
 1. BackColor
2. Background
3. Caption: El caption del form se transforma en el título de la ventana.
Por defecto, tiene el nombre del web panel. Esta propiedad solamente
puede modificarse en tiempo de ejecución.

Propiedades del Form en los Temas

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

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

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

Atributos y Variables
Al seleccionar un control y presionar el botón derecho del mouse aparecen las propiedades
para ser editadas.

Para modificar las propiedades de estos controles en ejecución (es decir en algún evento del
objeto), es necesario programarlo (ejemplo: &pwd.IsPassword = 1)

Recuerde que muchas de estas propiedades pueden asignarse en el objeto Tema en la clase
Attribute.

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

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

Propiedades del control Edit en diseño

Las variables y atributos son controles de tipo Edit, que tienen las siguientes propiedades:
 1. Attribute
2. Class La propiedad Class solo se encuentra disponible en las propiedades del control
si el objeto tiene un tema asociado.
3. Control Type: Las propiedades que se aplican sobre atributos y variables , dependen
del tipo de control que se seleccione. (Ver propiedades según el tipo de control).
Dentro del grupo Appearance se encuentran todas las propiedades que aplican al
aspecto del control. Se detallan a continuación:

4. Read Only
5. 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.
6. Fill
7. BackColor
8. ForeColor
9. Font
10. Format
11. ReturnOnClick
12. OnClickEvent

Propiedades del Control Edit en Tiempo de Ejecución

Además de las propiedades vistas anteriormente, existen otras que permiten modificar en
tiempo de ejecución los controles de tipo edit. Las propiedades son:
 1. Backcolor
2. BackStyle
3. Enabled
4. FontBold
5. FontItalic
6. FontName
7. FontSize
8. FontStrikethru
9. FontUnderline
10. ForeColor
11. Format
12. InternalName
13. IsPassword
14. Link
15. LinkTarget
16. Visible
17. Class

PROPIEDADES SEGÚN EL TIPO DE CONTROL

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

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

1. Attribute
2. BackColor
3. ForeColor
4. Fill
5. Font
6. Read Only

Las propiedades a nivel de ejecución son:

1. Backcolor
2. BackStyle
3. Enabled
4. FontBold
5. FontItalic
6. FontName
7. FontSize
8. FontStrikethru
9. FontUnderline
10. ForeColor
11. InternalName
12. Visible

NOTA : Alineación de un combo/dyncombo en grillas. Siempre se alinea a

la izquierda independientemente del tipo de datos. Esto se hace así porque aun
cuando el combo sea sobre un atributo numérico los valores que se muestran
en el combo son de tipo carácter.
 RADIO BUTTON, CHECK BOX
Las propiedades a nivel de diseño que aplican son:

1. Attribute
2. BackColor
3. ForeColor
4. Fill
5. Font

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

Las propiedades a nivel de ejecución son:

1. Backcolor
2. BackStyle
3. Enabled
4. FontBold
5. FontItalic
6. FontName
7. FontSize
8. FontStrikethru
9. FontUnderline
10. ForeColor
11. InternalName
12. Visible

Propiedades de atributos/variables en el Tema

Las propiedades se pueden configurar también en el Tema. La clase predefinida

“Attribute” del Editor de Temas reúne las propiedades para todos los controles en
los cuales se puedan representar atributos/variables en el form, a saber:
 Edit
 Combo Box
 List Box
 Radio Button

Obviamente se pueden derivar clases de la clase predefinida “Attribute”, por mas

información referirse a “Clase Attribute”

Propiedades de variables de tipo bitmap en diseño

Las propiedades que se detallan a continuación aplican únicamente a variables de tipo bitmap.
 1. Class
2. Autoresize
3. Borderwidth
4. Alternate Text
5. Tooltiptext
6. HSpace
7. VSpace
8. ReturnOnClick
9. OnClickEvent

Propiedades variables bitmap en tiempo de ejecución

A las variables de tipo bitmap se le pueden modificar las siguientes propiedades
en tiempo de ejecución:

1. Alternate Text
2. Borderwidth
3. Class
4. Enabled
5. HSpace
6. InternalName
7. Link
8. LinkTarget
9. TooltipText
10. Visible
11. VSpace

NOTA:La propiedad Enabled de Runtime permite habilitar

(Enabled=1)/deshabilitar (Enabled=0) la ejecución del evento asociado a la
variable bitmap.
 Propiedades de variables bitmap en el Tema

Las propiedades de las variables bitmap (y controles imagen), se pueden

configurar en los Temas. Referirse a “Clase Image”

METODOS DE LOS CONTROLES EDIT

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

 AddItem
 Clear

Picture de los tipos de datos dates y datetimes

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

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

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

Botones

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

disponibles.

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

Propiedades de botones
Las propiedades de los controles de tipo Button que pueden modificarse en diseño son:
1. ControlName
2. Class
3. OnClickEvent
4. Caption
5. Font
6. ForeColor
7. BackColor
8. BorderWidth
9. BorderColor
 En ejecución se pueden modificar todas estas propiedades (excepto la control
name) del boton y además las siguientes:
1. Enabled
2. Internal Name

PROPIEDADES DE BOTONES EN TEMAS

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

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

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

Cómo asignar un evento a un botón

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

COMO EVITAR VISUALIZAR EL INGRESO DE

UNA PASSWORD
Una cosa que vamos a querer cuando un cliente digita su password, es que no se
visualice lo que escribe, es decir, que aparezcan asteriscos mientras la ingresa.
Para hacer esto, utilizamos la propiedad IsPassword asociada a las variables.

Si programamos

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.

Haremos los cambios correspondientes en el objeto “SaleMovie”.

Observe que como el objeto será utilizado como punto de entrada a nuestra
aplicación, lo definiremos como un objeto de tipo main.

Haga clic aquí para ver la demostración

IMAGENES
En el desarrollo de aplicaciones web al igual que cualquier tipo de aplicaciones, se distinguien
dos ambientes o fases muy diferentes: el de diseño y el de ejecución. Por ambiente de diseño,
nos referimos al ambiente utilizado por los usuarios GeneXus que desarrollan la aplicación
web; por ambiente de ejecución entendemos a la ejecución propiamente dicha de los objetos
web (normalmente realizada por los usuarios finales).

Identificar estos dos ambientes es muy importante al trabajar con imágenes ya que
determinará que las mismas sean ubicadas correctamente y no ocurran errores del estilo “File
not found”.

En el ambiente de diseño (mientras se trabaja con GeneXus editando los objetos web) las
imágenes se buscan en el camino indicado en cada imagen (Ej.: c:\modelo\imagenes\img.gif),
pero en ejecución es necesario referenciar el camino virtual donde se encuentran las mismas,
que normalmente es el Servidor Web -(Ej.: /imagenes/img.gif). Hay que recordar que el
servidor web tiene acceso únicamente a aquellos directorios definidos en el software de
administración del mismo.

Para solucionar esto, se dispone de una preferencia a nivel de diseño denominada ‘Base image
path’ .
Preferencia Base image path
En esta preferencia del modelo de diseño, se debe ingresar el camino absoluto
que se va a utilizar para referenciar las imágenes en tiempo de diseño, es decir
mientras se desarrollan los objetos web.

En el caso en que se tenga acceso al servidor Web que se usará para producción
final, este camino puede referenciarse como una URL o también como un path
absoluto (respecto al servidor de archivos).
Esta forma de trabajo, permite que las imágenes esten en un único directorio y
pueden ser accedidas tanto en tiempo de desarrollo como en producción.

Cuando no se tiene acceso al servidor Web que se usará para producción (que es
el caso mas común), se deberán tener las imágenes duplicadas para poder
accederlas en desarrollo y posteriormente en producción. En este caso, en la
preferencia se deberá referenciar el path absoluto al directorio que las contenga
en tiempo de diseño.

Por ejemplo, si el directorio raíz del servidor Web es c:\inetpub\wwwroot y para

las imágenes de la aplicación existe el subdirectorio images esta preferencia podrá
contener el valor c:\inetpub\wwwroot o la url http://myserver.com. (siempre que en
tiempo de desarrollo se tenga conexión al servidor Web). En cada una de las
imágenes se pondrá el camino /images seguido del nombre del archivo. Si se
coloca el camino images (sin el carácter barra) intentará ubicar el directorio en
forma relativa al directorio de la aplicación y no respecto a la raíz del servidor
web.

Continuando con el ejemplo, si tenemos:

En c:\inetpub\wwwroot la raíz del servidor web

En c:\myapp\extranet el directorio de la aplicación web

Si las imágenes se indican como /images/image.jpg significa que existe el

directorio c:\inetpub\wwwroot\images, por lo tanto en la preferencia se deberá
indicar el valor c:\inetpub\wwwroot.

Si las imágenes se indican como images/image.jpg significa que existe el

directorio c:\myapp\extranet\images, por lo tatno en la preferencia se deberá
indicar el valor
c:\myapp\extranet\images.

Luego en el objeto web, para insertar una imagen se debe seleccionar el botón de la barra
de controles disponibles, y en el diálogo para ingresar el origen de la imagen se debe
seleccionar la misma.

Observaciones:

 Si la imagen seleccionada está bajo el path ingresado en la preferencia

de diseño, en la propiedad Source queda el nombre de la imagen (ej:
/imagenes/img.gif). Dado que delante del nombre de la imagen queda
‘/’, en ejecución el servidor web va a buscar la imagen bajo el directorio
raíz del mismo.
 Si se desea ubicar la imagen bajo el mismo directorio donde está el
resto de los objetos web, se debe eliminar el ‘/’ de la propiedad Source.
  Una vez agregada una imagen al objeto web, se puede editar la
propiedad ‘Source’ de la misma e ingresar cualquier path.
 Si la imagen seleccionada no está bajo el path ingresado en la
preferencia ‘Base image path’ de diseño, la propiedad Source queda con
el path absoluto, por lo que la misma no va a ser desplegada al ejecutar
el objeto.
 Si se prefiere que las imágenes de la aplicación se ubiquen en forma relativa al
directorio de los web panels, en las imágenes se deberá referenciar el directorio
imagenes\imagen.gif es decir sin la barra al principio.

Como asignar un evento a una imagen

Existen dos formas de asignar un evento a una imagen: en diseño o en ejecución.

Asignación de evento en diseño

Para asignar el evento en diseño se puede utilizar la propiedad OnClickevent.

Esta propiedad permite asociar un evento de los objetos Web a una imagen. Tiene el mismo
funcionamiento que la propiedad de igual nombre para los botones. En particular, permite
asociar un evento estándar de GeneXus (como First, Next, Previous, Last, Enter, etc.) a una
imagen.

Esta propiedad OnClickEvent es usada principalmente en las Transacciones Web para poder
asociar imágenes a los eventos estándar: Previous, Next, etc. En Web Panels, sirve para asociar
el evento Enter a las imágenes.

Asignación de evento en ejecución

Otra forma de asignar un evento a una imagen, es agregar el evento click de la
misma con el código deseado. De la misma forma, es posible asociar a una
variable de tipo bitmap un evento .

Si la imagen tiene asociado un link, pierde el mismo al quedar asociada a un

evento.
 Como se mencionó anteriormente, para asociar eventos de usuario a una imagen
puede usarse la propiedad Onclickevent o el evento Click. Si una imagen tiene
evento Click y, a su vez, un valor en la propiedad Onclickevent, prevalece este último
(se ignora el evento Click).

Con formato: Numeración y viñetas
TRABAJAR CON IMAGENES
Volvamos a nuestro web panel de "Ingreso al sitio de ventas" (”SaleMovie”) y agreguémosle
dos imágenes, que formarán parte del diseño de nuestro sitio web.

Todas las imágenes necesarias para el diseño del sitio se encuentran en el archivo images.zip.
Para poder usarlas hay que descomprimirlas y almacenarlas en algún directorio del disco duro.
En nuestro ejemplo, descomprimimos las imágenes en el directorio images bajo el directorio
de la KB (c:\InternetApp), y las copiamos también al directorio ‘images’ bajo el directorio raíz
de nuestro servidor web.

Primero, tenemos que ir al modelo de diseño y setear la preferencia "Base Image Path" para
indicar dónde están ubicadas de forma tal de poder verlas mientras diseñamos. Como
discutimos anteriormente (ver Imágenes), existen diferentes alternativas para completar esta
opción, y en consecuencia también el lugar donde deben estar al momento de ejecutar el
objeto en el web.

Para insertar una imagen tenemos que posicionarnos en el lugar que queremos insertarla, y
seleccionar la opción Insert/Image o el item Image de la toolbar de Controls y escribir
solamente el nombre de la imagen a insertar donde dice "Picture Source" (es decir, que
cuando ingresamos las imágenes hacemos el seteo de la propiedad "Source" de la misma).

Haga clic aquí para ver la demostración

Propiedades de las imágenes

A continuación se detallan las propiedades disponibles para las imágenes en tiempo de diseño.
 1. ControlName
2. Class La propiedad Class solo se encuentra disponible si el control está en el form
de un objeto que tiene un Tema asociado.
3. Source
4. LowResSource
5. OnClickEvent
6. Height
7. Width
8. Borderwidth
9. AlternateText
10. TooltipText
11. HorizontalSpace
12. VerticalSpace
13. Align
14. UseMap
15. ReturnOnClick

Propiedades De Las Imágenes En Tiempo De Ejecución

Las propiedades de las imágenes que pueden modificarse en tiempo de ejecución son:

1. BorderWidth

2. TooltipText

3. AlternateText
4. InternalName
5. Bitmap
 6. Enabled: La propiedad Enabled de Runtime permite habilitar
(Enabled=1)/deshabilitar (Enabled=0) la ejecución del evento asociado a la
variable bitmap.
7. Link: Si se programa el evento Click de una imagen se ignora la propiedad
Link.
8. LinkTarget
9. Visible
10. Class

PROPIEDADES DE IMÁGENES EN LOS TEMAS

Además de estas propiedades, en la clase Image (o derivadas de ella) de un
Tema, se pueden setear otras propiedades que permiten definir otras
características a las imágenes. Ver Clase Image

LINK
Los links son una característica única del WWW que nos permite saltar o navegar entre páginas
web.

Cuando queremos poner un link, tenemos que especificar la URL de la página web a la cual
queremos acceder.

Las url’s pueden ser absolutas o relativas.

 Una url absoluta es una dirección completa que incluye el camino completo al
archivo.
Cuando se referencia un archivo (página) de alguien más,
normalmente se va a usar una url absoluta (por ej: www.yahoo.com)

 Una url’s relativa es una dirección relativa al archivo que la contiene. Si solamente
se referencia el nombre del archivo, se asume que estará en el mismo directorio que
la página que contiene el link.
En las urls relativas no debe indicarse el protocolo (http, ftp, etc.).
Es suficiente con el nombre del archivo.

El link puede estar asociado a una imágen o a un texto, de forma que

cuando el usuario hace clic sobre el mismo, se llama a otra página estática,
página dinámica o archivo multimedia.

Dentro de GENEXUS, el link puede ser utilizado como función o como comando. A
continuación se definen ambos casos de uso.

Función LINK
La función LINK permite “enlazar” un objeto web con otro objeto web o con una URL. Esta
función se puede asociar a la propiedad link de un control dentro de cualquier evento del
objeto web, teniendo como resultado que al hacer click sobre dicho control se realiza la
llamada al objeto web o URL referenciado en el link.

La sintaxis de la función link es:

link(Objeto/URL/Att:Atributo/&var, [par1], [par2],..., [parn])

el primer parámetro contiene el objeto web, o la URL a llamar y [par1]...[parn] son el conjunto
de parámetros a pasar a los mismos. El primer parámetro, tambien puede ser un atributo o
una variable con la url o el objeto a invocar.

NOTAS:

1. Solamente se puede asociar la función link a controles que sean Read Only.

2. El objeto debe ser seleccionado utilizando la opción Insert/Object o Ctrl+B.

Ej: &var.link = link(hLogin). Se considera como una url relativa.

3. Si se desea llamar a una URL, la URL debe ser ingresada entre ‘’ (comillas
simples/dobles). Se considera como una url absoluta.
Ej.: &var.link = link(‘http://www.artech.com.uy’).

4. Si se desea hacer un link, utilizando un atributo que contiene la url o el nombre del
objeto web correspondiente, se debe utilizar la siguiente sintaxis:

&var.link = link(att:AplLnk), siendo AplLnk un atributo de alguna tabla.

5. También se puede definir un link utilizando una variable que contiene la url o el
nombre del objeto web correspondiente con la siguiente sintaxis:

&var.link = link(&varurl), siendo &varurl la variable que contiene la URL.

6. El pasaje de parámetros es opcional.

 OBSERVACIONES
En el caso de utilizar un atributo o una variable dentro de la función link, el
armado de la URL depende del contenido del atributo o la variable:

 Si la variable contiene http, el link se corresponde con el contenido de la

misma.
Ej: &var/att=’http://www.artech.com.uy’, al posicionarse sobre el link,
se visualiza en la parte inferior del browser:
‘http://www.artech.com.uy’.
 Si se encuentra un ‘/’, simplemente concatena el nombre del servidor
(ej: http://servidor/...) al comienzo del contenido del atributo o la
variable.
Ej: &var/att=’/index.html’, al posicionarse sobre el link, se visualiza en
la parte inferior del browser: ‘http://servidor/index.html’
 Si no es ninguno de los casos mencionados anteriormente, se concatena
la URL actual, al comienzo del contenido del atributo o la variable.
Ej: &var/att=’index.html’, al posicionarse sobre el link, se visualiza en la
parte inferior del browser: ‘http://servidor/diractual/index.html’
 En caso de almacenar el nombre de un objeto GeneXus hay que
destacar que no se agrega ninguna extensión. Por lo cual esta
administración queda por parte del desarrollador.
Ej: &var/att=&PgmName, al posicionarse sobre el link, se visualiza en la
parte inferior del browser: ‘http://servidor/diractual/obj”, por lo tanto al
hacer clic sobre el link, el usuario va a recibir un mensaje que le indica
que no se pudo resolver la url.

Mailto
Una característica interesante del link es que se puede definir de forma tal que al hacer clic
sobre el mismo se abre una ventana para el envío de mail. Para poder hacerlo, simplemente se
debe concatenar una dirección de e-mail a la palabra mailto como se describe a continuación:

&mail = ‘mailto:’+trim(AttMail/&varmail)

&var.link = link(&mail)

siendo &mail una variable de tipo caracter y AttMail o &varmail el atributo o variable que
contienen la dirección e-mail.

Comando LINK
Ver Comandos/LINK.
CALL
Ver Comandos/CALL.

Como navegar entre objetos web

Para relacionar objetos web dentro de una aplicación, se dispone de los comandos call, link y la
función link.

A continuación se realiza una comparación para aclarar las diferencias entre los mismos.

Desde un objeto web se puede hacer CALL a:

 Objetos web
 Procedimientos

La función y el comando LINK puede hacer referencia a:

 Objetos web
 Páginas HTML estáticas

NOTAS:

1. La función link se dispara cuando el usuario hace click sobre el mismo.

2. El comando link, en cambio se ejecuta en forma automática cuando se
ejecuta el evento. A diferencia del call, el comando link permite redireccionar
a otros sitios web o páginas dentro de otros directorios del sitio donde se
está ejecutando el objeto web.
3. La única forma de llamar a un procedimiento es con un call.

PRIMERA EJECUCION DEL WEB PANEL

Una vez creada la base de datos, luego de especificar y generar todos los
programas ejecutemos nuestro primer web panel (habiéndolo compilado
previamente).

La pantalla de nuestro primer web panel en ejecución sería la siguiente:

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

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

En el próximo punto veremos cómo alinear los controles del web panel "Sale of
Movies" insertándolos dentro de una tabla.

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

Agregar tabla

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

Propiedades de las tablas

Las propiedades varían dependiendo de la selección realizada, es decir que las propiedades
disponibles para una celda tienen alguna variación con respecto a las disponibles para la tabla
o la fila. A continuación se documentan las propiedades a nivel de tabla, fila y celda.
Para editar las propiedades de una tabla se debe marcar la tabla (el puntero del mouse
cambiará al posicionarse en los bordes de la misma y en la barra de status se indicará el
nombre del control seleccionado) y presionar el botón derecho del mouse. Seleccionar la
opción Properties del menú pop-up que se despliega.

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

1. ControlName
2. Class
La propiedad Class solo se encuentra disponible si el control está en el form de
un objeto que tiene un Tema asociado.
3. Tooltiptext
4. Align
5. Background
6. Backcolor
7. BorderWidth: 0 indica que no tendrá borde en ejecución, pero podrá
verse en diseño usando el botón de la barra de herramientas. El
valor por defecto es 1.
8. BorderColor
 9. Cellpadding
10. Cellspacing
11. Height
12. Width
13. Rules

Propiedades de las filas de una tabla

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

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

1. Identifier
2. TooltipText
3. Align
4. Vertical Align
5. Backcolor
6. BorderColor
Propiedades de las celdas de una tabla
Las propiedades de una celda de una tabla son las que se muestran a continuación:

1. Identifier
2. Tooltiptext
3. Align
4. VerticalAlign
5. Background
6. Backcolor
7. Bordercolor
8. Height
9. Width
10. Colspan
11. Rowspan

PROPIEDADES DE TABLAS EN LOS TEMAS

Además de estas propiedades, en la clase Table (o derivadas de ella) de un Tema, se pueden
configurar otras propiedades que permiten definir otras características a las tablas. Ver Clase
Table
PROPIEDADES DE LAS TABLAS - APLICACION
PRACTICA
Comencemos por insertar en una tabla (de 3 filas x 2 columnas) el texto y la
variable correspondiente al Usuario, el texto y la variable correspondiente a la
Password y el botón “Login”, ya que como podemos observar en la imagen del
web panel “Sale of Movies” en ejecución, dichos controles no están perfectamente
alineados entre sí.

Haga clic aquí para ver demostración

Dado que ya vimos todas las propiedades de las tablas, celdas, filas y form,
vamos a utilizar alguna de ellas en este web panel.

Vamos entonces a tener que crearnos una tabla de 2 x 2 donde vamos a tener
que incluir dentro los controles que ya tenemos en el formulario y hacer los
siguientes seteos en las propiedades Colspan y Width:
Haga clic aquí para ver la demostración

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

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

Edición de control Text Block

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

Propiedades Text Block en diseño

Las propiedades de este tipo de control son:

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

3. Format: El valor por defecto para TextBlocks es Text (se puede cambiar
a través de la propiedad “Default HTML Format(Textblocks only)” del
modelo de diseño).
4. OnClickEvent
5. ReturnOnClick

Además el textblock se puede configurar usando la barra de formateo de texto

de GeneXus (seleccionando el textblock).

Propiedades Text Block en ejecución

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

1. Visible
2. Caption
3. Link
4. LinkTarget
5. Format
6. Class

PROPIEDADES DEL CONTROL TEXTBLOCK EN LOS TEMAS

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

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

Si no se inserta explícitamente en un lugar determinado del form, y se usa en el

código del web object la función Msg(), de todas formas aparece el mensaje (en la
esquina superior izquierda del form).

Propiedades del Error Viewer en diseño

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

1. ControlName
2. Class La propiedad Class solo se encuentra disponible si el control está en
el form de un objeto que tiene un Tema asociado.
3. Display Mode
4. ForeColor
5. Font
6. Fill
7. BackColor
Propiedades del Error Viewer en ejecución
Además de las propiedades detalladas anteriormente, se pueden modificar las
siguientes propiedades en tiempo de ejecución:

1. BackColor
2. DisplayMode
3. ForeColor
4. Class
PROPIEDADES DEL CONTROL ERROR VIEWER EN LOS TEMAS
Además de las propiedades mencionadas, en la clase Error Viewer de un Tema (o
alguna clase derivada de ella), se pueden setear otras propiedades para el control.
Ver Clase ErrorViewer

COMO DARLE UN MENSAJE AL USUARIO

En este momento ya tenemos implementada nuestra pantalla donde el cliente va
a ingresar su usuario y password. Tenemos que verificar en el evento “Login” si
existe en nuestra tabla de clientes un cliente con dicho usuario. Si existe, verificar
que la password ingresada sea correcta y en caso de no existir darle un mensaje
al cliente informándole que se debe registrar como nuevo usuario.

Esto normalmente en un work panel lo haríamos utilizando la función msg(), y se

abriría una nueva ventana con el mensaje. En los objetos web, si utilizamos la
función msg(), el mensaje se despliega usando el control Error Viewer.

Si el control error viewer no se coloca en una posición determinada del form, y se

usa la función msg(), el mensaje aparece en la esquina superior izquierda de la
pantalla, de lo contrario, aparece donde se colocó el control.

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

Otra forma de darle un mensaje al usuario en los objetos web, es utilizando un

control de tipo Text Block y modificando su caption en tiempo de ejecución. No
serviría incluir en la pantalla un control de tipo Texto ya que la diferencia entre
los controles de tipo Text Block con los Texto es que a los Text Block se les
pueden modificar las propiedades en tiempo de ejecución (como por ejemplo la
propiedad caption), mientras que a los controles de tipo Texto se le pueden
cambiar las propiedades solamente mientras estamos diseñando.

Volvamos entonces a nuestro ejemplo para hacer el control del usuario y password en el
evento ”Login” y agregar un Text Block en la pantalla para desplegarle al cliente el mensaje
que corresponda.

Haga clic aquí para ver la demostración

COMO ASOCIARLE UN LINK ESTATICO A UN
TEXTO
Veamos ahora entonces cómo haríamos para permitir que el cliente se pueda
registrar por primera vez.

Una forma es agregar en el web panel que estamos diseñando un botón en cuyo
evento se programa un CALL a otro objeto, donde el cliente va a poder ingresar
todos sus datos por primera vez (nombre, dirección de mail, usuario, password,
etc.).

Otra forma, es incluir en lugar de un botón, un LINK al objeto web de ingreso de usuarios (el
cual no hemos creado aún). Es decir, insertar en el formulario un Texto y asociarle al mismo un
Link Estático (con la opción Insert/Hyperlink o Ctrl K teniendo el texto marcado) que nos
permita acceder al objeto web de ingreso de datos del usuario. Esto lo podemos hacer con un
Texto ya que la propiedad que le queremos asociar al mismo es "estática", es decir, queremos
que el link haga siempre referencia al mismo objeto web. Es por esto, que podemos hacerlo
con un control de tipo Texto y no es necesario un Text Block.

Vamos a realizarlo con el LINK ESTATICO ya que con el botón es conocido por
todos cómo hacerlo. Tengamos en cuenta que cuando hagamos Insert/Hyperlink
nos va aparecer la siguiente imagen, donde tenemos que especificar la URL donde
se encuentra el objeto web que queremos invocar.

Dado que el objeto web que queremos invocar todavía no lo creamos, es que
vamos a tener que definir ya el nombre que le vamos a poner, en nuestro
ejemplo va a ser una transacción con form HTML que se denominará “Customer”.

Si definimos el link en forma absoluta, también vamos a tener que saber desde ya
el nombre del servidor web en el que van a estar todos los objetos web de la
aplicación. En nuestro caso, el nombre del servidor web va a ser localhost, y los
objetos web los vamos a tener bajo el directorio “web” del modelo. Es decir, que
la URL que tenemos que poner debe ser http://localhost/services/TCustomer.aspx
(“services” es el alias del directorio virtual donde se encuentran los ejecutables)

También podemos ingresar el link en forma relativa, simplemente marcando en la

opción Type el valor “(other)” e ingresando el path relativo.

Es importante destacar que al definir un link estático, es necesario incluir la

extensión del objeto web. Por lo tanto, si el mismo objeto fuese generado en otro
lenguaje, va a ser necesario editar el mismo y modificar el link.
Haga clic aquí para ver la demostración

Esta no es la única alternativa disponible para agregar el link a un objeto web,

existen otras posibilidades que son mas dinámicas que vamos a ver más adelante,
y que son mas adecuadas en este caso para mantener la portabilidad de la
aplicación.

Los links estáticos normalmente se utilizan para referenciar a páginas externas o

que utilizan otros protocolos.

INTRODUCCION AL CAPITULO 3
A lo largo de este capítulo profundizaremos sobre el funcionamiento de los web
panels.

Para una mejor comprensión del desarrollo de aplicaciones para Internet,

estaremos comparando los web panels con los work panels.
Esta comparación nos permitirá destacar las diferencias que existen al desarrollar
aplicaciones para este ambiente.

Por supuesto seguiremos avanzando sobre nuestra aplicación Sitio de ventas de

películas.

CREACION DEL SEGUNDO WEB PANEL

Lo que vamos a hacer a continuación es crear un web panel CustProfile, donde
vamos a colocar los datos del cliente (nombre, mail, usuario).

La siguiente demostración corresponde a la creación del web panel CustProfile.

Vamos a agregar la regla parm(CustId); de forma de que el web panel se
comporte como un work panel. Es decir que nos va a permitir desplegar los datos
del usuario.

Haga clic aquí para ver la demostración

En conclusión, recordemos que los web panels se comportan como work panels,
en el sentido de que si se colocan atributos en el form, la información desplegada
no puede ser modificada y si colocamos variables se puede ingresar información.
Para dar de alta en la base de datos, es necesario utilizar “procedimientos” (para
cambios batch) o invocar a “transacciones web” (en caso de querer actualizar la
base de datos en forma interactiva con el usuario).

ESQUEMA DE TRABAJO EN INTERNET

Es importante entender la diferencia del ambiente en el que se está trabajando: en Internet,
cuando el usuario accede a una página del servidor Web para visualizarla, el Browser baja la
página al cliente. Por lo tanto, no existe forma de detectar lo que realiza el usuario: el Servidor
Web volverá a tener el control cuando se dispare el evento ENTER o algún evento de usuario.
En ese momento se envía (o se somete) el resultado al servidor para continuar con su
procesamiento. Es por esta razón que es importante destacar el orden en que se disparan los
eventos y el momento en que las variables adquieren el valor ingresado por el usuario.

Orden de ejecución de los eventos

El orden de ejecución de los eventos en web panels se diferencia si es la primer llamada al
mismo o si se disparó algún evento de usuario.

PRIMERA EJECUCIÓN DE LOS WEB PANELS

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

1. Start
2. Refresh
3. Load
Luego de esto, cuando el usuario presione un botón (ya sea asociado al evento ENTER o a un
evento de usuario) que no llame a ningún otro web panel, se ejecutará nuevamente éste y el
orden de disparo de los eventos será diferente.

RESTO DE LAS EJECUCIONES DE LOS WEB PANELS

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

1. Start (nuevamente se dispara el evento Start)

2. Nueva lectura de las variables de la pantalla. Esto se realiza porque el usuario puede
haberlas modificado (por ejemplo las variables de la parte fija del web panel que
están involucradas en las conditions)
3. Código correspondiente al evento asociado al botón seleccionado.
4. Refresh
5. Load

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

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

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

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

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

Nota:

En HTML se puede especificar dos métodos distintos de someter el form. El método se

especifica dentro del elemento HTML “FORM”, usando el atributo “METHOD”, por ejemplo:

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

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

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

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

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

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

En GeneXus todos los eventos se resuelven con un POST y se ejecutan en el servidor web.

EJEMPLO ESQUEMA DE TRABAJO EN INTERNET

Aunque decimos que los web panels son similares a los work panels, hay una
diferencia fundamental entre ellos relacionada con el hecho que el objeto web una
vez que finaliza la ejecución, no queda en memoria. Como consecuencia, la forma
en que programamos este tipo de aplicaciones presenta algunas diferencias con
respecto a lo acostumbrado en ambientes no web.

Es por esta razón que es importante tener claro el orden de ejecución de los
eventos.

Ejemplifiquemos esto, programando nuestro sitio de ventas.

Supongamos que en el evento donde validamos el usuario y la contraseña (en el

web panel Sale of Movies), guardamos en una variable el código de usuario para
poder utilizarlo en otro evento. Esto nos permitiría, por ejemplo, llamar a un objeto
que permita visualizar los datos del usuario.

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

el usuario:

Event ‘Login’
For each
Where &CustUsr = CustUsr
If CustPsw = &CustPsw
&CustId= CustId
Message.Caption = ‘’Welcome to Movies.com’
Else
Message.Caption = ‘Invalid password, try again please’
Endif
When none
Message.Caption = ‘User name not found’
Endfor
Endevent

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

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

la variable.

Si agregásemos un botón o una imagen con un evento clic asociado, entonces el

código seria el siguiente:

Event profile.clic/profile
Call(HCustProfile,&CustId)
Endevent

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

Repasemos entonces lo que pasa en este segundo caso:

1. En la primer ejecución se disparan los eventos: Start, Refresh y Load y

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

Haga clic aquí para ver la demostración

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

Haga clic aquí para ver la ejecución

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

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

Haga clic aquí para ver la demostración

Haga clic aquí para ver la ejecución

Nota:
Conviene hacer en este punto del curso un Estilo de Web Panels (que llamaremos
“SaleMovie”), es decir un Web Panel con la propiedad Style Object habilitada, en el que
basaremos luego la definición de los nuevos objetos.

Para quienes conocen y utilizan los Styles habitualmente, es importante destacar que en el
caso de los web panels, los styles aplican solamente al momento de inicializar el objeto,
es decir los cambios que se hacen en el style luego de estar aplicado no se heredan.

Haga clic aquí para ver la demostración

COMPARACIÓN ENTRE WEB PANELS Y WORK

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

Tabla Base
La determinación de la tabla base de los Web panels es análoga a la determinación de los work
panels. La determinación de la tabla base puede encontrarse en el capítulo: ‘Múltiples Grids’.
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 la sección ‘Esquema de trabajo en Internet’, las variables adquieren los
valores ingresados por el usuario después de presionar algún botón en el web panel.

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

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

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

Gatillado de fórmulas stand alone

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

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

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

Reglas más importantes

En el objeto Work Panel, las reglas más importantes son las siguientes: ORDER, NOACCEPT,
SEARCH, HIDDEN y WORKFILE_LINES.

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

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

WORKFILE_LINES
Esta regla no aplica a los Web Panels. La forma de hacer esto es usando la
propiedad ROWS del grid.

Propiedades

En los Web Panels para resolver la visualización de grandes cantidades de registros se dispone
de la paginación automática del grid.

Comandos soportados por los objetos web

A continuación se detallan los comandos soportados por los objetos web.

CALL
El comando Call no presenta grandes diferencias con respecto al resto de los objetos GeneXus.
Es importante tener en cuenta que los objetos web ejecutan en el servidor y por consiguiente
no pueden realizar llamadas a programas que tengan salida en pantalla, ya que la ejecución de
dicha llamada cancelaría por time-out. En resumen, desde un objeto web, se puede llamar a
otro objeto web, a un procedimiento o reporte que no tengan salida en pantalla.

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

La sintaxis de este comando es la siguiente:

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

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

<parm1>...<parmn>: son los parámetros que recibe la URL.

El pasaje de parámetros es opcional.

Por ejemplo:

Event ENTER

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

Endevent

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

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

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

Este comando Return puede ser ejecutado en cualquier evento o subrutina del
Web Panel, salvo el evento Load y los métodos Load de subfiles. Tampoco puede
ser ejecutado en subrutinas llamadas directa o indirectamente por el evento Load
o métodos Load de subfiles. 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 la función SetCookie (Ver funciones estándar Setcookie, Getcookie) y

luego se ejecuta el comando Return el valor de la(s) cookie(s) se establece
correctamente
INTRODUCCION AL CAPITULO 4
Volvamos al web panel de "Sale of Movies”.

Se quiere que en este Web Panel (el cual es de acceso público) se muestre todo el
"Catálogo de películas", pudiendo filtrar por "género" y por "título", cargando 5
películas cada vez.

Se deberá programar la paginación a pedido cargando en una grilla de a 5

películas.

Para cada película, se quiere ver: la imagen de la misma, su título debajo.

El título a su vez, deberá de contener un link a otro web panel que muestre más
información de la película seleccionada y nos permita comprar dicha película en
sus diferentes formas (dvd, video, etc.).

Más adelante veremos cómo hacer esto, ya que por lo que se pide podemos notar
que esto no se puede hacer en una grilla estándar ya que queremos para cada
película de la grilla desplegar un control debajo del otro).

Se quiere también, desplegar la imagen y resumen de la "Película del Mes",

asumiendo que ésta es fija y es la de código 4 (si bien esta información podría
almacenarse en alguna tabla, lo que nos permitiría que la película del mes varíe) y
debajo de esta información se desea también mostrar los actores de dicha película
(desplegando el nombre y apellido de cada uno).

La pantalla que se desea obtener en ejecución es la siguiente:

Es decir, que se desea incluir todo lo mencionado anteriormente, en el área vacía
hasta el momento del web panel “Sale of Movies”.

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

DIFERENTES TIPOS DE GRILLA

En los objetos web, se dispone de más de un tipo de grilla:

 Grilla estándar
 Grilla Freestyle

Estas grillas, agregan potencia al diseño de aplicaciones web, permitiendo al desarrollador

mayor libertad a la hora del diseño.

GRIDS EN WEB PANELS

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

Los grids permiten trabajar con datos repetitivos en web panels y transacciones con form
HTML. Las columnas de los grids pueden ser atributos, variables (incluyendo las de tipo
bitmap).

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

A continuación se detalla la forma de trabajo con grids en web panels.

Cómo desplegar datos en un grid

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

Cómo aceptar datos en un grid

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

1. si dentro de un evento del Web Panel se está utilizando el comando For each line o
For each line in <grid>, todas las variables que están dentro del grid pasan a ser de
ingreso. Es posible indicar en este caso cuáles son las variables que no van a poder
ser modificadas, utilizando la regla noaccept() o modificando la propiedad Read Only
de la variable dentro del grid.
2. si dentro de la fila hay algún control con un evento clic asociado.

Cómo asociar eventos a una línea de un grid

Es posible asociar un evento a cualquier variable que pertenezca al grid.

Propiedades del Grid

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

 1. Control Name
2. Class La propiedad Class solo se encuentra disponible si el control está en el
form de un objeto que tiene un Tema asociado.
3. Auto Resize
4. Width
5. Heigth
6. LinesColor
7. LinesFont
8. TitleForeColor
9. TitleFont
10. BackColorStyle
11. BorderColor
12. Rows
13. AllowCollapsing
14. Collapsed
15. AllowSelection
16. SelectionColor
17. AllowHovering
18. HoveringColor

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

propiedades adicionales relacionadas con la configuración de las líneas del grid.
 Si BackColorStyle = Header

1. LinesBackColor
2. TitleBackColor

Si BackColorStyle = Report

1. LinesBackColor
2. LinesBackColorEven
3. TitleBackColor

Si BackColorStyle = Uniform

1. BackColor

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

El ancho de cada columna de un grid se especifica como un porcentaje del ancho total del
grid (que por defecto no se especifica, el browser lo calcula en función al contenido de todas
las celdas).

El ancho del grid NO se deduce como la suma de los anchos de las columnas, ya que si estos
se especifican en valores relativos (porcentajes), puede no corresponderse a lo deseado.

Las propiedades LinesColor, LinesFont, TitleForeColor y TitleFont:

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

Table
Los grids también tienen algunas propiedades configurables para las tablas Estas
propiedades son:
1. ToolTiptext
2. Align
3. Background
4. BorderWidth
5. Cellpadding
6. Cellspacing
7. Rules.
Propiedades modificables en ejecución
A continuación se detallan las propiedades que se pueden modificar a los grids en tiempo de
ejecución:

1. Visible: si la propiedad Visible tiene el valor 0, el grid completo

desaparece del formulario.
2. Backstyle
3. BackColor
4. BackColorEven
5. BackColorOdd
6. PageCount
7. RecordCount
8. Rows
9. Class

Propiedades de las columnas del grid

También es posible indicar propiedades particulares para las diferentes columnas que forman
el grid. Para esto, se debe seleccionar la opción Columns del menú que aparece al hacer clic
en el grid.

En ese diálogo, seleccionando Properties sobre una columna se despliega un diálogo, como el
siguiente:
 1. ControlName
2. Class La propiedad Class solo se encuentra disponible si el control está en el form de
un objeto que tiene un Tema asociado.
3. ControlType
4. ReadOnly
5. Autoresize
6. Font
7. ForeColor
8. Title
9. TitleFont
10. TitleForeColor
11. Format
12. Visible
13. ReturnOnClick

Propiedades de columnas en tiempo de ejecución

En tiempo de ejecución se pueden modificar las siguientes propiedades de las columnas de un
grid:

1. Backcolor
2. Backstyle
3. Enabled
4. FontBold
5. FontItalic
6. FontName
7. FontSize
8. FontStrikeThru
9. FontUnderline
10. ForeColor
11. Format
12. Title
13. TitleBackcolor
14. TitleBackstyle
15. TitleFontBold
16. TitleFontItalic
17. TitleFontName
18. TitleFontSize
19. TitleFontStrikeThru
20. TitleFontUnderline
21. TitleForeColor
22. TitleFormat
23. Visible
24. 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

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

Para insertar el grid Freestyle se debe utilizar el botón de la barra de controles disponibles.

El grid Freestyle es básicamente una tabla a la que se le pueden insertar los atributos /
variables, text blocks, imágenes, botones, web components, embedded pages, grids freestyle
y/o grids que se van a mostrar posteriormente en la pantalla. Este tipo de grid no posee títulos
para las columnas y además permite tener más de un tipo de control, atributo / variable en
una misma celda, proporcionando de esta forma mayor libertad de diseño. Cabe destacar que
el grid Freestyle posee las mismas propiedades mencionadas anteriormente para el grid
tradicional.

En este caso para poder visualizar las propiedades hay que seleccionar la tabla donde se
encuentran los atributos / variables.

El comportamiento de las variables dentro de un grid Freestyle es análogo al que presentan

dentro de un grid, por lo tanto también quedan de ingreso si existe un For each line o For each
line in <grid> dentro de algún evento, o si se asocia un evento a cualquier control de la fila.
Nuevamente este comportamiento puede modificarse, agregando la regla noaccept o
cambiando la propiedad Read Only.
Propiedades del grid Freestyle
Para visualizar las propiedades de un grid Freestyle, hay que seleccionar la tabla del grid,
presionar el botón derecho del mouse y seleccionar la opción ‘Properties’.

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

1. Control Name
2. Class La propiedad Class solo se encuentra disponible si el control está en el form de
un objeto que tiene un Tema asociado.
3. BackColorStyle
4. Rows
5. Columns
6. AllowCollapsing
7. Collapsed

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

propiedades adicionales relacionadas con la configuración de las líneas del grid.
 Si BackColorStyle = Report

4. LinesBackColor
5. LinesBackColorEven

Si BackColorStyle = Uniform

1. BackColor

Propiedades modificables en ejecución

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

1. Visible: Si la propiedad Visible tiene el valor 0, el grid free-style

desaparece del formulario En el caso de tener grids anidados, la
propiedad Visible aplicada al grid padre, aplica también a los grids
hijos.
 2. Backcolor
3. BackColorEven
4. BackColorOdd
5. Columns
6. PageCount
7. RecordCount
8. Rows
9. Class

PROPIEDADES DE FREESTYLEGRIDS 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

PAGINADO DE GRIDS EN WEB PANELS

Introducción
A partir de la versión GeneXus 7.5 se brinda al usuario una serie de métodos que habilitan el
paginado automático en grids y grids freestyle.

Alcance
Objetos: Web Panels

Generadores: C/SQL – VB – JAVA - .Net

Plataformas: Web

Descripción
El paginado de grids aplica a grids comunes y freestyle cuya propiedad ‘Rows’ tiene un valor
diferente de cero. Los grids pueden estar anidados.

Existen algunas diferencias relacionadas con la paginación cuando un grid tiene tabla base o
no.

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

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

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

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

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

PREVIOUSPAGE
El método PreviousPage lleva al usuario al conjunto anterior de registros.
Los valores devueltos por este método son los siguientes:

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

LASTPAGE
El método LastPage lleva al usuario al último conjunto de registros. Puede ser
utilizado únicamente si el grid tiene tabla base.
Los valores devueltos por este método son los siguientes:

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

GOTOPAGE
El método GotoPage(PageNumber) permite acceder en forma directa a un
determinado conjunto de registros. Puede ser utilizado únicamente si el grid
tiene tabla base.
Los valores devueltos por este método son los siguientes:

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

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

Grid con tabla base Grid sin tabla base

FirstPage  
NextPage  
PreviousPage  
LastPage  
GoToPage  
Propiedades
Cada grid dispone de las siguientes propiedades que son utilizadas en la paginación:

 RecordCount
 PageCount

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

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

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

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

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

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

1. Tener un buen filtrado de datos (de forma que no existan muchas páginas)
2. Evitar, cuando el costo sea alto, el uso de GotoPage( N) con valores altos de N, así
como el uso de LastPage.
3. También se recomienda salvar el valor de la propiedad RecordCount en una variable
ya que cada invocación de la propiedad implica un COUNT en la base de datos.

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

Event Start

&Count = MyGrid.RecordCount

If &Count > MyGrid.Rows

Pagina2.Visible = 1

EndIf

If &Count > MyGrid.Rows * 2

Pagina3.Visible = 1

EndIf

Endevent

Event Siguiente.Click

MyGrid.NextPage()

Endevent

Event Anterior.Click

MyGrid.PreviousPage()

Endevent
Event Enter

MyGrid.FirstPage()

Endevent

APLICACION PRACTICA

Paginación a pedido
Como ya mencionamos en la introducción de este capítulo, se quiere mostrar en el
web panel ”Sale of Movies” el "Catálogo de películas" programando la paginación a
pedido en la grilla de películas, cargando 5 películas a la vez y pudiendo filtrar por
género y por título.

Para hacer esto vamos a tener que crearnos dos variables en la parte fija del web
panel, donde el usuario va a indicar los filtros correspondientes (&genre y &title),
pudiendo en el caso de la variable &genre definirnos un dynamic combo box que
nos cargue los géneros existentes de la tabla de géneros, agregando una opción
(con el método additem) para poder ver las películas de “todos” los géneros. Es
decir, poner la siguiente sentencia en el evento start: &genre.additem(0,'All')

Haga clic aquí para ver la demostración

Dado que en la grilla de Películas queremos desplegar las películas filtradas por
género o simplemente desplegar todas las películas, una posibilidad es realizar la
carga en forma “manual” utilizando variables.
La ventaja de la carga manual (con respecto a usar tabla base) es que se puede
optimizar la consulta si el usuario no ingresa un género, recorriendo únicamente
la tabla Movies, evitando el join.

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

Es por este motivo que a esta grilla le asignaremos como nombre Movies y a la
otra (con los Actores de la película del mes) la llamaremos Actors.

Entonces la carga de las películas la tenemos que programar en el Event

Movies.load, haciendo el load de cada registro con el comando load.

Como se quieren cargar de a 5 películas, debemos modificar la propiedad Rows de

la grilla y asignarle 5 como valor.

Por otro lado, vamos a agregar dos imágenes en el formulario “Ver anteriores” y
“Ver siguientes” (prev.jpg y next.jpg respectivamente), programando su
comportamiento en el evento click de cada una.

Event next.click //código que se va a ejecutar cuando el usuario haga clic

sobre la imagen next.jpg
Movies.NextPage()
EndEvent

Para implementar la opción de “Ver Anteriores” (asociada a la imagen prev.jpg),

debemos programar el siguiente evento:

Event prev.click //código que se va a ejecutar cuando el usuario haga clic

sobre la imagen prev.jpg Movies.PreviousPage()

Endevent

Cuando “modifiquemos” los valores de las variables &genre y &title de la parte

fija, vamos a presionar el botón de Buscar (“Search”) queriendo que se carguen
las primeras 5 películas que cumplen con los nuevos valores de &genre y &title
Para esto, vamos a tener que programar en el evento asociado al botón de Buscar
lo siguiente:

Event 'Search'

Movies.FirstPage()

EndEvent

Haga clic aquí para ver la demostración

Veamos entonces como quedaron los eventos Refresh y Load de la grilla de

películas:

Event Movies.Refresh

EndEvent

Event Movies.Load
If null(&genre) // si no se filtra por género, se recorre la tabla de Movies

For each
Where MovieTitle >= &title when not null(&title)
&photo = loadbitmap(MovieImg) //cargamos la imagen de la
película
&MovieTitle = MovieTitle
load //cargamos la película
Endfor

Else // si se filtra también por género recorremos la tabla Gen_Movie

For each
where (MovGenId = &genre)
where MovieTitle >= &title when not null(&title)
&photo = loadbitmap(MovieImg)
&MovieTitle = MovieTitle
 load
Endfor

Endif
EndEvent

Notar que la condición de filtro por película se realiza con la cláusula WHEN para
indicar que la misma se toma en cuenta cuando la variable tenga un valor. En el
caso de tener un valor nulo, no se considera la condición por lo que se recorrerá
toda la tabla.

Si ejecutamos el web panel, podemos notar que los controles que están en la
columna 1 (imagen de Chaplin, link de Registrar nuevo usuario, Usuario, Password
y botón de Login) aparecen alineados verticalmente en el "centro" de la celda en
la que se encuentran, y como esa celda crece verticalmente según el tamaño de la
grilla de películas, puede ocurrir que en ciertas ocasiones no podamos ver a todos
esos controles (a menos que hagamos scroll vertical). Para cambiarle la alineación
a TOP, lo que tenemos que hacer es presionar el botón derecho del mouse
estando posicionado en la celda de dichos controles y seleccionar la opción de
"Top" en la propiedad "Vertical Align".

Haga clic aquí para ver la demostración

Haga clic aquí para ver la ejecución

MÚLTIPLES GRIDS EN WEB PANELS

Introducción
Poder diseñar Web Panels con más de un grid potencia el desarrollo de estos objetos, ya que
permite, entre otras cosas resolver en el mismo objeto accesos a diferentes tablas.

Descripción
El uso de varios grids en un web panel, implicaron un cambio en la forma de especificar en
GeneXus las reglas, los eventos y las condiciones asociados a los mismos.

A continuación se detallan los cambios de comportamiento y las formas de uso de las

entidades pertenecientes a estos objetos GeneXus.

Atributos.
No se permite referencias <Grid Control Name>.<Attribute>.
Esto implica que si un atributo se encuentra en más de un grid, los cambios de las propiedades
afectan a todos los grids en los que se encuentra.

Variables.
No se permite <Grid Control Name>.<Variable>.

Esto implica que no se recomienda tener la misma variable en mas de un grid ya que cuando la
misma variable está presente en más de un grid, los cambios de las propiedades afectan a
todos los grids en los que se encuentra.

Propiedades.
Las propiedades de los grids conservan la implementación y comportamiento actual ya que
siempre estuvieron asociadas al objeto.

Eventos.
Los eventos del grid conservan su comportamiento actual.

Los eventos Load y Refresh deben referenciar al grid usando la siguiente nomenclatura:

Event <Grid Control Name>.<Refresh | Load>

....

EndEvent

Si el objeto solo tiene un grid, no es necesario usar la nomenclatura nueva.

Comandos.
Los comandos que actúan específicamente sobre el grid cambian de forma de que, en caso de
haber más de un grid, se pueda determinar a cual grid se aplica, estos comandos son:

 For each line: Este comando debe incluir una referencia al grid de la siguiente forma:
For each line IN <Grid Control Name>
 Load: Dispara la carga del grid. La sintaxis continua siendo Load, pero debe incluirse
dentro del evento load asociado a dicho grid. Si el objeto solo tiene un grid, no es
 necesario usar la nomenclatura nueva.
Ejemplo

Event Grid1.Load

Load

Endevent

Reglas.
 Order: Quedan asociadas al grid. (Se puede editar dando clic con botón derecho
sobre el grid)
 Hidden: Los atributos / variables nombrados en esta regla son colocados como
“hidden” en cada uno de los grids. No se recomienda su uso, en contrapartida se
recomienda agregar el atributo / variable al grid y luego ocultarlo usando la
propiedad visible.
La razón para promover el uso de los atributos / variables con la propiedad Visible en
False en lugar de la regla hidden es que los atributos referenciados en las reglas hidden
están en TODOS los grids mientras que los otros sólo están para el grid en que fueron
definidos. Esto redunda en menos código HTML a enviar al Browser y, en
consecuencia, mejor performance

Precedencias
 Order: Si el conjunto de atributos de la regla se corresponde con los de algún grid y
este tiene un orden asignado explícitamente este último es el que se toma en
cuenta.
Conditions.
Las condiciones se pueden indicar por cada grid o en forma general para el objeto.

Si hay condiciones generales y particulares sobre los mismos atributos, se toman en cuenta
todas.

Determinación de la tabla base

Como los web panels permiten tener mas de un grid, es que hay una tabla base por cada grid.

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

 Están en el grid
 Están referenciados en las reglas Hidden y Order aplicadas al grid y en conditions
aplicadas al grid

Los atributos de la parte fija no participan en la determinación de la tabla base de ninguno de

los grids, pero deberán pertenecer a la tabla extendida de alguno de ellos. Si hay alguno que
no cumpla la condición da el warning:
”Attribute not instantiated”. Notar que es posible que algunos atributos de la parte fija estén
en una tabla extendida y otros en otras.

Tampoco participan los atributos que están en los Eventos (fuera de los grupos For each) como
ocurre en los work panels. Estos, deberán pertenecer a la tabla extendida de alguno de los
grids.

Carga.
La carga se realiza para cada grid de forma independiente, es decir, aún si los datos que se
muestran en ambos grids están relacionados, el especificador no relaciona las cargas.

La carga incluye el evento refresh, o sea que la secuencia de carga de un objeto con 2 grids es:

Evento refresh del grid 1

Evento Load grid 1

Evento refresh del grid 2

Evento Load grid 2

El orden en que se cargan los grids es como aparecen en el form: de arriba hacia abajo y de
izquierda a derecha.

Aplicacion practica

Multiples subfilesgrillas
Lo que nos quedaría por hacer en este web panel es desplegar la imagen y
resumen de la "Película del Mes" (que para simplificar la supusimos fija, la de
código 4), y una grilla subfile con los Actores de dicha película.

Recordemos cómo es que dijimos que queríamos que apareciera el formulario en

ejecución …
Lo primero que debemos hacer para poder mostrar la película del mes es agregar
una celda a la derecha de la celda donde desplegamos todas las películas. La
forma maás sencilla de hacerlo es seleccionar la opción ‘Split Cell’. Una vez
realizado este cambio es necesario modificar el valor de la propiedad ‘Colspan’ de
la celda superior a 3, ya que ahora la misma debe abarcar 3 celdas en lugar de 2.

Dado que ya sabemos que le película del mes es la de código 4, entonces

podemos cargar la imagen y resumen de la misma en el evento Start.
Por otro lado, vamos a tener que crear una grilla subfile FreeStyle (para no
ponerle título al mismo) con los actores de la película del mes, y vamos a tener
que realizar su carga en el evento actoresActores.load (siendo Aactores el Control
Name del grid FreeStyle).

Para que no se vean en ejecución los bordes donde se carga el resumen de la

Película del Mes (&moviesmrymresu), lo que hay que hacer es poner a la variable
&resumoviesmrym como ReadOnly.

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

Haga clic aquí para ver la demostración

Vamos entonces a crear el web panel "Detalles de

una película" (de nombre MovieDetails)…
Se quiere desplegar en la parte fija de este web panel la imagen, título y resumen
de la película recibida como parámetro, así como un grid con los actores (la
concatenación del apellido y nombre de cada actor separados por una coma) y
otro grid con el precio de la película (el de fecha máxima, ya que se guarda el
histórico de precios) para cada tipo de película (dvd, video, etc.), teniendo
también en dicho grid una variable donde permita al usuario seleccionar la
cantidad que desea comprar, para luego presionar un botón (“Add to cart”) para
generar una orden de compra con lo seleccionado en el grid.

Vamos a crear entonces un webpanel MovieDet (“Movie Details”), cuya pantalla es

como la siguiente:
Tenemos que desplegar en la parte fija de este web panel la imagen, título y
resumen de la película recibida como parámetro. Para desplegar el título y
resumen podemos poner directamente en el form los atributos correspondientes
(MovieTitle y MovieSumry); pero para desplegar la imagen de la película tenemos
que definir en el form una variable en la cual debemos cargar la imagen
correspondiente.

Haga clic aquí para ver la demostración

El código de la película se recibe por parámetro, entonces, agregue la siguiente

regla al webpanel:

Parm(MovieId);

Dado que el código de película lo recibimos por parámetro, cargaremos la imagen

de la película en el evento Start, como mostramos a continuación:

Event Start

For each MovieId

&photo =loadbitmap(MovieImg ) //cargamos la Imagen de la película recibida en

la regla parm

Endfor

EndEvent

Grid de actores

Es necesario desplegar un grid con los actores de la película recibida como

parámetro.

Vamos a desplegar en cada línea del grid, la concatenación del apellido y nombre
de cada actor separado por coma, para lo cual vamos a tener que realizar la carga
“manualmente”, esto es, en el evento Actors.load.

Haga clic aquí para ver como incluímos en el form el grid de Actores, y le
llamamos “Actors”.

Usted debe programar lo siguiente:

Event Actors.Load
For each MovieId //se recorre la tabla Movie_Act
&actorname = concat(ActLastName, ActName,', ') // &actorname es la
variable presente en el grid de actores.
actors.load()
Endfor
Endevent
Grid de precios
 Carga del grid

Recordemos las estructuras de algunas tablas:

Movies Movie_Type Movie_Prc Movie_Act MoviesType

MovieId* MovieId* MovieId* MovieId* MovieTypeId*
MovieImg MovieTypeId* MovieTypeId* ActId* MovieTypeDsc
MovieTitle MovieLinDate*
MovieSumry MovieLinPrc
MovieStck
MovieQtity

En el grid de precios vamos a tener que desplegar “para cada tipo de película” un único
registro con el precio (el de fecha máxima).

Recuerde que el MovieId se recibe como parámetro. Entonces recorremos la tabla Movie_Prc,
para obtener para cada tipo de película (MovieTypeId), el precio (MovieLinPrc) que se
corresponde con la fecha más reciente (MovieLinDate).

Es decir, que se va a hacer un corte de control por MovieTypeId en la tabla Movie_Prc, de

forma de desplegar los valores de MovieTypeDsc y MovieLinPrc para la fecha máxima.

En una variable el usuario indicará la cantidad que desea comprar (la vamos a implementar
con un combo box con los valores del 0 al 5, y la llamaremos Qty).

Observe que hay que tener disponible para cada línea del grid el valor del
MovieTypeId , ya que lo vamos a tener que pasar como parámetro al momento de
presionar el botón de “Add to cart” para generar la orden de compra
correspondiente.

Entonces, haremos la carga del grid en forma manual, incluyendo las siguientes
variables:

Variable Type
&Qty N(5)
&MovieTypeDsc Based on MovieTypeDsc
&MovieTypeId Based on MovieTypeId
&MovieLinPrc Based on MovieLinPrc

El controlname del grid de precios, será Prices.

Haga clic aquí para ver la demostración

Observar que cuando definamos mas adelante el for each line in Prices, la
variable &Qty y el resto de las variables del grid van a tener un accept implícito.
Cambiamos este comportamiento modificando la propiedad ReadOnly de las
variables que nos interesa que no sean editables. En el caso de la variable
&actorname del grid de actores (Actors), como no existe un for each line sobre
dicho grid, es que la variable &actorname tiene un noaccept implícito.

En el load del grid Prices programamos lo siguiente:

Event Prices.Load
for each MovieTypeId
defined by MovieLinPrc
&Movietypeid = MovieTypeId
&MovieTypeDsc = MovieTypeDsc
&flag = 0
for each (MovieLinDate)
if &flag = 0
&MovieLinPrc = MovieLinPrc
&flag = 1
endif
endfor
prices.Load()
endfor
EndEvent

 Recorrida del grid, lógica del Evento “Add to cart”

Se va a tener que recorrer el grid de precios para ver las cantidades que se
desean comprar para cada tipo de película y acceder a la tabla de órdenes para
ver si existe una orden para ese cliente que se encuentre en estado de
"Pendiente", y de ser así agregar esta compra a las líneas de la orden. En caso de
no existir una orden pendiente para ese cliente, se deberá dar de alta una orden
nueva (como "Pendiente") y las líneas que correspondan.

Una vez recorridas todas las líneas del grid se quiere llamar a una web transaction
(“Purchase Order”) que despliegue los datos de la orden generada hasta el
momento, donde se va a permitir eliminar o modificar los datos de las líneas de la
orden.

Event ‘Add to cart’

For each

Where CustId = &CustId and PurOrdSts = OrderStatus.Pending

&PurOrdId = PurOrdId

Endfor
For each line in Prices se recorre el grid de precios, donde se indicó la cantidad que se
desea comprar
if not null(&Qty)

If null(&PurOrdId)
 &PurOrdId = udp(PAddHead, &CustId)

endif
call(PAddLine,&PurOrdId ,MovieId, &MovieTypeId,&Qty)
endif
Endfor
call(TPurchaseOrder,&PurOrdId)  muestra la orden de compra generada hasta el
momento

EndEvent

Nota Importante

1. En el evento asociado al botón “Add to cart”, se deberá controlar que el usuario

ya se haya logueado al sistema y sólo en caso de ser un usuario válido es que se
le va a permitir hacer compras. Esto lo veremos más adelante, en el capítulo
correspondiente a "Seguridad" (capítulo 8).

Observe que en ese evento se usa el CustId, para armar la orden de compra. Por
el momento (hasta que no veamos el capítulo de Seguridad), asumiremos que el
usuario ingresa su usuario, contraseña y presiona el botón de LOGIN
“inmediatamente antes de” presionar el botón de “Add to cart”. De esta forma
obtenemos en el evento correspondiente al botón de LOGIN, en la variable
&CustId, el CustId del cliente logueado, para luego poder usuarlo en el evento
correspondiente al botón de “Add to cart”. Como vimos en capítulos anteriores, es
necesario en este caso tener la variable &CustId en el form. Revise lo visto en
“Ejemplo: Esquema de trabajo en Internet”

2. En el web panel Sale of Movies, en el grid donde cargamos las películas

tenemos que agregar un link en el título de cada película al web panel que
acabamos de crear. Cuando programamos la carga de dicho grid en el evento
movies,Load debemos incluir el link de la siguiente manera dentro de cada uno de
los for each:

&MovieTitle.Link = link(HMovieDet, MovieId)

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

Los grids anidados consisten en un grid Freestyle al que se puede insertar dentro de una celda
otro grid estándar u otro Freestyle.
Por ejemplo, se quiere tener un web panel que muestre los productos, pero indentados por
categoría:

Electrodomésticos

Heladera

TV

Muebles de escritorio

Silla ejecutiva

Mesa de directorio

...

Para ello se define un grid free-style con la categoría y dentro de este se inserta otro grid con
los productos.

Puede haber grids anidados de varios niveles y puede haber también paralelos. Puede decirse
que se está definiendo un árbol en donde cada nodo es un grid.

Cada grid puede ser un free-style o un grid común, aunque si es común no puede tener
ninguno anidado.

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

Determinación de tablas bases

Cada grid tiene una tabla base independiente a la del resto de los grids del árbol de anidación.

Para relacionarlas, se deben incluir en los grids los atributos relación necesarios.
Generalizando el concepto, se deben incluir atributos que determinen específicamente la tabla
base deseada.

Como existen las propiedades Visible y Hidden, no tendrán porque visualizarse en el grid, pero
sí deben participar en la definición.
Siguiendo con el ejemplo anterior, el grid de Productos deberá tener el código de la categoría
para que los relacione.

Los grids deberán tener:

Sf1: CatDsc

Sf2: CatDsc PrdDsc

Disparo de Eventos
El manejo de eventos es análogo al del resto de los grids: se tienen los eventos refresh, load.

Cada vez que se ejecuta el comando Load en un grid con anidaciones, se llama al
evento Refresh y load de cada hijo. Cada grid puede o no tener tabla base (es
decir un for each implícito). Si no lo tiene, se deben cargar los datos con el
comando Load como en el resto de los grids sin tabla base.

Ejemplo de aplicacion de grids anidados

Una posible aplicación del uso de grids anidados en nuestro Sitio de Venta, es
disponer de un catálogo completo de películas clasificadas por su género.

Para eso creamos un web panel con el estilo del sitio, denominado ‘MovieCatalog’ y
agregamos un grid freestyle donde colocamos los atributos MovGenId, MovGenDesc
y dentro de este grid colocamos otro (también de tipo freestyle) con los atributos
MovieId, MovieTitle para desplegar la información de la película.
Como vimos anteriormente el grid puede ser estándar o Freestyle, en este caso
elegimos un grid Freestyle simplemente por el modo en que esta página va a ser
diseñada.

Haga clic aquí para ver la demostración

Si especificamos este Web Panel vamos a ver que el reporte de especificación

muestra por navegación de la tabla de géneros por un lado y de la tabla de
películas por otro. Para que se realice la anidación, debemos relacionar las cargas
de ambos grids. Esto podemos hacerlo, agregando en el grid interno el atributo
MovGenId. Ahora sí, en el reporte de especificación vemos que se navega la tabla
de géneros y por cada género, la que relaciona la película con el género.
Haga clic aquí para ver la demostración

Pero como no queremos que se despliegue un género que no tiene películas

asociadas (en nuestros datos de ejemplo el género “Children’s”), entonces
necesitamos un corte de control. Esto lo logramos forzando que ambas grillas
tengan la misma tabla base, la tabla relación Generos (MovieGenre) y Películas
(Movies). Para esto tenemos que agregar en la primer grilla el atributo MovieId. Así
obtenemos el corte de control. Dado que no queremos ordenar por la clave de la
tabla MovGenId, MovieId ya que no tiene ningún sentido, debemos agregar un
orden de recorrido que nos interese, en este caso la descripción del genero (*).
Para lograrlo, agregamos el atributo MovGenDesc en la opción Order de la primer
grilla. De esta forma logramos programar nuestro Catálogo de Películas clasificado
por género.

La manera de ocultar los atributos que no queremos que se vean dentro de los
freestyle grids, es poner lo siguiente en el evento start:
MovGenId.Visible = 0
MovieId.Visible = 0

(*)Nota: el atributo MovGenDesc no pertenece a la tabla de clave primaria

MovGenId, MovieId (que es la que se está recorriendo) por lo cual estamos
ordenando por un atributo de la tabla extendida. Esto NO es válido en ambientes
locales como Access, pero SI en ambientes Client/Server donde se puede ordenar
por atributos de la tabla extendida. En el caso de que ud. esté trabajando en un
ambiente local, debería hacer el corte de control por MovGenId que sí pertenece a
la tabla que se está recorriendo.

Haga clic aquí para ver la demostración

Para mejorar el diseño de nuestro catalogo, podemos agregarle las imágenes de las
películas y realizar algunas pequeñas modificaciones.

Haga clic aquí para ver la demostración

Haga clic aquí para ver la ejecución

Queda a cargo del lector, poner en el webpanel ‘Sale of movies’, un link al

webpanel recién creado (‘MovieCatalog’) de título “Complete list of recent releases”.

COMO TRABAJAR CON LOS "REGISTROS DE UN

GRID"
Vamos a implementar una libreta de direcciones para el cliente.

Primero vamos a definir la transacción “Direcciones

del Cliente” (Trn CustAddresses)
La estructura de la transacción es la siguiente:

CustId*
CustAddssId*
CustAddssDsc

Haga clic aquí para ver la demostración

Vamos entonces a crear el web panel “Trabajar con

direcciones" (de nombre CustAddresses)
En el formulario vamos a querer desplegar una lista de las direcciones que tiene
ingresadas el cliente.

¿Cómo implementar la "eliminación" de direcciones de la

libreta de direcciones?

Esto lo podemos resolver de tres formas.

1) Si queremos permitir selección múltiple, lo que tendríamos que hacer es

agregar una variable &dlt en el grid y definirla como check box. De esta forma, el
usuario seleccionaría el check box en las direcciones que desea eliminar. A su vez,
tendríamos que tener un botón "Delete" y en el código del evento asociado a
dicho botón deberíamos recorrer el grid (con el comando For each line) y para
cada línea seleccionada invocar a un procedimiento que haga la eliminación física
de dicha dirección (DelAddress). La creación del procedimiento DelAddress queda
por cuenta del lector.

Haga clic aquí para ver la demostración.

2) Agregar una imagen o botón en cada línea del grid, y en el evento asociado
llamar a otro objeto que permita realizar la modificación

En la siguiente demostración, modificamos el webpanel creado con la solución 1,

de forma de implementar la solución 2.

La siguiente pantalla es como se visualiza en ejecución la solución 2.

3) Otra alternativa es usar la propiedad AllowSelection del grid.

Haga clic aquí para ver la demostración (modificamos el webpanel CustAddresses

de manera de usar esta solución)

Note que también se configuraron las siguientes propiedades:

 AllowHovering
 AllowCollapsing

Modificaremos el webpanel de forma de que el grid y el botón queden alineados

verticalmente hacia arriba, dentro de la tabla que los contiene.

Haga clic aquí para ver la demostración.

Haga clic aquí para ver la ejecución.

En resumen, si lo implementamos permitiendo Selección Múltiple (opción nro. 1)

el usuario tendría que seleccionar los check box de cada una de las líneas que
desea eliminar y luego presionar el botón de "Delete".

Si lo implementamos como mencionamos en la opción 2 o 3, el usuario tiene que

hacer clic solamente en las líneas que desea eliminar, de a una.

¿Cómo implementar la "modificación" de las direcciones de la

libreta?

En el caso de querer modificar una dirección de la libreta, la forma de

implementarlo es similar a la solución 2 y 3 vistas anteriormente.

Es decir, se puede tener un control o variable en cada línea, al que se le asocie un

link a un webpanel para modificar la línea, o un link a la transacción de
direcciones pasándole llave primaria y modo.

Tambíen se puede implementar la solución 3, haciendo uso de la propiedad

“AllowSelection”, para llamar a un webpanel o procedimiento que modifique la
línea, dado que cuando el usuario selecciona una línea quedan instanciados los
datos de esa línea, de forma de llamar al objeto con los parámetros adecuados.

¿Por qué no se puede implementar esto de la forma mencionada en la

opción 1?

Porque de querer hacerlo así, en el código asociado al botón tendríamos que hacer
lo siguiente:

Event 'Update Addresses'

For each line //Selección múltiple para modificar las líneas de la orden
If &upd = 'S'
call( HModifyAddress, CustId ,CustAddssId )
Endif
Endfor
Endevent

Tenemos que recordar que cuando el usuario presione el botón de Modificar

direcciones, el código de dicho evento se ejecuta en el Servidor (para todas las
líneas), por lo cual cuando se devuelve el control al browser, nos va a cargar el
webpanel ModifyAddress , pero sólo para la última dirección.

Es por este motivo que la única forma de implementar esto como lo explicamos
anteriormente.

Queda a cargo del lector la implementación de ambas soluciones.

Recordar lo que se vió anteriormente (capítulo Grids):

En forma predeterminada todas las columnas de un grid son Read-Only (esto

aplica tanto a grids como a grids freestyle).

La forma de hacer que una variable dentro de un grid sea editable, para que el
usuario la pueda modificar es la siguiente:

 Tener un for each line en el evento asociado a algún control del form, ó
 un evento click asociado a algún control en las líneas del grid

Si se quiere que algunas variables sean editables y otras no, usar la Regla
noaccept() para aquellas variables que se quiere que sean readonly.

Nota:

El webpanel “CustAddresses” puede ser invocado desde el webpanel “CustProfile”;

queda a cargo del lector agregar en este último webpanel un botón o un link a
“CustAddresses” pasando como parámetro el CustId.

Por ejemplo, la siguiente es la imagen del webpanel “CustProfile” al cual le

agregamos el botón “My Addresses”:

Y el evento sería:
Event 'My Addresses'

call(HCustAddresses ,CustId)

EndEvent // 'My Addresses'

INTRODUCCION AL CAPITULO 5
En nuestra aplicación ventas de películas el área de login, se repite en gran parte de
los web panels que hemos diseñado. Hasta el momento, usábamos un style para
inicializar el objeto, pero como se mencionó anteriormente los styles en ambiente
web no tienen el dinamismo que tienen en ambiente win.

Lo que proponemos ahora son diferentes formas de componentizar una página,

para poder reutilizar otros objetos web y simplificar el diseño de la aplicación…

Los ‘Web Components’ son Web Objects que tienen una propiedad que indica que
son componentes. Es decir, pueden ser ejecutados en forma independiente como
cualquier otro Web Object o pueden formar parte de otro objeto web (Web Panel o
Web Transaction); por ende permiten a los diseñadores de aplicaciones Web GeneXus
un alto grado de reutilización de los mismos.

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

Algunos ejemplos: menús, login, área que permite la personalización, etc.

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

Definición de Web Components

Para definir un Web Object como Web Component se debe configurar la propiedad
‘Web Component’ del objeto en ‘YES’. Se debe notar que un Web Object definido
como Web Component no pierde ninguna de sus caracteristicas, por lo tanto,
puede ser ejecutado en forma autónoma.

Los Web Components se generan dentro del mismo HTML del Web Panel que los
contiene. Esto significa que el servidor resuelve la inclusión del Web Component en
tiempo de ejecución y devuelve al navegador el código HTML con el Web
Component ya incluido.
Uso de Web Components
Para insertar un Web Component en un Web Panel o Web Transaction se debe

elegir la opción Insert / Web Component, o la opción de la barra de controles,

con lo cual se creará un objeto de tipo ‘Web Component’ en el objeto.

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

Para determinar el objeto que se va a desplegar en lugar del control Web

Component, se utilizan las propiedades del mismo. El web object a desplegar se
puede fijar en diseño o en tiempo de ejecución, como se describe a continuación.

Propiedades
El objeto Web Component tiene las siguientes propiedades de diseño:

 ControlName: Nombre del control

 Object: Permite asociar un objeto web al web component. Sólo se aceptan
objetos con la propiedad Web Component en YES.
 Parameters: Permite especificar la lista de parámetros con los que se
invocará el web component.
PROPIEDADES MODIFICABLES EN EJECUCIÓN
A continuación se detallan las propiedades de los Web Components que se
pueden modificar en tiempo de ejecución:
 Object: permite determinar en tiempo de ejecución el Web Object que se
va a desplegar en el lugar del control. Para invocar el Web Component se
debe utilizar la siguiente sintaxis:

Control.Object = Create(Hxxx, [par1], ... [parn]

Siendo Control el nombre del control Web Component agregado al objeto,

Hxxx el Web Object que está configurado como Web Component
(Propiedad ‘Web Component’ con valor ‘Yes’) y par1 a parn los parámetros
que recibe dicho Web Object.

Visible: si la propiedad Visible tiene el valor 0, el Web Component

desaparece del formulario.

Web Components ‘dinámicos’

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

&variable = ‘HMenu’

Comp1.Object = Create(&variable)

Tanto si se invoca de forma dinámica como estática, en el programa generado la

invocación será estática. Es decir la invocación dinámica (create(&Var)) se genera
como:

Do Case

Case &Var=”Objeto1”

Create(Objeto1)

Case &Var=”Objeto2”

Create(Objeto2)

....

endcase

Esto implica que si se agrega un componente al modelo y el mismo será llamado de

forma dinámica, se deberán regenerar y compilar todos los “invocadores” de ese
nuevo componente. Esto, en .Net y Java no es estrictamente necesario; basta con
generar y compilar el componente mismo.

GeneXus determina automáticamente un dominio de objetos llamados en un create

dinámico. El dominio esta definido por los Web Objects que tienen la propiedad
WebComponent en YES y que tienen igual cantidad y tipo de parámetros que el
create. Estos objetos se verán además en el object browser como objetos llamados.
Por lo tanto, al compilar el web panel ‘padre’ C/SQL y VB compilan en forma
automática los posibles Web Components llamados.

Observaciones
 En diseño, el tamaño del Web Component permanece fijo, pero en
ejecución, el tamaño quedará sujeto al espacio ocupado por el mismo.
La forma de fijar el tamaño del Web Component en ejecución es
entonces incluyéndolo en una tabla y fijando el tamaño de la celda.
 Un Web Component puede a su vez contener otros Web Components.
 Los parámetros de los Web Objects cuando son utilizados como Web
Components no son opcionales. Notar que esto es una diferencia con
los Web Panels ‘comunes’ cuyos parámetros sí son opcionales.
 La asignación de un Web Component puede realizarse dentro de
cualquier evento del web panel ‘padre’.
 Si se asigna un Web Component en el evento Start del padre, los
parametros se pasarán solamente la primera vez que se crea. En
sucesivos POST, los parámetros se recordarán del render anterior.
Si se asigna un Web Component en cualquier otro evento (Refresh,
Load, de usuario, etc.), los parámetros se pasarán siempre que se
ejecute dicho evento.
 Si se asigna el web panel en la propiedad Object del control Web
Component en diseño, el pasaje de parámetros se realiza en forma
análoga a lo descrito en el punto anterior.
 Los controles y las variables de los Web Components no son accesibles
por los objetos que los contienen (objeto web ‘padre’). Si por ejemplo
se desea que un campo del Web Component tenga un color
determinado por el padre, se le tendrá que pasar por parámetro el
color y asignarlo en el evento Start del Web Component.
 En ejecución, las propiedades del form del Web Component son
heredadas del objeto web que lo contiene. Por ejemplo si el form de un
Web Component tiene color verde, pero el form del objeto web que lo
contiene tiene color blanco, entonces este último predominará sobre el
primero. No es así con las propiedades de los demás controles.
 No se soporta el uso de atributos como primer parámetro de la función
Create.
 En C/Sql y Visual Basic el .EXE o .ASP del main incluirá los fuentes de
todos los web components llamados por él. Esto es diferente en Java y
.Net, donde cada objeto tiene su propio .class o .dll. Esto no
necesariamente es un problema para Visual Basic o C (los servidores
tienen tecnología de “swapping” lo cual implica que no haya perdida de
performance por el tamaño del EXE o ASP).
TRANSACCIONES COMO WEB COMPONENTS

Introducción
A partir de la versión 8.0, no solo un Web Panel puede ser un Web Component, sino tambien
cualquier Transacción con interfaz web.

Alcance
Objetos: Transacciones

Lenguajes: .Net, C/SQL, Visual Basic, Java.

Interfaces: Web

Descripción
La posibilidad de definir una transacción como Web Component permite tener en un Web
Panel varios componentes, algunos conteniendo Transacciones (para altas, bajas y
modificaciones de datos) y otros conteniendo Web Panels que despliegan información
relacionada, menues, etc.

La definición y el uso de una transacción como Web Component es similar al caso de Web
Panels como Web Components

Por más información referirse al documento de Web Components.

Observaciones
Es posible tener varios web components con transacciones en un mismo web panel, pero se
deben tener en cuenta los siguientes puntos:

El estado de grabación no se mantiene por cada componente. Esto significa que si el usuario
ingresa a un componente y realiza una operación (por ejemplo modifica un atributo de la
transaccion y oprime el boton “Aplicar Cambios” por primera vez) y no reconfirma la misma, al
realizar una operación en otro componente (por ejemplo un GET), se pierden los cambios
realizados en el primero (es decir se refresca la página con el valor y estado que tenía antes de
modificar el atributo).

Ejemplos
Puede obtener un ejemplo en esta URL:

http://www.gxopen.com.uy/hproject.asp?122
EJECUCIÓN DE OBJETOS WEB CON WEB COMPONENTS
A continuación se describe la ejecución de objetos Web que contienen Web
Components.

Web Components en área plana del objeto Web

Orden de ejecución de los eventos

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

Primer llamada (GET)

El orden de ejecución de los eventos al realizar la primer llamada al mismo

(GET) es el siguiente:
 Evento START del objeto web que contiene el Web Component (objeto
Web ‘padre’),
 Evento REFRESH del objeto Web ‘padre’,
 Evento START de todos los Web Components dentro del objeto web que
no están dentro de subfiles,
 Eventos REFRESH y LOAD de cada uno de los Web Components y de los
subfiles en el orden que aparecen en pantalla (de arriba a abajo y de
izquierda a derecha).

Ejemplo:

En la siguiente figura, se puede observar un Web Panel que contiene 2 Web

Components (A y B) y un subfile. Cada Web Component tiene a su vez un
subfile.

A B

En este caso el orden de los eventos cuando se ejecuta por primera vez es el
siguiente:

1. Evento START del Web Panel

2. Evento REFRESH del Web Panel
3. Evento START del Web Component A
4. Evento START del Web Component B
5. Evento REFRESH del Web Component A y evento LOAD del subfile en
el Web Component A
6. Evento LOAD del subfile del Web Panel
 7. Evento REFRESH del Web Component B y evento LOAD del subfile 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 padre o en un Web Component. A continuación se analizan
ambos casos.

NOTA: La lectura de variables de cada objeto se realiza siempre

inmediatamente después del evento START de dicho objeto.

Disparo de un evento de un Web Component

 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 subfiles
en el orden que aparecen en pantalla.

En el ejemplo, si se dispara un evento del Web Component A, el orden de

los eventos sería el siguiente:

1. Evento START del Web Panel

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

Disparo de un evento en el objeto web padre

 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 subfiles en el
orden que aparecen en pantalla.

En el ejemplo, al dispararse un evento del Web Panel, el orden de los

eventos sería el siguiente:

1. Evento START del Web Panel

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

Nota: si el objeto web tiene más de un subfile, primero se ejecuta el REFRESH

independiente de los subfiles y luego el refresh de cada uno de los subfiles en el
orden en que aparecen en pantalla.

Web Components en subfile freestyle

Orden de ejecución de los eventos

En caso de haber Web Components en subfiles, 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
subfiles) se ejecutan cada vez que aparece el Web Component.

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

Components

A continuación se describen algunos puntos a considerar para el diseño de páginas

Web con GeneXus y Web Components para lograr una optimización del código
HTML generado:

USO DEL CREATE

Evitar el uso de CREATE y especificar, siempre que sea posible, el nombre del
Objeto Web Component en las propiedades del Control Web Component.

Cuando se utiliza CREATE (especificando un objeto o una variable) los

generadores tienen que incrementar el código HTML generado para saber cuál
fue el nombre del Objeto Web Component que se utilizó.

El incremento en el código HTML por utilizar CREATE es relativamente menor.

De todas formas, en páginas con muchos Web Components y/o con Web
Components dentro de grids, puede sumar varios KBytes más a la página.
 EVITAR EL USO DE CREATE CON UNA VARIABLE
En algunos generadores (VB, C/SQL, etc.) el CREATE con una variable es
transformado, por el especificador, en un DO CASE con CREATEs "fijos" (con
nombre de objeto) basándose en los parámetros especificados.

Resulta evidente que el DO CASE puede incluir CREATEs de Web Components

que nunca van a ser llamados (porque no son necesarios en la lógica del
programa) y entonces nos encontraríamos como en el punto anterior.

UTILIZAR TEXT BLOCKS EN LUGAR DE VARIABLES SIEMPRE QUE

SEA POSIBLE

Un Text Block tiene menos funcionalidad que una variable. Sin embargo, en la
medida en que la funcionalidad adicional no sea necesaria es recomendable
utilizar un Text Block en lugar de una variable ya que el código HTML generado
para un Text Block es normalmente menor (en algunos casos la mitad) que el
de una variable. Es importante notar que la cantidad de código HTML generado
depende del contenido de la variable o del valor de la propiedad Caption de un
Text Block.

Un ejemplo de esto es la inclusión de código HTML escrito por el usuario en las

páginas generadas. Es muy recomendable utilizar Text Blocks en este caso.

ELIMINAR ATRIBUTOS/VARIABLES QUE NO ESTÉN SIENDO

UTILIZADOS EN LA PANTALLA

Genera menos código HTML un atributo/variable que no esta en la pantalla que

uno que sí esta pero tiene la propiedad Visible en cero. Ninguno de los dos se
"ve" en la página generada.

Lo que vamos a hacer ahora es reemplazar el área de login en el web panel ‘Sale of
Movies’ por un web component.

Para poder hacerlo, lo primero que vamos a hacer es definir un nuevo web panel,
que llamaremos Login, e indicar que el mismo es un web component.

Haga clic aquí para ver la demostración

A continuación, vamos a agregar un control de tipo web component en el web panel
‘Sale of Movies’ en el lugar del área de login y vamos a indicar que se debe cargar el
web panel Login que acabamos de definir.

Haga clic aquí para ver la demostración

Nota:

Observe que lo más correcto sería incluír el textblock “My profile” en el

webcomponent “Login”. Hágalo como ejercicio, sin olvidar que es necesario
recuperar la variable &CustId en el evento “login” y colocar esa variable en el form
para que sea posible instanciar el Id del cliente cuando se llama al webpanel que
permite visualizar los datos del cliente (webpanel “CustProfile” creado en el capítulo
3).

EMBEDDED PAGES

Introducción
El objetivo de las ‘Embedded Pages’ es poder incluir información externa, es decir desplegar el
contenido de cualquier URL en objetos web generados por GeneXus.

Alcance
Objetos: Web Panels, Web Transactions

Lenguajes: C/SQL – Java – Visual Basic – .Net

Interfases: Web

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

Ventajas del uso de Embedded Pages

El uso de Embedded Pages brinda a los usuarios GeneXus la siguiente ventaja:
  Incluir información externa: permite que se incluyan páginas
estáticas o dinámicas de la propia aplicación o desarrolladas por
terceros. Dichas páginas pueden estar en el mismo servidor que la
aplicación o en otro servidor. Esta característica brinda gran
dinamismo a las aplicaciones web desarrolladas con GeneXus.

Generación de Embedded Pages

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

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

Uso de Embedded Pages

Para insertar una Embedded Page en un Web Panel o Web Transaction se debe seleccionar la
opción Insert / Embedded Page, con lo cual se creará un control de tipo ‘Embedded Page’ en el
mismo como se puede observar en la siguiente figura:
Tambien es posible insertarla con un solo clic en el ícono de la barra de controles.

Propiedades
El control ‘Embedded Page’ tiene las siguientes propiedades:
  ControlName: Nombre del control.
 BorderStyle
 Scrollbars
 Source
 TooltipText
 Height
 Width
 Align
PROPIEDADES MODIFICABLES EN EJECUCIÓN
A continuación se detallan las propiedades modificables en tiempo de
ejecución:
 BorderStyle
 TooltipText
 Source
 Visible
 Height
 Width
 HeightUnit
 WidthUnit

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

Netscape 6.0 o superior.

Observaciones
 Si en las propiedades del control no se especifica la propiedad
 Source, entonces en el evento START o REFRESH se debe
asignar algún valor a la misma. Por ejemplo EP.Source =
“http://www.genexus.com”, siendo EP el nombre del control
‘Embedded Page’.
 Se permite la asignación dinámica de URLs, es decir se permite
algo del estilo
&url = “http://www.genexus.com”
EP.Source = &url
 Se pueden incluir Embedded Pages dentro de subfilegrids freestyle.

Orden de los eventos

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

INTRODUCCION AL CAPITULO 6
A lo largo de este capítulo discutiremos como se comportan las transacciones que
se ejecutan en el web (transacciones con form HTML).

Para destacar el funcionamiento de las mismas, se describirán sus diferencias con

respecto al comportamiento de las transacciones en ambiente gráfico. De esta
forma podremos seguir avanzando sobre nuestra aplicación…

TRANSACCIONES WEB

Descripción
Las Transacciones Web no son un nuevo tipo de objeto GeneXus, sino un nuevo form para las
transacciones tradicionales que permiten su ejecución en navegadores.

La ventaja de estas transacciones es que facilitan la distribución de la aplicación, ya que sólo se

requiere un navegador instalado en el cliente.

También facilitan el diseño de aplicaciones Web porque permiten resolver el ingreso de datos
sin tener que definir Web Panels y Procedimientos para resolverlo, realizando
automáticamente todos los controles de integridad referencial necesarios.

Para diseñar este nuevo form Web, que será el que se visualizará en ambientes Internet se
utiliza el mismo editor HTML que en el diseño de Web Panels.
¿Cómo se define en GeneXus?
Para diseñar el form Web de una transacción, se debe abrir la transacción y
seleccionar la opción Object/Web Form del menú GeneXus.

Otra forma de editar el HTML form, es seleccionando el tab Web Form:

Inicialmente se crea un form donde se muestran los botones de movimiento, los atributos que
componen la transacción y sus descripciones y los botones para confirmar los datos.

Adicionalmente, se crea un botón a continuación del atributo clave. Este botón

tiene asociado el evento ‘Get’ y permite obtener la información correspondiente a
un registro cuando se ingresa un valor en el/los atributo/s clave.

También tiene un control denominado Error Viewer donde se despliegan los mensajes. Este
control podrá ubicarse en cualquier parte del form y se le podrán asignar propiedades (tipo de
letra, color, etc.).

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

Se muestra un ejemplo a continuación:

Consideraciones Generales
La principal diferencia de las Transacciones Web con las transacciones de las aplicaciones
tradicionales es el diálogo que emplean, lo que implica diferencias en la validación de los datos
y en el disparo de las reglas.

Las Transacciones Web tienen un diálogo a pantalla completa, semejante al que se provee en
el iSeries en pantallas de texto. La razón de este diseño es facilitar el uso en ambientes de
Internet donde un diálogo de tipo campo a campo como en los ambientes visuales (Visual
Basic, Visual FoxPro, etc.) resultaría inviable por performance.

Arbol de evaluación
Con este tipo de diálogo, las reglas se disparan en dos momentos: al ingresar a
la transacción (las que no tienen condiciones de disparo) y también al
confirmar los datos. Esto determina diferencias en el comportamiento de
aplicaciones que tienen diálogo campo a campo:

 No se valida campo a campo

 No se pueden disparar reglas entre un atributo y otro con reglas ‘after
attribute’. El ‘After(Attribute)’ se comporta como el ‘After (Level)’
 Los atributos de la tabla extendida se cargan al momento de confirmar
los datos y no antes. El usuario puede visualizarlos presionando el
botón ‘Check’.

ORDEN DE DISPARO DE LOS EVENTOS Y ARBOL DE EVALUACIÓN

Cuando se ejecuta por primera vez una transacción, el orden de disparo de
eventos y reglas es el siguiente:
 1. Evento Start
2. Reglas que no tienen condiciones de disparo

Al presionar el botón ‘Get’, el botón ‘Confirm’ o cualquier botón con un evento

de usuario asociado, el disparo de eventos y reglas es el siguiente:

1. Evento Start
2. Lectura de los atributos/variables de la pantalla
3. Reglas

REGLAS
La regla Default_mode no aplica en Transacciones Web.
La regla Default (Att,&today) se dispara únicamente la primera vez que se
ejecuta la Transacción Web, en su lugar se aconseja utilizar
default(Att,today()). Lo mismo ocurre con la variable &time y la función Time()
correspondiente.

Integridad transaccional
Por la forma de trabajo en Internet, las Transacciones Web “viven” solamente
el tiempo entre que el usuario de un navegador seleccionó el link o presionó un
botón y la nueva página es mostrada. Toda modificación a la base de datos que
se haga durante la “vida” debe ser confirmada o eliminada antes de que la
Transacción Web “muera” y retorne la página resultante.

Como consecuencia, una Transacción Web inicia una UTL (unidad de trabajo
lógica) al comenzar a ejecutar y la cierra (ya sea por COMMIT o ROLLBACK)
antes de terminar. No puede formar parte de otra UTL. Si un programa llama a
una Transacción Web, ésta iniciará otra (nueva) UTL.

Por todo esto, no aplica la propiedad ‘Commit on Exit’ en las Transacciones

Web.

Control de concurrencia
Las Transacciones Web utilizan el diálogo pseudo-conversacional. Esto implica
que, mientras el usuario esta realizando modificaciones a los datos o
simplemente viéndolos, no existe ningún tipo de locks en la base de datos.
El control de cambios (es decir la validación entre la lectura inicial y la
confirmación) se realiza a nivel de cada tabla involucrada en la Transacción
Web. Los valores leídos al momento de “enviar” los datos son comparados con
sus correspondientes, en cada tabla, en el momento de “recibir” las
modificaciones (cuando el usuario presiona Confirm). Si los valores no
coinciden, se informa al usuario que hubo cambios y que debe intentar
nuevamente.

Es importante notar que el control de cambios se realiza sobre todos los

atributos involucrados salvo aquellos de tipo Long VarChar por su tamaño.
Prompts
Para cada Transacción Web se genera un Web Panel que será el prompt por
defecto (autoprompt), y los prompts correspondientes a las claves foráneas
que se tengan. Para modificar el prompt llamado por defecto, se puede utilizar
la regla prompt.
También es posible definir web panels como prompt, por mas información
referirse a la sección “Web panels como prompt”

Transacciones Web sin Modo instanciado

Las transacciones Web pueden invocarse sin recibir el modo instanciado. Se detalla el
comportamiento de las mismas dependiendo de la acción: inserción, modificación o
eliminación de registros.

Modo Insert
Al ingresar a una Transacción Web de este tipo, se comienza en modo Insert, y se despliega
una pantalla con la siguiente forma:
Si se quiere ingresar un registro nuevo, se digitan los datos en la pantalla y se presiona el
botón ‘Apply Changes’. Esto provoca, en primera instancia, que se validen los datos ingresados
en forma similar a cuando se presiona el botón ‘Check’. En caso de que ya exista el registro va
a dar un mensaje de error que se despliega en el Error Viewer. El mensaje es ‘Record already
exists’.

Además, si no se trabaja con confirmación (propiedad Confirmation del objeto), se insertarán

los datos. Si se trabaja con confirmación, se desplegará el mensaje ‘Please confirm the data’. Al
presionar nuevamente el botón ‘Apply Changes’, se insertarán los datos.

Luego de actualizada la base de datos, se despliega el mensaje ‘Data has been successfuly
added’.

Modo Update
Para entrar en modo Update, se deberá poner un valor en la clave y presionar el botón ‘Get’ (
). Esto hace que se carguen los datos del registro.

Al cargar los datos también se traen las descripciones. Se pueden modificar los datos y
presionar el botón ‘Apply Changes’, y se actualizarán los datos con un procedimiento análogo
al que se sigue para el modo Insert.

Modo Delete
Para eliminar un registro primero se debe ingresar en modo ‘Update’ (ingresando la clave y
presionando el botón ‘Get’), y luego presionar el botón ‘Delete All’, lo que provoca que se
deshabilite dicho botón. En el caso de trabajar con confirmación, se desplegará el mensaje
‘Confirm deletion’
Al presionar el botón ‘Apply Changes’, se eliminarán los datos y de desplegará el mensaje ‘Data
has been successfuly deleted’:

En el caso de que no se trabaje con confirmación, al presionar el botón ‘Delete All’ se

eliminarán directamente los datos y se desplegará el mensaje ‘Data has been successfuly
deleted’, sin necesidad de presionar ‘Apply Changes’.

Al eliminarse un registro se cargan los datos correspondientes al registro anterior, quedando

en modo ‘Actualizar’. Si se borran todos los registros, la transacción queda en modo ‘Insert’.

Transacciones Web con Modo instanciado

Las Transacciones Web que se invocan instanciando el modo Insert, Update o Delete,
deshabilitan los botones de movimiento entre registros y los botones ‘Get’, ‘Select’ y ‘Delete
All’.
Modo Delete
Cuando se invoca una Transacción Web instanciando el modo Delete siempre se despliega el
mensaje ‘Confirm deletion’, sin importar si se esta trabajando con confirmación o no. Al
presionar el botón ‘Apply Changes’, se elimina el registro.

Ahora que ya vimos como funcionan las transacciones web, podemos definir la
transacción para registrar un nuevo usuario que es invocada en el link que
definimos en el Web Panel Sale of Movies.

Para hacerlo, tenemos que editar la transacción de Clientes (“Customer”) y en el

web form diseñarlo como se muestra a continuación:

Haga clic aquí para ver la demostración

La numeración del Cliente es realizada en forma automática, a partir de la

propiedad “Autonumber” que le asignaremos a la clave primaria de la tabla.

Haga clic aquí para ver la demostración

Agregaremos las siguientes reglas a la transacción:

Parm(&CustId,&Mode);

CustId=&CustId if update .OR. delete;

Además, debemos agregar una regla que evite que el código de Cliente sea
ingresado:

Noaccept(CustId);

El ingreso de todos los campos es “obligatorio”, por lo cual debemos agregar reglas
que hagan este control:

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

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

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

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

Error(‘Please specify a Password’) if null(CustPsw);

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

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

Accept(&PswConf);

Finalmente, se debe controlar que la contraseña concuerde con la confirmación

ingresada, para eso es necesario agregar:

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

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

&PswConf.IsPassword = 1

CustPsw.IsPassword = 1

EndEvent

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

Recuerde que la página principal del sitio ‘Sale of movies’ contiene un

webcomponent ‘Login’, que es el que tiene el link para registrar un nuevo usuario,
vamos a modificar ese mismo link.

Haga clic aquí para ver la demostración

Ahora si, veamos la ejecución de nuestra aplicación y registremos un nuevo

usuario…

Haga clic aquí para ver la ejecución

Transacciones Web de más de un nivel

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

 Número de niveles de una transacción

Las transacciones Web pueden tener un nivel anidado y pueden tener varios niveles paralelos.
El primer nivel debe respresentarse plano (sin grid) y el nivel subordinado necesariamente
debe tener un grid.

 Grid

 Eliminación de líneas

En diseño se utiliza una variable &GxRemove definida y agregada automáticamente a los

subfiles de la pantalla por defecto. Esta variable es un check box que se ubica en la primera
columna del grid.
Cuando se desea eliminar alguna línea del grid, se debe marcar la misma con el check box, y
presionar el botón de ‘Apply Changes’, no de ‘Delete All’. Este último eliminará toda la
transacción, no las líneas marcadas.

Nota: Es importante considerar nuevamente que cuando se está en una Transacción Web se
está modificando todo el “documento” y no se está en un nivel en particular de la misma. Por
eso para eliminar líneas se debe utilizar el botón ‘Apply Changes’ porque en realidad se está
actualizando el “documento”. Lo mismo para agregar líneas, se debe utilizar el botón ‘Apply
Changes’ porque se está actualizando el “documento”.

REGLA PROMPT ON

Introducción
Es posible definir el control que activa la llamada a un determinado prompt en objetos Web,
en lugar del bitmap utilizado por defecto.

Esto posibilita además la llamada desde Web Panels a prompts de GeneXus o de usuario.

Alcance
Objetos: Web Panels, Transactiones

Lenguajes: Java, C/Sql, Visual Basic, .Net

Interfaz: Web

Descripción
La regla PROMPT permite especificar (opcionalmente) el nombre del control que activa la
llamada a un determinado prompt.

La sintaxis pasa a ser la siguiente:

Prompt( <program>, [p1, ] ... pn) [on <control>];

En caso de omitirse on <control> se agregará (en los ambientes que corresponda) una imagen,
botón, etc. a la derecha del o los campo(s) que tienen prompt, como hasta ahora.

Cuando se especifica on <control> se utilizará el control referenciado. Los controles posibles

son aquellos que tengan la propiedad link (TextBlock, Imagen, etc).

Al utilizarse esta regla se mostraran en el diagrama de navegación los prompts utilizados.

Nota: Esta regla aplica únicamente a objetos que se especifiquen para interface Web, en caso
que se utilice en otros objetos, se ignora la nueva funcionalidad.

USO DE WEB PANELS EN REGLAS PROMPT

Introducción
En muchas circunstancias, en una transacción Web es necesario utilizar Web Panels de usuario
en lugar de las listas de selección generadas automáticamente por GENEXUS, mediante el uso
de la regla Prompt.

Alcance
Objetos: Transacciones

Lenguajes: C/SQL – JAVA - Visual Basic – .Net

Interface: Web

Descripción
Existen casos en los que un usuario requiere crear un Web Panel que luego quiere utilizar
como prompt para obtener valores de atributos.
Para invocar el Web Panel, simplemente se utiliza la regla prompt en una transacción web o
dentro de un web panel.

Al dispararse la regla prompt (haciendo click sobre un control) se abre una ventana con el Web
Panel y, al seleccionar un valor (nuevamente haciendo click) se cierra la ventana y el valor se
asigna a lo(s)/la(s) atributos/variables que corresponda.

Programación de un Web Panel como prompt

El web panel que será utilizado como prompt debe cumplir ciertas condiciones:

1. Debe tener uno o más parámetros de tipo output. Puede tener de in, de inout
también pero lo importante es que tenga de output que son los que devolverá.
2. Alguno de los atributos, variables, text blocks o imagenes del form debe tener la
propiedad de diseño ReturnOnClick en True. Puede tener habilitada esta propiedad
en más de un atributo/variable. En caso de ser un atributo o una variable, tiene que
estar Read Only para que la propiedad esté habilitada.
3. Los valores a retornar (de los parámetros definidos como de output) no se
determinan al realizar click, sino al desplegarse la pantalla por lo que tienen que
tener el valor válido a retornar en cada Load (si se muestra un grid, por ejemplo).

Si uno de los atributos variables, text blocks o imagenes del form que tienen la propiedad de
diseño ReturnOnClick en True también tiene programado el evento Click, el código que este en
el dicho evento se ignora. Simplemente al hacer click se asignan los valores a las variables de
tipo OUT y se retorna.

Uso avanzado
Esta funcionalidad puede no contemplar todos los casos. Por ello, también se implementó la
función ReturnOnClick() (sin parámetros) que puede ser asignada a la propiedad Link de
cualquier control (que tenga esta propiedad).

Ejemplos
Prompt de Clientes
Un prompt de clientes se programa así:

En las Reglas del web panel:

parm( out: &CliCod);

En los Eventos:

event Grid1.load

&CliCod = CliCod

endevent

En el form:

Un grid que tiene CliNom y CliCod, donde CliNom (por ejemplo) tiene la propiedad
ReturnOnClick en true.

TRANSACCION “ORDEN DE COMPRA”

Una vez que el cliente selecciona una película para comprarla, debe visualizar la
lista de películas que tiene seleccionadas hasta el momento. Es por esta razón,
que vamos a diseñar la transacción “Orden de Compra (Purchase Order)”.

Lo primero que vamos a hacer es abrir la transacción “Purchase Order” y vamos a

agregar una regla para recibir por parámetro el nro. de orden de compra.

Parm(PurOrdId);

Además, vamos a permitir que el cliente modifique su orden de compra, es decir,

que pueda agregar nuevas películas, o modificar la cantidad que ordenó. La
modificación de la cantidad de películas ordenadas es inmediata, simplemente
cambiando el valor ingresado en el atributo PurOrdQtity. Para poder agregar una
nueva película, vamos a tener que agregar un prompt en el grid sobre el atributo
MovieId, que invoque al web panel ‘Sale of movies’.

Haga clic aquí para ver la demostración

Además, tenemos que modificar el web panel ‘Sale of Movies’ para poder devolver
el código de la película elegida cuando el cliente haga clic sobre la imagen. Esto se
logra modificando la propiedad Returnonclick (valor “True”) de la imagen, y
poniendo como parámetro de salida el MovieId.

Haga clic aquí para ver la demostración

Se quiere dar al usuario la posibilidad de dar por finalizada la orden, para lo cual
agregaremos en la pantalla de la transacción un botón de "Confirm Order". En el
evento asociado, vamos a tener que cambiar el status de la orden a "Finalizada"
(invocando al procedimiento ProcofPurchOrder) y llevar en forma automática al
usuario al web panel principal del Sitio (‘Sale of movies’).
Haga clic aquí para ver la demostración

Observe en la ejecución de la transacción “Purchase Order”, como

automáticamente el campo fecha de la misma se despliega en forma de un
calendario popup:

Las atributos y variables de tipo Date y DateTime que se despliegan en el form de

los objetos web (transacciones HTML y webpanels) pueden tener opcionalmente
un calendario asociado. El calendario se despliega en forma de una ventana
popup, o “flat” en el form (esto es configurable). Por defecto, se usa un calendario
popup. Esta funcionalidad, facilita la visualización y la selección de una fecha y
hora. Por más información referirse a “Web control calendar: Datepicker”

INTRODUCCIÓN AL CAPÍTULO 7
Las aplicaciones Web necesitan un look & feel bastante más sofisticado que las aplicaciones
Winform y los desarrolladores no tenemos las habilidades y el tiempo para lograr un diseño
con esas características.

Por esa razón, por lo general se opta por contratar servicios de diseño. Por lo cual, es necesario
luego integrar ese diseño con la aplicación GeneXus. Esta integración se logra a través de los
“Themes”.

Para el diseño gráfico contamos con el “Editor de Themes”, una herramienta de libre
distribución que se puede ejecutar en forma independiente de GeneXus.

Mientras que en versiones anteriores las propiedades de los controles en los “html forms”
(Web Panels y forms html de las transacciones) debian ser configuradas en los controles,

hoy mediante los “Themes” se pueden definir “Clases” para los diferentes tipos de controles y
asignarles propiedades a esas Clases.

Luego, los controles se asocian a esas clases, y éstos heredarán las propiedades allí
configuradas. Por lo tanto ya no es necesario establecer los valores de las propiedades para
cada control en el form. Las propiedades de los controles se configuran en un único lugar: en
las clases del Theme.

Cualquier cambio de diseño que se requiera hacer, se realizará en el Theme (sin

necesidad de generar/compilar absolutamente nada), de esta forma se logra la
uniformidad estética del sitio con un bajo costo de mantenimiento (no es necesario
cambiar cada uno de los objetos), y como consecuencia se obtiene una mayor
productividad en el desarrollo de aplicaciones Web.

Recuerde que en el capítulo 2 se dió una introducción del objeto Theme e incluso se realizaron
algunos ejercicios para comprender su funcionamiento.

Veremos a lo largo de este capítulo en forma más completa, las diferentes funcionalidades que
brinda este objeto, que se introdujo en la versión 8.0 de GeneXus.

El editor de Themes es una herramienta de libre distribución que se puede ejecutar en forma
independiente de GeneXus. Esto es para que la herramienta pueda ser usada por el diseñador
gráfico, y el desarrollo de la aplicación se independice e incluso se paralelice con su diseño.

Se despliega como una estructura jerárquica de Clases, la siguiente es una imagen del editor
de Themes:
Se puede observar que descendiendo en la estructura jerárquica, se presentan un nodo
“Classes” y un nodo “HTML tags” (parte izquierda). Al centro, tenemos las propiedades
correspondientes a cada una de las Clases, y Tags HTML; y a la derecha un preview que es una
vista de cómo se visualizará en ejecución un control asociado a la clase correspondiente.

CLASES
A partir del nodo “Classes” se despliega un conjunto de clases predefinidas, correspondientes
a controles GeneXus.

Cada clase reúne un conjunto de propiedades configurables por el diseñador, y constituye un

“diseño” para un tipo de control GeneXus.

Una clase podrá ser asignada a un control en tiempo de diseño, y en runtime a través de la
“Propiedad Class”.

clases predefinidas
1. Attribute
2. Button
3. Error Viewer
 4. FreeStyle Grid
5. Grid
6. HyperLink
7. Image
8. Table
9. Textblock
10. Form

Nota 1:

Existen también específicas de botones, correspondientes a aquellos que son

generados en forma automática por GeneXus en Web Transactions y Web
Prompts.

Cuando se crean dichos objetos los botones se asocian a las clases

correspondientes. Estas clases son descendientes directas de la clase
“SpecialButtons” que es hija de la clase “Button”:

 BTnCancel
 BtnCheck
 BtnDelete
 BtnEnter
 BtnFirst
 BtnGet
 BtnHelp
 BtnLast
 BtnNext
 BtnPrevious
 BtnRefresh
 BtnSelect

Nota 2:

Las propiedades del Form, que se definen en GeneXus se aplican al BODY del HTML. Esto es
porque algunas de esas propiedades no son soportadas por el tag FORM (por ejemplo, el
background color).

Por la misma razón, la clase Form queda en runtime asociada al tag BODY.

Clases 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 y configurar las
propiedades que le corresponden a esa clase.

Las clases hijas o derivadas quedan implícitamente vinculadas en una relación de

herencia con las clases de las cuales derivan. Como consecuencia de esto, las
modificaciones en las clases “padre” se verán reflejadas en las “hijas”, con algunas
excepciones. Las modificaciones consisten en cambiar los valores de alguna de las
propiedades de la clase.

La parte inferior del editor muestra el nombre de la propiedad, junto con una
descripción de la misma. Además dirá “Inherited: True” o “Inherited: False
según corresponda.

Si para una propiedad de una clase dice “Inherited: True”, significa que su valor es un reflejo
del valor de la misma propiedad del padre. Es decir, cualquier cambio en la clase padre se
traduce en un cambio en la misma propiedad en el hijo.

En cambio, "Inherited: False" implica que un cambio en la propiedad en la clase padre no se

reflejará en la clase hija. La herencia en el valor de las propiedades se pierde cuando éstas son
alteradas en las clases hijas.

Propiedades de un Theme
Las propiedades de un Theme son las siguientes:

FileName: Es el nombre del archivo físico que corresponde al Theme o al Template.

Name: Nombre lógico del Theme (o Template).

XML Template: Es el XML default con el cual se inicializa el 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 KB.

La utilidad de esta funcionalidad es la siguiente: si el usuario que está trabajando

en la KB tiene seteada la propiedad Base Image Path (por ejemplo en el
directorio: e:\images), pero el diseñador gráfico (quien usa el editor por fuera de
GeneXus) tiene las imágenes en el directorio c:\cliente\imagenes.

Si no se setea la propiedad cuando se trabaja con el Template, es decir, se usan

caminos absolutos y no relativos, todas las imágenes quedarán apuntando a
c:\cliente\imagenes que no existe en la máquina del usuario GeneXus y por lo
tanto no se va a visualizar correctamente el Theme cuando se incorpore a la KB
(además del hecho de que el usuario seguramente tuviera que cambiar ese path
porque no será válido en producción)

Si el diseñador configura la propiedad (en el ejemplo, con el valor

c:\cliente\imagenes), las imágenes quedarán salvadas en forma relativa, luego el
usuario GeneXus debe copiar las imágenes a e:\images para poder visualizar
correctamente el Theme al incorporarlo a la KB, sin necesidad de algún otro
procedimiento (como sería ir a cambiar uno por uno las imágenes utilizadas en el
Theme para que apunten a la imágen correcta).

Nota:

1. El valor por defecto de la propiedad Base Image Path es el directorio de la KB.

2. Se crea automáticamente un fólder “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, como se visualiza en la figura:

Las propiedades en el Editor de Temas están clasificadas de la siguiente manera:

1. Background Properties
2. Box
3. Classification
4. Font
5. Misc
6. Text

Esa es la clasificación estándar de las propiedades de los CSS (Cascading Style

Sheets), con la excepción del grupo “Misc”, cuyo propósito es centralizar las
propiedades que pueden ser editadas en GeneXus, para el control correspondiente
a la clase.
Clase Form
El control Form, se modifica según la clase Form. Las propiedades bajo el grupo “Misc” son las
que pueden ser editadas en las properties del control Form en diseño, más algunas
propiedades que complementan la funcionalidad de aquellas y se encuentran en el estándar
de CSS, que son las siguientes:

 BorderColor
 BorderStyle*
 BorderWidth
 Font
 Height
 Width

Las siguientes propiedades aún no es posible configurarlas en el Theme:

 TooltipText
 Word Wrap
 Caption

Los colores de los links, se configuran agregando Tags HTML.

Clase Button
Dentro de las propiedades del grupo “Misc”, se tienen las siguientes propiedades, que si bien
pertenecen a ese grupo, no se encuentran dentro de GeneXus para los botones:

 Background
 BorderStyle*
 Height
 Width

Además, se tienen todas las propiedades, fuera del grupo “Misc”, que como se
mencionó anteriormente son propias de los CSS.

Clase Attribute
Dentro de las propiedades del grupo “Misc”, se tienen las siguientes propiedades, que si bien
pertenecen a ese grupo, no se encuentran dentro de GeneXus para los atributos/variables:

 Background
 BorderColor
 BorderStyle*
 BorderWidth
 Height
 Width

Las propiedades de los demás grupos aparte del “Misc” tienen su definición correspondiente al
pié del Editor de Temas, y pertenecen al estándar de CSS.

Clase Image
La clase Image se puede asignar tanto a controles imagen, como a variables de tipo bitmap.

Las propiedades del grupo “Misc”, que no se encuentran disponibles en diseño en GeneXus
para imágenes son las siguientes:

 BackColor
 BorderColor
 BorderStyle*
 Font
 ForeColor
Las propiedades de los grupos distintos de “Misc” pertenecen al estándar de CSS.

En particular, el valor de la propiedad Margin del Editor de Themes, se suma al valor de las
propiedades Hspace y Vspace de GeneXus (caso de imágenes).

En la documentación del CSS se muestran que se maneja el siguiente concepto:

Margin

Border

Padding

Content

La hspace y vspace son similares al border, por eso se "suman" cuando se define un margin.

Clase Table
Las propiedades del grupo “Misc”, que no se encuentran disponibles en diseño en GeneXus
para tablas son las siguientes:

 BorderStyle*
 LinesColor
 LinesFont

Clase Grid
La propiedad que se encuentra en el grupo “Misc”, y no está en diseño en GeneXus, es:

 Borderstyle*

Propiedades que están en diseño en GeneXus, y no están disponibles en el Editor de Themes:

 Backcolorstyle : Debe ser asignada en diseño.

  CellPadding, CellSpacing: A nivel del Editor de Themes, no existe la propiedad
Cellpadding y Cellspacing, esto es porque no las soporta el CSS.
Existe la propiedad Padding, que se compone de BottomPadding, LeftPadding,
RigthPadding, TopPadding.

En Internet Explorer a la propiedad Padding, se la interpreta como cellPadding cuando

se le pone cellPadding en 0 en diseño, y se ignora si cellPadding es diferente de 0.

Clase FreeStyleGrid

Aplican las mismas observaciones que para la clase Grid.

Clase TextBlock
Las propiedades del grupo “Misc”, que no se encuentran disponibles en diseño en GeneXus
para textblocks son las siguientes:

 BackColor
 Background
 BorderColor
 BorderStyle*
 BorderWidth
 Height
 Width
 Font**
 ForeColor**

**Las propiedades de Font y ForeColor, si bien no están disponibles en el diálogo de

configuración de los textblocks en diseño (y sí están en el Tema), en diseño, se pueden
configurar seleccionando el textblock y usando la barra de formato de texto de GeneXus.

Clase ErrorViewer
Las propiedades del grupo “Misc”, que no se encuentran disponibles en diseño en GeneXus
para el control ErrorViewer son las siguientes:

 Background
  BorderColor
 BorderStyle*
 BordeWidth
 Height
 Width

Nota:

*La propiedad BorderStyle, en el Tema, tiene una gama de valores más amplia que en el caso
de la misma propiedad en GeneXus.

Los valores que la propiedad acepta en el Tema son los que admite la tecnología CSS y son los
siguientes:

 None
 Dotted
 Dashed
 Solid
 Double
 Groove
 Ridge
 Inset
 outset
Preview del editor de Themes
En la barra vertical derecha del editor, hay un botón “Preview” mediante el cual se
puede mostrar o no, una vista previa de cómo se visualizaría un control asociado a
dicha clase.

La vista previa del editor se puede personalizar, agregándole “Custom Views”, que son
archivos .HTML. Para eso, agregar una nueva vista a través del menú contextual del nodo
Custom Views, o presionando la tecla INS sobre el mismo.

Para eliminar una vista personalizada basta con presionar DEL/SUPR.

La vista consiste de varios tabs (HTML browser, HTML Source y CSS).

Se puede modificar el source y ver los cambios reflejados en el HTML, pero no se salvan dichos
cambios en el documento que esté activo.

La siguiente figura muestra un ejemplo en el cual se agregó una vista previa

llamada “Transacción”.
Nota:

Si se tienen diferentes clases form definidas (es decir, distintas clases hijas de la
clase predefinida form), el preview para el resto de los controles se ve con un
aspecto de fondo correspondiente a la configuración de aquella clase form que sea
la default.
 HERENCIA DE LAS PROPIEDADES DE UNA CLASE
En el caso de que una propiedad de una clase esté marcada como
“Inherited:False”, es posible revertir la situación.
Haciendo click con botón derecho sobre la propiedad correspondiente, aparece un
menú “Inherit Value”. Seleccionando dicha opción, la propiedad pasará a heredar
el valor de la misma propiedad del padre.

La derivación de clases, y en particular la "herencia" le brinda al usuario

facilidades en la tarea de mantenimiento de las Clases y claridad en el diseño.

Por ejemplo si se define una clase “Bullet” derivada de Texblock, con el fin de
definir las propiedades de los textos en listas con viñetas.

Supongamos que ahora se quiere tener otra clase para los textos anidados a
aquellos que estan asociados a la clase “Bullet”, y se desea que tengan las
mismas características que la clase “Bullet” a excepción de la indentación.
Llamemos a esa clase “SubBullet” y creémosla como hija de “Bullet”. Esta clase
solo difiere con su padre en la propiedad “TextIndent”. Por lo cual, esa es la única
propiedad que no hereda, y la única propiedad que habiéndose modificado en el
padre no se refleja en la clase “SubBullet”.
Herencia: aplicación práctica

Como ejemplo del concepto de herencia en los Temas, edite el Tema “default” de la KB, 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 web transaction “Customer” como todos los botones cambian el “Backcolor”, siendo
que cada uno de ellos está asociado a una clase diferente derivada de “Button”.

Haga clic aquí para ver la demostración..

Haga clic aquí para ver cómo se pierde la herencia de las propiedades, al ser modificadas en la
clase hija.

HTML TAGS
Los HTML Tags complementan la funcionalidad de los Themes, en cuanto a que permiten
definir las características de un Tag HTML, en un determinado contexto. Es decir, siempre que
se quiera establecer la configuración de un determinado Tag dentro de un contexto, se puede
hacer mediante el Editor de Themes. Por ejemplo, definir las propiedades de los links dentro
de una tabla.

La configuración de los Tags HTML, dada en el editor, se ve reflejada en la página Web si esos
Tags están en el HTML de la página, en el mismo contexto con el cual fueron definidos en el
editor.

El contexto está determinado por la jerarquía con la cual se definen los Tags.
Para el ejemplo que mencionábamos anteriormente, de definir las propiedades de los links
dentro de una tabla, se haría como se muestra en la figura:

Se define un Tag A hijo de un Tag TD.

Es decir, siempre que un tag A se encuentre anidado a un tag TD en el HTML generado, se

tomará el forecolor definido en el ejemplo.

Otro caso de ejemplo sería definir un tag body y la propiedad “ForeColor” del mismo, con lo
cual el texto libre de la página tomará ese color.
Aplicación práctica: Temas
Cuando se hace una aplicación Web es necesario que el sitio se vea “uniforme”.

Esto implícitamente requiere de un alto costo de mantenimiento, ya que si por ejemplo hay
que cambiar el color de una grilla de azul a celeste, probablemente habría que hacerlo en
todas las páginas del sitio para mantener la uniformidad del mismo. Antes, había que ir por
cada uno de los controles de cada objeto. Hoy el cambio se realiza en un solo lado: el Tema.

Todos los objetos basados en el Tema van a reflejar el cambio automáticamente.

Cuando se salva un Tema con el editor de Temas ejecutado desde dentro de

GeneXus, se obtiene un archivo con extensión .CSS (Cascading Style Sheet) en el
directorio web del modelo.

En tiempo de ejecución, ese archivo .CSS (que contiene la definición de las clases)
es referenciado en el Header de las páginas generadas, y se transfiere al pc del
cliente para almacenarse en su caché.

Por lo cual, siempre que realicemos un cambio en el Tema asociado a un objeto,

basta con llevar el archivo .CSS a producción, para que el usuario final perciba los
cambios estéticos realizados (no es necesario generar ni compilar!!)

Veamos un ejemplo con la aplicación del curso.

Observe que los objetos de la Kb del curso están asociados al Tema “Default” (a
través de la propiedad “Theme” del objeto), y los controles de cada uno de los
objetos están asociados a la clase default correspondiente (propiedad “Class” de los
controles).

Realizaremos algunos cambios a las clases de Tema “Default” y veremos como se

reflejan los cambios en ejecución.
Note que en nuestro caso, el directorio de producción coincide con el directorio web
del modelo, por lo cual no es necesario copiar el .CSS a ningún lado.

Haga clic aquí para ver la demostración.

Crear un nuevo Tema

Se puede crear un Tema de dos maneras:

1. Desde el Editor de Temas

2. Desde el menú de GeneXus.

Para crear un nuevo Theme desde dentro de GeneXus, se debe ir a la opción Object >
New Object > Theme.

Un nuevo Theme consiste de los siguientes elementos:

 Un nombre (nombre del nodo raíz)

 Un conjunto de elementos predefinidos, correspondientes a las clases, dentro del
 folder “Classes”.
 Un folder “HTML tags” inicialmente vacío.

Como ejercicio, crearemos un nuevo Tema de nombre “Movie”.

En ese Tema vamos a definir una clase “BtnLogin” para la cual definiremos algunas
propiedades. En particular, vamos a asignarle una imagen a la propiedad “Background” de la
clase.

Observe que la propiedad “Base Image Path” del Tema coincide con la misma propiedad del
modelo de diseño. Entonces, dado que vamos a usar una imagen que se encuentra bajo el
“Base Image Path”, el path de la propiedad Background del Tema quedará relativo.

Al Tema “Movie” lo vamos a asociar al web panel “Login”. Debemos cambiar la clase del botón
“Login” para que sea “BtnLogin”.

Haga clic aquí para ver la demostración.

Observe que en este caso si es necesario generar/compilar antes de ejecutar, ya que

cambiamos una property del objeto y una property del control.

Uso del Editor de Themes

El editor se puede ejecutar desde GeneXus y como un programa independiente.

Dentro de la KB es posible salvar los Themes como archivos con extensión .CSS
(objeto theme de la KB). Asimismo, dentro y fuera de GeneXus, el editor permite
trabajar con archivos con extensión XML.
Esta última funcionalidad (trabajar con archivos XML) es la que permite la
integración entre el editor como aplicación independiente y como tool de GeneXus.

Nomenclatura: Llamaremos “Template” a los archivos XML que tienen el

formato de Themes, pero no son objetos GeneXus Theme.
Cuando el Editor es ejecutado en forma independiente de GeneXus,
siempre se trabaja con Templates.

Entonces, un usuario podrá diseñar un sitio utilizando el editor de Themes

independientemente de GeneXus; el producto de su trabajo serán archivos .XML
que otro usuario (posiblemente quien desarrolle la aplicación) podrá integrar a la
KB, y salvar como objetos GeneXus Theme (archivos .CSS).

Por otro lado, también se podrá desde la KB salvar un Theme con extensión .XML
de manera de poder editarlo y modificarlo por fuera de GeneXus.

Con esto se logra independizar el trabajo de diseño de las páginas, del desarrollo de
la aplicación.

Dado un diseño en formato XML (un Template creado con el Editor por fuera de
GeneXus), se puede incorporarlo a la KB rápidamente siguiendo los siguientes
pasos:

1. Abrir el Template usando el Editor desde dentro de GeneXus (opción File –>
Open Template)
2. Salvar el Template como un Theme (opción File -> save as)

Opciones del Editor para el manejo de Themes y Templates

OPCIÓN SAVE AS
Cuando el Editor es ejecutado desde dentro de GeneXus, mediante la opción del menú :
File -> Save As se puede:

1. Salvar un Template como un objeto GeneXus Theme

2. Salvar un Template como otro Template
3. Salvar un Theme como otro Theme
4. Salvar un Theme como un Template

Si se tiene el check “GeneXus” habilitado, se salva como un objeto Theme.

De lo contrario (si el checkbox está deshabilitado), se habilita la opción File Name,
para ingresar el nombre que se le dará al archivo XML generado.

Si el Editor se ejecuta por fuera de GeneXus la única opción del “save as” es
guardar un Template como otro Template.

OPTIONS -> CUSTOMIZE -> “TEMPLATES”

En el Menú Options -> Customize del Editor de Themes se presenta el
siguiente diálogo:

Mediante este diálogo se incorporan archivos XML al Editor, y se determina uno de

ellos como “Default Template”.
El default Template se usa para:

1. Inicializar el Theme que se crea automáticamente cada vez que se crea

una nueva KB.
2. Para inicializar un Theme si se crea desde el menú de GeneXus (Object ->
New Theme).
Los templates “Custom” se graban en el registry de la máquina, y por lo general
solo va a ser necesario incorporar aquellos que se sepa que se van a usar
habitualmente como base para crear Themes.
FILE -> NEW THEME
Es posible crear un objeto GeneXus Theme desde dentro del Editor de Themes,
cuando éste es ejecutado dentro de GeneXus.
Mediante el siguiente diálogo (menú “File->New” del Editor) se puede crear un
nuevo Theme en base a alguno de los Templates (incorporados mediante el diálogo
“Options->Customize Templates”.)

Por defecto el nuevo objeto se basará en el Template default.

Mediante el combo box “Based On” se puede seleccionar un Template con el cual se
inicializará el nuevo Theme creado (los Templates de esta lista son los incorporados
mediante el diálogo “Options->Customize Templates”)

Notas:
1. 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.

2. GeneXus distribuye cinco templates (archivos con extensión .XML) que

podrán ser usados opcionalmente como default. Estos quedan en el folder
“THEMES” de la instalación de GeneXus.

Los Templates que son incluidos con la versión son los siguientes:

 Beach.xml
 Classic.xml
 Executive.xml
 Extreme.xml
 Fancy.xml
 Light.xml
 PinkPanther.xml
Los cuatro primeros son “serios” y siguen las recomendaciones de "buen uso" del diseño en
internet, el resto son divertidos y radicales.

OPTIONS -> CUSTOMIZE -> “EDITORS”

Mediante el menú del editor Options->Customize-> “Editors” es posible

seleccionar el tipo de diálogo para los colores.

Esta configuración se guarda por usuario.

Las opciones son:

1. Default
2. Designer

Si se usa el diálogo "Designer", y se definen “Custom Colors” (botón “Add to

Custom Colors”), estos valores son almacenados con el Theme.

De esta forma si se define un conjunto de colores básicos para el Theme, estarán

disponibles cada vez que se quiera editar.

Por ejemplo: si se crea un Theme Gold (toda una combinación de amarillos y

naranjas), en los custom colors quedan los colores definidos como custom.

El editor como aplicación independiente

Usando el editor desde fuera de GeneXus, se pueden salvar los Themes en archivos con
extensión XML.
Se puede llamar al editor desde fuera de GeneXus, haciendo doble click en el
GXThemeEditor.exe o desde línea de comandos pasándole como parámetro
opcionalmente un archivo con extensión .XML.

De forma de distinguir cuando se edita un Template de cuando se edita un Theme,

la interfaz del Editor cambia en algunos aspectos:

1. El título de la ventana indica que es un “Template”

2. El color de fondo del Treeview es gris y no blanco como en el
caso de cuando se edita un Theme GeneXus.

Creación de un objeto Theme por defecto cuando se efectúa la creación de una kb

en GeneXus

Cuando se crea una nueva base de conocimiento en GeneXus, se crea un objeto Theme por
defecto.

Para la inicialización de este objeto se utiliza el Theme definido como Default en el editor
(“Default Template” –ver sección “Uso del editor”). En particular, se utiliza aquel Theme
definido en el registry de la máquina: HKEY_LOCAL_MACHINE\Software\Artech\GxTheme
Editor\1.0\ThemeTemplates\DefaultTheme.

Al ejecutar el setup de distribución de GeneXus queda grabado el registry con un

Theme default.
Interacción diseñador – desarrollador de la aplicación
Web
Debido a las exigencias de un buen diseño estético del sitio, por lo general es necesario
contratar el servicio de un diseñador gráfico. De ahí es que surge la necesidad de una buena
interacción entre el diseñador y quien programa la aplicación, e incluso el hecho de paralelizar
ambas tareas.

Veremos en un ejemplo práctico, como a través del Editor de Temas, se logra independizar el
diseño de las páginas, del desarrollo de la funcionalidad de la aplicación.

El diseñador gráfico (sin tener GeneXus instalado en su máquina), se instalará el Editor de

Temas a través de un setup de nombre GXThemeEditor.exe

Al ejecutar el setup, aparece la siguiente ventana:

Los únicos requerimientos para instalar el Editor de Temas en un pc son:

•.NET Framework 1.1 Redistributable Package

• Internet Explorer 6.0 SP 1 o superior

Vamos a crear un “Template” ejecutando el editor en forma independiente a GeneXus, y luego

integraremos ese Template a la KB del curso, para crear un Tema y asociarlo al modelo de la
aplicación que estamos desarrollando.

Lo primero, es ejecutar el GXThemeEditor.exe. Una opción es ejecutarlo desde la instalación de

GeneXus, la otra posibilidad es instalarlo en un directorio aparte corriendo el setup del Editor
de Temas.

Una vez abierto el Editor de Temas como aplicación independiente a GeneXus, “diseñaremos”
un Template y lo salvaremos en algún directorio (es un archivo con extensión XML).

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

Una vez salvado el Template en algún directorio, vamos a ejecutar esta vez el Editor de Temas
desde dentro de la aplicación GeneXus (mediante la opción “Tools->GX Theme Editor”)

Para editar el Template anteriormente creado, ir al menú del Editor de Temas “File -> Open
Template” y seleccionar el Template del directorio donde lo hemos guardado (con extensión
XML).

Para salvarlo como un Theme de la KB, ir al menú “File -> Save As”, y estando chequeada la
opción GeneXus del diálogo, salvarlo con el nombre “Movie2”.

Una vez que es un Theme de la KB, lo podemos asociar a la propiedad “Theme” del modelo.

Haga clic aquí para ver como integramos el template anteriormente creado, al modelo del
curso.

INTRODUCCION AL CAPITULO 8
Una pregunta muy importante a la hora de desarrollar una aplicación para
Internet, es la siguiente:
¿Es segura nuestra aplicación en Internet?

Como la seguridad es un concepto muy amplio, la respuesta a esta pregunta no es

sencilla. Sin embargo, dependiendo del tipo de aplicación que se está
desarrollando, este punto puede ser crucial.

Se puede decir que al publicar una aplicación en Internet, se tienen 3 niveles

distintos de seguridad:

 SEGURIDAD A NIVEL DEL SERVIDOR WEB.

 SEGURIDAD A NIVEL DE LA BASE DE DATOS.

 SEGURIDAD A NIVEL DE LA APLICACIÓN.

A lo largo de este capítulo se va a desarrollar cada uno de los puntos mencionados

anteriormente...

SEGURIDAD A NIVEL DEL SERVIDOR WEB

Cuando se habla de la seguridad a nivel del servidor web, se están enfrentando básicamente
los siguientes riesgos:

 Intercepción de información enviada a través de la red desde el navegador al

servidor o viceversa.

 Errores o problemas de configuración del servidor web, que permitan a usuarios no

autorizados:
o acceder a información confidencial que se encuentra en el servidor,
o ejecutar comandos que afecten el comportamiento del servidor y les permita
ingresar al sistema.

Intercepción de información
El protocolo TCP/IP no fue diseñado para ofrecer servicios de comunicación seguros. En
consecuencia, la información enviada desde el navegador al servidor web o viceversa puede
ser interceptada por alguien.

Es por esta razón que se debe agregar tecnología adicional para resolver problemas de
seguridad.

Desde siempre, existe una única tecnología que provee los principios para resolver estos
problemas: CRIPTOGRAFIA.
Existen servidores web, que pueden trabajar como servidores seguros. Un servidor seguro es
un servidor web, al cual se le habilitó la posibilidad de encriptar los datos que se envían al
navegador, así como desencriptar la información recibida del mismo.

El standard más conocido de autenticación y encriptación de datos para el Web es el SSL. Este
standard fue propuesto por Netscape Communications Corporation y es el que soportan la
mayoría de los navegadores (Internet Explorer, Netscape).

Para habilitar la encriptación de datos se necesita obtener un certificado de una autoridad

certificadora (por Ej.: Verisign, El Correo (en Uruguay)), este certificado es instalado en el
servidor web, quedando habilitada la encriptación de datos.

Finalmente, para activar la encriptación de los datos a transferir, todo lo que el usuario debe
hacer es realizar la solicitud del recurso a través del protocolo HTTPS: en lugar de HTTP.

La seguridad ofrecida por el servidor web, depende en parte también del largo del certificado
soportado. Cuanto más largo sea el mismo más segura es la comunicación de los datos.

Hay que destacar que los servidores seguros protegen “únicamente” la información
confidencial de ser interceptada por terceros, pero sin seguridad a nivel del sistema el servidor
web sigue siendo vulnerable a ataques.

La property “Protocol Specification” aplica a la generación automática de links entre

webpanels, y el objetivo es identificar el protocolo default a usar cuando se construyen los
links (HTTP, HTTPS.)

Acceso de usuarios no autorizados

La mayor parte de los riesgos que se presentan al tener un servidor web público son asumidos
por el administrador del sitio. Desde el momento que se instala un servidor web en un sitio, se
abre para la comunidad Internet una “ventana” a la red de área local.

La mayor parte de los usuarios únicamente visitan el sitio, otros, sin embargo intentarán entrar
por la “ventana” abierta. Los resultados pueden ser variados, desde el simple descubrimiento
que la página principal del sitio web fue cambiada, hasta el robo de la base de datos que
contiene la información de sus clientes.

Es entonces importante que el administrador del sistema defina políticas de seguridad, así
como tome las medidas necesarias para evitar el acceso de usuarios no deseados. Estas
medidas pueden ser a nivel del sistema operativo (restringir las operaciones que se pueden
realizar, limitar los permisos sobre documentos y directorios, deshabilitar servicios no
utilizados, etc.), como a nivel del servidor (aislamiento de la red, instalación de firewall).

Existe abundante documentación sobre el tema, que es recomendable leer, para saber que
pasos debería seguir al publicar documentos, o aplicaciones en su sitio web.

Bibliografía:
Verisign:

http://www.verisign.com/products/site/faq/40-bit.html#6

El correo:

http://www.correo.com.uy/CorreoCert/sitio_seguro.htm

Microsoft:

Internet Information Services (IIS) 6.0 security overview

http://www.microsoft.com/resources/documentation/WindowsServ/200
3/enterprise/proddocs/en-
us/Default.asp?url=/resources/documentation/WindowsServ/2003/ent
erprise/proddocs/en-us/iis_security.asp

Hardening Systems and Servers: Checklists and Guides

http://www.microsoft.com/technet/security/topics/hardsys/default
.mspx#XSLTfullModule122121120120

Apache Web Server:

Securing Apache: Step-by-Step

http://www.securityfocus.com/infocus/1694
SEGURIDAD A NIVEL DE LA BASE DE DATOS

La seguridad a nivel de la base de datos es también un punto sensible a la hora de

publicar una aplicación en Internet. Es de fundamental importancia evitar que
usuarios no autorizados puedan acceder a los datos corporativos, así como que un
usuario autorizado realice operaciones que le deberían estar negadas.

Desde el punto de vista de la configuración del modelo de GENEXUS, no se deben realizar

configuraciones específicas para mejorar la seguridad de la base de datos.

SEGURIDAD A NIVEL DE LA APLICACION

A nivel de la aplicación, la seguridad depende del tipo de aplicación que se esté desarrollando.

La implementación de controles de seguridad, es importante en aplicaciones en las cuales los

usuarios acceden a información confidencial, como por ejemplo sus datos personales.

La razón por la cual son necesarios dichos controles, es que los parámetros que se pasan entre
objetos web (y entre páginas dinámicas en general) viajan visibles al usuario, como por
ejemplo:

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

Por lo tanto, por más que se disponga de una página de login, donde se valida el usuario y su
contraseña para ingresar al sistema, el usuario eventualmente podría saltearse la misma,
ingresando en el navegador la URL de la siguiente página con un código de usuario válido.
Para evitar que se burle el control de acceso y permitir que se acceda a información
confidencial, es que se debe agregar algún tipo de control adicional de seguridad.

A continuación, se van a discutir diferentes posibilidades que se encuentran disponibles.

MANEJO DE SESIONES
Una de las posibles alternativas para solucionar el problema de seguridad mencionado
anteriormente, es el uso de sesiones.

El uso de sesiones se compone de una transacción (SECURITY) que almacena el

usuario logueado, un número randómico de sesión y la fecha y hora del comienzo
de la misma. Mediante este número de sesión se controla que un usuario no pueda
acceder a los datos de otro usuario.
Cada vez que el usuario ingresa a una página del sistema, se chequea el número de usuario y el
número de sesión. Si estos no se corresponden con los datos almacenados en la tabla
SECURITY, se muestra una pantalla indicando el error y se vuelve al usuario a la página donde
se pide login y password nuevamente.

Este número de sesión es válido por un tiempo determinado que se configura en el

procedimiento. Si el usuario está logueado por más de dicha cantidad de tiempo, se muestra la
misma pantalla de error.

A continuación se presenta un ejemplo del funcionamiento de las sesiones. La página principal

de la aplicación es Login, donde se controla la validez del usuario y su contraseña.

La primera vez que un usuario ingresa al sitio debe registrarse al mismo, creando un nuevo
usuario (navegando a través del link “Click here to complete a brief registration form”, el cual
lo lleva a la transacción “Customer”). De esa forma se da de alta el cliente, y se crea un
registro en la tabla SECURITY con el identificador del cliente, el número randómico de sesión,
la fecha y hora de la registración.

Luego se llama a la página donde se muestra la información a la cual únicamente los clientes
registrados pueden acceder, en este caso, ingresar productos al carrito de compras e ingresar
a la transacción de orden de compra “PurchaseOrder” para modificar detalles de la compra y
confirmar la misma.

En el evento Start de la transacción “PurchaseOrder”, se llama al procedimiento “Checksesion”.

Este procedimiento verifica que el número de sesión del cliente recibido se corresponda con el
que se encuentra almacenado, así como su validez. Si alguna de las condiciones anteriores no
se cumple, se llama a una página de error, donde se explica al cliente la causa del mismo. Hay
que darse cuenta que en ese caso nunca llegaría a visualizarse la página “PurchaseOrder”.

Login Customer Purchase Order

“InsertSec” “CheckSession”

El otro caso que queda por analizar, es cuando el cliente ya está

registrado. En este caso en el evento que valida el usuario se realiza una
llamada al procedimiento “GenSesNum” que actualiza en la tabla
SECURITY el número de sesión asignado al usuario, así como la fecha y
hora de generación del mismo. Igualmente que en el caso anterior, en la
transacción “PurchaseOrder” se invoca al procedimiento “CheckSession”
para validar la sesión.

Login Purchase Order

 “GenSesNum” “CheckSession”

FUNCIONES DE COOKIES

Introducción
El objetivo es proveer funciones que permitan leer y grabar cookies desde objetos web
generados por GeneXus.

¿Que son las cookies?

Las Cookies son archivos pequeños que se graban desde un web site en las máquinas de los
clientes. Los programas CGI o cualquier aplicación que corre en un servidor, puede leer o
grabar las cookies en el cliente.

El uso más común de las cookies es la identificación de usuarios. Cuando un usuario se registra
en un web site (Portal o E-Store), el sitio graba una cookie en la máquina del cliente con la
identificación del cliente. De este modo la próxima vez que el cliente visite este sitio, intenta
leer la cookie y si la misma existe usa el valor de la cookie para identificar el usuario y
recuperar sus preferencias desde una base de datos.

También existen otros usos de las cookies, como rotación de contenido (especialmente avisos),
mantener estado de una aplicación, etc. Incluso se pueden usar como método de almacenar el
“carrito de compras” de modo que la información del mismo quede en la máquina cliente y se
mantiene entre conexiones.

Como se menciona anteriormente, generalmente se usa una cookie para identificar el usuario
(en algunos casos, una para la sesión, en otros para el usuario), aunque se podrían poner
todos los valores de las preferencias en cookies. Lo ideal es tener una clave que viaje y con
esta clave leer la información del usuario. De este modo la información del usuario no viaja
hacia el cliente, ni está en la URL. (Ej. tarjetas de crédito, nombre, dirección) simplemente
permanece en el servidor.

Hay que tener en cuenta que existe un límite en cuanto a la cantidad de cookies que el cliente
puede aceptar. El máximo son 300 cookies en total por cliente (para todos los servidores juntos
por cada browser/cliente) y 20 cookies por server o dominio lo cual quiere decir que si una
aplicación graba más de 20 cookies las últimas van a borrar los valores de las primeras.
Además existe un límite de tamaño de 4K por cookie, si una cookie supera ese límite es
truncada.

El usuario puede preferir no grabar la cookie permanentemente (por ej. si está accediendo
desde una máquina pública como podría ser un cybercafe) o incluso puede deshabilitar el uso
de cookies, por lo cual esta no debe ser la única manera de identificar al usuario, sino que se
debe poder usar un método alternativo en caso de que el browser no soporte o no tenga
habilitado el manejo de cookies.

Otra particularidad es que el lugar donde se almacenan las cookies (al menos en Windows)
depende del browser, por lo que si un usuario tiene más de un browser, cada uno tendrá un
conjunto independiente de cookies.

El ciclo de vida de una cookie es como sigue:

1. El usuario se conecta a un servidor que por alguna razón quiere grabar una cookie.

2. En la respuesta (HTML Headers), se indica el nombre y valor de la cookie a grabar,

así como otros valores (el más relevante es la fecha de expiración).

3. El browser recibe la respuesta y, si el valor de la fecha de expiración es en el futuro,

la graba; en caso contrario busca una con ese nombre y la borra.

4. Cada vez que el usuario se conecte a una URL de este dominio el browser enviará al
server las cookies que se hayan grabado desde el dominio y no hayan expirado.

5. Una vez pasada la fecha de expiración, las cookies se borran.

Para obtener más información técnica sobre cookies y su uso :

http://www.cookiecentral.com
Descripción
Se dispone de las siguientes funciones, las que pueden ser utilizadas en cualquier objeto
GeneXus, el resultado tiene sentido únicamente si dicho objeto fue llamado en forma directa o
indirecta por un objeto web o está ejecutando en un ambiente Web.

GetCookie

Permite leer una cookie, devolviendo un string con el valor. Si no

encuentra la cookie (o no la puede leer por estar deshabilitada) devuelve el string
vacío.

La sintaxis es:

&var_char = GetCookie(NombreCookie)

NombreCookie – carácter

&var_char – carácter

SetCookie

Permite grabar una cookie. Devuelve 0 (cero) si el resultado es correcto, otro

valor si hubo algún error.

La sintaxis es:

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

Los parámetros entre paréntesis rectos son opcionales. Si alguno de los parámetros va nulo se
asume el default.
&var_num – variable numérica.

NombreCookie -Carácter

Nombre de la cookie

Valor - Carácter

Valor a almacenar

path - Carácter

Camino que indica para qué web panels la cookie es válida. Si

no se especifica, la cookie es válida para los web panels que
están en el mismo directorio que el que la grabó, o en
directorios subordinados. Si se indica “/” la cookie será válida
para todo el dominio.

Exp-date - Date/Datetime

Indica la fecha de expiración de la cookie. Si no se especifica, la

misma expirará cuando se cierre la sesión en el browser.

Domain-name - Carácter

Dominio donde es válida la cookie. Por default es el dominio

desde donde se creó.

Secure - Numérico

Si está en 1 la cookie se trasmite solamente si la conexión es

segura (HTTPS). Si está en 0 se trasmite siempre.
NOTA: Si se activa el trace para el generador C/SQL, y se pone TraceLevel=4 o mayor se verá
en el trace todas las Cookies que llegan al programa. Se imprimen una por cada línea
precedidos por la palabra Cookie.

Observaciones
 Las funciones mencionadas anteriormente siempre devuelven 0. La única forma de
detectar si una cookie fue almacenada es leerla. En consecuencia no se puede
obtener la configuración del navegador.

Ejemplos
Algunos ejemplos sencillos sobre cómo grabar una cookie son:

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

Aquí se está grabando una cookie -válida para todo el dominio- de nombre ID_USER con el
valor correspondiente al atributo UsrId y que expirará el 1° de Enero de 2002.

 &OK= SetCookie(“SESSION_ID_GX”, &StrSession, “”, Nullvalue(&Fecha) )

Aquí se está grabando una cookie -válida para los web panels de la misma aplicación -de
nombre SESSION_ID_GX- con el valor correspondiente a la variable &Strsession. La cookie
expirará al cerrar la sesión del browser.

 &Op= SetCookie(“USR_PAIS”, “UY”, “/”, ADDYR(&Today, 1),

“otrodom.artech.com.uy”, 1)

Aquí se está grabando una cookie -válida para todo el dominio ‘otrodom’- de nombre
USER_PAIS con el valor UY y que expirará exactamente dentro de un año.
TIPO DE DATOS WEBSESSION

Introducción
WebSession es un nuevo tipo de datos de GeneXus que permite almacenar datos en una
sesión de usuario del servidor Web. De esta manera se pueden tener variables globales,
accesibles mientras la sesión esté activa.

Alcance
- Objetos: Transacciones, Web Panel, Procedimientos

- Lenguajes: Java - Visual Basic - C#

- Interfaces: Web

Descripción
Los servidores Web permiten manejar el concepto de sesión. Una sesión se identifica por una
clave única, que se mantiene mientras el usuario continúe en el sitio Web.

El objeto WebSession permite almacenar información que será visible desde cualquier objeto
Web dentro de la sesión activa como si fueran variables globales al sitio.

Para utilizar el objeto WebSession, se debe definir una variable de este mismo tipo y aplicarles
los métodos y propiedades adecuados.

Propiedades:
Id

Esta propiedad retorna un String que es el identificador de la sesión. Por ejemplo:

&Iden = &Session.Id

Metodos:
Set(key, value)
Permite hacer una entrada en la sesión activa. Key y value deben ser del tipo
String. Por 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. Por ejemplo:

&User = &session.get(“user”)

Remove(key)

Permite remover un valor de una sesión. Por ejemplo:

&Session.remove(“user”)

Destroy()

Detruye el contenido de la sesión. Es recomendable utilizarlo cuando el usuario

hace un “logout”, si es que existe este concepto en la misma. Por ejemplo:

&Session.destroy()

Consideraciones Generales
 El ID de la sesión se guarda en una cookie en el cliente, aunque esto es transparente
para el programador.

 La validez de la Websession es similar a la validez de las cookies que solo valen por la
sesión. Esto quiere decir que si se abre una instancia nueva del browser, se pierde la
sesión, pero si abro en una ventana nueva se mantiene.

 Los datos y el ID de una sesión son diferentes para cada generador. Esto implica que
no puedo hacer un link de un Web Panel VB a un Web Panel Java y mantener los
valores de la sesión

 Si no se ejecuta el 'destroy()', el servidor Web destruye la sesión cuando ha pasado un

determinado tiempo desde la última vez que se utilizó. Esto depende del servidor
Web/plataforma, y se configura de forma nativa en cada una.

 La forma en que se almacena la información de sesión también depende de la

plataforma, y condiciona la capacidad de tener la aplicación en mas de un servidor
Web. Básicamente, si la sesión se almacena de forma local al servidor Web, solo es
visible en ese servidor Web, por lo que si el siguiente request del cliente va a parar a
otro servidor Web, no va a tener disponible los valores de sesión.
Consideraciones específicas para el Generador Visual
Basic
 En VB el destroy() limpia los valores almacenados en la sesión, pero si inmediatamente
se pide ID de la sesión devuelve el mismo ID. Java devuelven un nuevo ID.

Ejemplos

Supongamos un sistema Web donde el usuario debe autentificarse por medio de

un usuario y una password que están previamente grabadas en la base de datos.
Entonces podemos definir en el Web Panel de Inicio una variable tipo WebSession
(&Session) y las variables de entrada &User y &Password. En el evento Enter del
Web Panel definir

For each
Where UsrNom = &User
Where UsrPsw = &Password
&Session.Set(“Name”, UsrNombre)
Call (HWelcome)
When none
Return
//Usuario no valido
endfor

De esta manera validamos el usuario con la base de datos y en caso de los

valores correspondan guardamos el nombre del usuario en la sesión y vamos a un
Web Panel de bienvenida (HWelcome) .
Luego en el Web Panel Welcome definir en el evento Start:

&UsrNombre = &session.Get(“Name”)
If Trim(&UsrNombre)=””
Return ///Sesión no valida
Else
TX.Caption = “Bienvenido “+ &UsrNombre + “a nuestro sitio!”
Endif

De esta manera, obtenemos el nombre del usuario desde la sesión y escribimos

un mensaje de bienvenida en pantalla.

ENCRIPTACION DE PARAMETROS

Introducción
Los objetos Web generados con GeneXus, permiten visualizar los parámetros que se pasan
entre los objetos en la barra de dirección del navegador.
Esto hace que, si se pasa información reservada como parámetro entre objetos Web (Número
de cliente, por ejemplo), las aplicaciones no sean muy confiables en cuanto a la seguridad,
porque un usuario podría simplemente cambiar el valor de dicho parámetro en la URL y
disponer de información sobre la que no debería tener acceso. No sucede lo mismo si se
utilizan cookies, en este caso no hay problemas de seguridad.

Es por eso que se hace necesario pasar los parámetros sin que el usuario de la aplicación los
conozca o sea encriptar los parámetros.

En la versión 7.5 de GeneXus se implementa la encriptación de los parámetros de los objetos

Web que van en la URL en forma automática y transparente para el usuario.

Alcance
Objetos: Web Panels, Transacciones

Lenguajes: C/SQL, Java, Visual Basic, .Net

Interface: Web

Descripción
Para poder realizar la encriptación de parámetros en objetos Web se implementaron funciones
estándar que contienen las funciones básicas de encriptación y algunas funciones adicionales
(las que requieren manejo de parámetros y cookies).

Con respecto al diseño de los objetos la encriptación de parámetros no implica ningún

cambio, se programan de la misma forma que hasta el momento.

Las ventajas del uso de la encriptación de parámetros son:

 Que los usuarios finales no sepan el o los datos que van en los parámetros
 Que los usuarios finales no puedan modificar el o los datos que van en los
parámetros

Se agrega la preferencia Encrypt URL Parameters a nivel de modelo, en el grupo “Web

Information” y también a nivel de objeto.

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

No

Indica que No se van a encriptar los parámetros que van en la URL de los
objetos Web, siendo éste el valor por defecto.
 Session Key

Indica que se van a encriptar los parámetros que van en la URL, utilizando una
clave diferente para cada sesión. La encriptación se realiza a través del uso de
cookies locales.

Este valor ofrece un nivel de seguridad mayor, pero no permite compartir

URLs. Esto significa que no es posible para un usuario X enviar una URL que
tenga parámetros a otro usuario Y, ya que en este caso la URL no va a
funcionar porque se necesita la cookie correspondiente para la
desencriptación.

Site Key

Se encriptan los parámetros que van en la URL de los objetos Web, pero la
clave de encriptación va a ser la misma para todo el sitio.

En este caso no se utilizan cookies. Esto da un nivel de seguridad menor pero

facilita el traspaso de links.

La propiedad a nivel de objeto, además de los valores mencionados tiene el valor “Use model’s
preference value”. Este valor indica que se va a tomar el valor de la preferencia del modelo
para realizar la encriptación de ese objeto. Este es el valor por defecto.

Consideraciones Generales
Sesiones del Navegador
Una sesión del navegador queda determinada por una instancia del mismo. Por ejemplo, si en
un máquina se ejecuta el navegador de Internet y a partir de ese navegador se abre otra sesión
(a partir de la opción de menú File/New/Window o a partir de un link), ambas sesiones
pertenecen a la misma instancia del navegador.

En cambio, si se abre una sesión del navegador, y luego se ejecuta nuevamente el exe del
navegador 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 preferencia 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 navegador 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 preferencia del modelo,
determinan que todos los llamados entre objetos Web se harán con parámetros
encriptados. Para tener unicamente las llamadas entre algunos objetos con
parámetros encriptados se debe indicar el valor “No” en la preferencia 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 preferencia a nivel de modelo y la propiedad

a nivel de objeto para encriptar parámetros, ésta última tiene prioridad sobre la
primera.

 Cuando se utiliza la propiedad a nivel de objeto para encriptar parámetros, y se

realizan varios llamados entre objetos Web, se debe tener en cuenta que los valores
utilizados por todos lo objetos involucrados debe ser el mismo.
Por ejemplo: Si se tiene un Web Panel que llama a otro pasándole parámetros, y se
quieren visualizar estos parámetros encriptados, en ambos Web Panels se debe
configurar el mismo valor para la propiedad “Encrypt URL Parameters”.

Lo mismo sucede si el arbol de llamadas involucra a más objetos Web, todos (los
llamados y los llamadores) deben tener configurada la propiedad Encrypt URL
Parameters y todos deben tener el mismo valor en la propiedad.

Propiedad “Encrypt URL Parameters” en Prompts

Los parámetros de los prompts asociados a las Transacciones Web no es posible encriptarlos.
Esto es porque el llamado a los prompts se realiza desde el cliente y para realizar la
encriptación se debe ir al servidor.

Ejemplos
Si se tiene un Web Panel que recibe parámetros y no se utiliza la encriptación de parámetros,
la URL correspondiente al Web Panel será del estilo:

http://localhost/HINGRESO_WebObj/hdospar.asp?2,3
Si, en cambio se utiliza encriptación de parámetros (preferencia Encrypt URL Parameters =
Session Key ó Site Key), la misma URL se generará de la siguiente forma:

http://localhost/HINGRESO_WebObj/hdospar.asp?lQ/tK1lefxCZMVoXrnmrTQ==

COMPARACION DE ALTERNATIVAS DE
SEGURIDAD EN LA APLICACIÓN
A continuación se realiza una comparación entre las soluciones disponibles para agregar
seguridad a una aplicación web.

Cookies
Ventajas:
 No es necesario el pasaje de parámetros entre Web Panels, ya que los
valores se graban en la cookie.
 Si las cookies no son temporales, se puede saber si el usuario ya accedió
anteriormente a la aplicación.
Desventajas:
 Tienen limitaciones en cuanto al tamaño máximo, cantidad de cookies que se
pueden grabar. Se tiene dependencia de la configuración del navegador.

Manejo de sesiones
Ventajas
 Es independiente de la configuración del navegador del PC del cliente.
Desventajas
 Mayor complejidad de programación
 Pérdida de información: si el usuario pasa a una página estática, y luego
vuelve a ingresar la URL en el navegador, debe volver a loguearse.

Tipo de datos Web Session

Ventajas
 Presenta las mismas ventajas que el uso de cookies.
Desventajas
 Depende de la configuración del navegador. No permite compartir datos si
los objetos son generados en diferentes lenguajes. Por el momento no es
soportado por C/SQL.
 No es posible compartir la información de sesión entre diferentes servidores,
ya que es local al webserver.
 La destrucción de los datos depende del browser utilizado.

Encriptación de la URL
Ventajas
 No se requiere programación alguna, simplemente se modifica el valor de
una preferencia.
Desventajas
 El tamaño de la URL aumenta al ser encriptada, por lo tanto si el
pasaje de parámetros es importante, se puede llegar al máximo
aceptado por el browser. Requieren del uso de cookies en el caso de
“Session Key”.

Lo que nos quedaría por implementar en el web panel

de “Movie Details” es el evento asociado al botón
“Add to Cart”…
Como hemos visto hasta el momento, si bien el web panel “Sale of Movies”
permite loguearnos al sistema, recién cuando el usuario desea realizar alguna
compra (en el botón de "Add to cart" en el web panel “Movie Details”) se exige
que el usuario ya se haya identificado y que sea por supuesto un usuario válido.

En caso de ser un usuario registrado y haberse identificado, se genera la orden

de compra correspondiente (invocando a los procedimientos "AddHead" y
"AddLine" según corresponda), pero en caso contrario se le dará al usuario un
mensaje diciéndole que "Debe identificarse antes de realizar alguna compra".

Todo esto es lo que tenemos que implementar en el evento asociado al botón

"Add to cart" del web panel “Movie Details”. Es decir, que a partir del evento
asociado al botón de “Add to cart” del web panel “Movie Details” se requiere que
la aplicación sea segura.

Utilizaremos cookies “temporales” para evitar que todo usuario que se registre al sitio desde el
mismo computador utilice la misma información de conexión.
Disponemos de un Business Object (security.xpz) que brinda los objetos
necesarios para definir la “seguridad” en las aplicaciones Internet utilizando
cookies.

Implementación de la seguridad en nuestra

aplicación
El control de la seguridad lo implementaremos utilizando:

 Una tabla denominada Security donde se almacena para cada nuevo cliente el
número generado en forma aleatoria para su sesión, así como la fecha y hora de la
última sesión activa.
La estructura de la tabla sería entonces la siguiente:

SecId*
SecRnd (Número de sesión randómico)
SecDate (Fecha de Inicio de Sesión)
SecHour (Hora de Inicio de Sesión)

 Una cookie denominada SECURITY que concatena (separados por una coma) el
número identificador del cliente (atributo CustId), así como un número generado en
forma aleatoria de la sesión de este cliente (atributo SecRnd).

Descripción de Objetos del archivo security.xpz

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

SECURITY

Es la transacción que define la tabla de SECURITY.

INSERTSEC
Este procedimiento da de alta en la tabla SECURITY la primera vez que el
usuario inicia una sesión en el web.

CHECKSESSION
Este procedimiento valida el número de sesión recibido con el usuario que está
logueado, y devuelve el código de validación resultante. A la sesión se le da
una validez de 1 día.
Se distinguen tres casos: cuando el Usuario tiene iniciada una sesión vigente
(valor S), cuando el usuario tiene una sesión vencida (valor V) y cuando el
usuario tiene una sesión, pero no coincide el número randómico de sesión
 (valor I).

GENSESNUM

Este procedimiento actualiza el número randómico de sesión del usuario, junto

con la fecha y hora en que se logueó por última vez.

RETSTR
Este procedimiento devuelve los dos valores almacenados en la cookie: el
número de usuario y el número de sesión.

ERROR
Este web panel se invoca siempre que sea necesario cancelar la ejecución de la
aplicación (por ejemplo: cuando la sesión ya no está vigente se invoca
automáticamente a este web panel, desplegándole al usuario el mensaje
correspondiente).

Lo primero a hacer entonces es consolidar en la KB del curso el archivo

security.xpz.

¿Dónde dentro de la aplicación tenemos que grabar las

cookies? o lo que es lo mismo ¿Dónde dentro de la
aplicación tenemos que invocar a la función SetCookie?

La cookie se debe grabar cuando el cliente se registra en el sitio por primera vez
(en la transacción TCustomer)) y cada vez que se identifique (evento LOGIN de
todos los web panels del sitio).

1) Cuando el cliente se identifica, luego de chequear que el usuario y

password ingresados son válidos, tenemos que grabar una cookie (con la función
SetCookie), y luego en el evento Start de cada uno de los web panels de “acceso
limitado a usuarios registrados” tenemos que leer la cookie (con la función
GetCookie). Como definimos anteriormente un web component para encapsular el
procedimiento de login, simplemente debemos editar el evento 'Login' del web
panel definido como web component y realizar la siguiente modificación:

Event 'Login'
for each
where CustUsr = &CustUsr
if upper(CustPsw) = upper(&CustPsw)

&SecRnd = Udp(PGenSesNum,CustId)
&CookieVal = Concat(trim(Str(CustId)),trim(Str(&SecRnd)),',')
&result = SetCookie('SECURITY',&CookieVal)

message.Caption = 'Welcome to movies.com'

else

message.Caption = 'Invalid password, try again please'

endif
when none
message.Caption = 'User name not found'
endfor

EndEvent // 'Login'

Haga clic aquí para ver la demostración

2) El otro lugar donde tenemos que grabar una cookie es cuando se da de alta
un usuario nuevo. Es decir, que en la transacción ‘Customer’ (TCustomer), luego
de dar de alta el cliente, tenemos que grabar una cookie en el PC Cliente con el
CustId del cliente nuevo y el número de sesión randómico. Para esto vamos a
crear un procedimiento Login con el siguiente código:

&SecRnd = Udp(PInsertSec,&CustId)

&cookieVal = Concat(trim(Str(&CustId)), trim(Str(&SecRnd)),’,’)

&result = SetCookie(‘SECURITY’,&cookieVal)

Este procedimiento deberia recibir como parámetro la variable &CustId. En la

transacción TCustomer, deberíamos agregar en las reglas:

Call(Plogin,CustId) if after(Trn);

Hagamos entonces estas modificaciones necesarias…

¿Dónde tenemos que leer las Cookies? Es decir, dónde

tenemos que invocar a la función GetCookie?

Como ya dijimos antes, todos los web panels del sitio de “acceso limitado a
usuarios registrados”, deben realizar el control de la seguridad leyendo la cookie y
comparando los valores obtenidos con los valores almacenados en la tabla de
SECURITY. En nuestro caso, en el evento asociado al botón de “Add to cart” y en
el evento Start de la transacción ‘Orden de Compra’ (“Purchase Order”).

1) VAMOS A TENER QUE INCLUIR LAS SIGUIENTES LÍNEAS DE

CÓDIGO EN EL EVENTO START DE LA TRANSACCION PURCHASE
ORDER:

&CookieVal = GetCookie('SECURITY')

Call(PRetStr,&CookieVal,&CustStr,&SecStr)

&CustId = Val(&CustStr)

&SecRnd = Val(&SecStr)

&result = Udp(PCheckSession,&CustId,&SecRnd)

If &result <>'S'  si la sesión de dicho usuario no está vigente

 Call(HError)
Endif

Haga clic aquí para ver la demostración

2) HAGAMOS EL CONTROL (EN EL WEB PANEL “MOVIE

DETAILS”) DE QUE EL USUARIO TIENE QUE SER UN USUARIO
“REGISTRADO” PARA PODER REALIZAR COMPRAS ...

El evento asociado al botón de "Add to cart" quedaría entonces:

Event ‘Add to cart’

&CookieVal = GetCookie('SECURITY')

Call(PRetStr,&CookieVal,&CustStr,&SecStr)

&CustId = Val(&CustStr)

&SecRnd = Val(&SecStr)

&result = Udp(PCheckSession,&CustId,&SecRnd)

If &result = ‘S’ // si la sesión de dicho usuario está vigente

For each

Where CustId = &CustId and PurOrdSts = OrderStatus.Pending

&PurOrdId = PurOrdId

Endfor

For each line in prices

if not null(&Qty)

If null(&PurOrdId)

&PurOrdId = udp(PAddHead, &CustId)

endif

call(PAddLine,&PurOrdId ,MovieId, &MovieTypeId,&Qty)

endif

Endfor
call(TPurchaseOrder,&PurOrdId)

Else // si la sesión de dicho usuario no está vigente

Call(HError)
Endif
EndEvent

Haga clic aquí para ver la demostración

Nota:

1. Observe que para el usuario de prueba que se estaba usando en los ejercicios
anteriores, al momento de creado no se tenía en cuenta la seguridad del sistema, por
lo cual no fue dado de alta en la tabla de seguridad, y cualquier intento de realizar
una compra con él va a dar error. Entonces, para probar el ejercicio hecho en este
capítulo, dé de alta un nuevo usuario a través de la transacción “Customer”, y luego
pruebe agregar alguna película al carrito de compras.

2. El webcomponent “Login”, es el que tiene la lógica de seguridad para que el usuario

compre películas, y es importante que el usuario en cualquier parte del sitio se pueda
logear, y navegar por toda la aplicación hasta que opte por realizar una compra.
Entonces, el webcomponent Login debe estar en todos los webpanels del sitio.

INTRODUCCION AL CAPITULO 9
Existen otras características interesantes para el desarrollo de aplicaciones en el
web, que presentamos en este capítulo…

 WAP
 WebWrapper
 Manejo HTTP
 Funciones de acceso al header de un objeto Web
 Tipos de datos estructurados

INTERNET MOVIL (WAP)

Introducción
En los últimos años tanto Internet como la telefonía celular han tenido un gran crecimiento y
se han hecho accesibles a millones de personas. Es posible ahora unir estas dos tecnologías
accediendo de forma fácil y rápida a la información que brinda Internet desde los teléfonos
celulares (ó móviles).
A partir de esta versión GeneXus permite generar salidas para Internet móvil, generando
objetos con contenido WML.

Alcance
Objetos: WebPanels

Lenguajes: Visual Basic, Java, C/SQL y .NET

Interfaces: Web

Algunas definiciones
WAP (Wireless Aplication Protocol)
Es el protocolo más común de Internet Móvil.

Internet móvil es el término comercial para acceder a información de Internet a través de

dispositivos móviles.

Los dispositivos móviles más comunes son los teléfonos celulares con “microbrowser” pero
también entran en esta categoría, los dispositivos de tipo palm y cualquier dispositivo de
información portátil, que pueda disponer de una conexión inalámbrica.

Este protocolo consiste en un modelo de capas que incluyen un IP inalámbrico, capas de

seguridad (WSL) y lenguajes de descripción de contenidos entre ellos WML.

WML
Lenguaje de “tags” basado en XML. Es interpretado por los celulares WAP compatibles. Es
parecido al HTML, pero tiene menos potencia y soporta algunas cosas que el HTML no y es
bastante más estricto en la sintaxis.

WML vs HTML
Por el tamaño de la pantalla, es imposible traducir o ver de forma satisfactoria una página de
web normal (HTML) en un celular. El tamaño, los tipos de letra, las imágenes y la cantidad de
información que se soporta en el WEB no se puede soportar en un microbrowser y no es
práctico hacerlo.

La navegación, además, es diferente, el usuario no tiene ratón, ni teclado por lo que el ingreso
de datos debe ser limitado y la navegación, mucho más simple.

MicroBrowser
Es un software instalado en el teléfono o dispositivo inalámbrico que interpreta el WML (y el
WMLScript, WTAI, etc.) y despliega la información en la pantalla.
Es posible acceder a emuladores de celulares y sus microbrowser. Algunos de los más
conocidos son UP Browser (Unwired Planet) de Phone.com, RS380 Ericsson, Nokia, etc.

Arquitectura
La arquitectura es similar a Internet. El cliente es el teléfono celular con MicroBrowser y en el
servidor se encuentra la lógica en objetos (ejecutables o ASP) con contenido WML o sea que al
ser interpretados por los browsers generan WML.

Descripción
Para generar Web Panels con contenido WML, se implementó una nueva propiedad (a nivel de
objeto) denominada ‘Tag Language’.

Los valores de la propiedad son:

 HTML
 WML

El valor por defecto es HTML para cualquier objeto Internet.

Con el valor WML es posible generar objetos con contenido WML, estos podrán ser vistos
desde un browser WAP.

Requerimientos
Para testear esta característica directamente en la máquina de desarrollo es necesario tener
instalado el emulador de microbrowser.

Recomendamos el UP Browser (UP.SDK version 4.0) que es posible bajarlo de:

http://www.openwave.com/products/developer_products/sdk/

El producto es sin cargo, para acceder al mismo se debe realizar la registración en dicha
página.

El archivo ocupa aproximadamente 7 MB.

Diseño
Se deben definir los Web Panel como hasta el momento y configurar la propiedad ‘Tag
Language = WML’.

En el diseño del objeto se deben tener en cuenta las siguientes limitaciones del lenguaje
generado (WML):
  Los objetos WML están limitados en el tipo y cantidad de controles que se soportan
así como en el tamaño de las páginas debido a la cantidad de memoria de los móviles
y el tamaño de la pantalla.
 Las pantallas permiten entre 4 a 8 líneas de texto, dependiendo del móvil, por lo que
no se recomienda que las pantallas superen estos tamaños. No es conveniente que
se tenga scroll en una pantalla de teléfono celular.
 Solo se soportan los siguientes controles:
o Edit
o Textblocks
o Texto libre
o Tablas simples
o Subfile freestyles simples

 No se soportan
o Variables dentro de tablas
o Ninguna anidación de tablas y/o subfile freestyle
o Subfiles comunes
o Campos LongVarchar
o La letra ñ
o Tag <BR>
o Botones
o Cookies
o Encriptación de parámetros

 Las propiedades de runtime soportados son

o Link
o Ispassword
o Visible y
o Enabled.

 El softbutton del teléfono (botón que se encuentra en la parte superior izquierda), se

asocia al Evento Enter.
Ejecución
Luego de generado el objeto se debe ejecutar desde el emulador celular, esto se realiza
escribiendo la dirección donde se encuentra el Web Panel en la barra de direcciones del
mismo.

Ejemplo
Se desea desplegar un texto de prueba en un teléfono celular, los pasos a seguir son los
siguientes:

- Insertar el texto en un textblock en el form de un Web Panel.

Es aconsejable verificar el código generado, en el Tab ‘Source’, teniendo en cuenta las
consideraciones

- Especificar, generar y compilar el Web Panel desde GeneXus.

- Ejecutar el UP.Simulator.

- Escribir la dirección donde se encuentra el objeto (por ej. http://localhost/cgi-

bin/hPrueba.exe) en ‘Go’, y presionar Enter o el Softbutton.

- En el teléfono celular se visualizará el texto ingresado en el Web Panel.

- Si se producen errores en la pantalla del teléfono celular siempre se despliega el siguiente
mensaje:

‘Compile error: See info windows for details.’

El texto completo del error se debe visualizar en el ‘Phone information’ (ventana DOS que se
ejecuta detrás del emulador).

Hay un ejemplo disponible en :

http://www.gxtechnical.com/main/Hdcenter.aspx?2,5,36,408

Errores comunes
Error Síntoma

“Error : Invalid element ‘PCDATA’ in contents Se debe a la ausencia de <P> en textblock o

of card.” variable.

“Error : Invalid element ‘br’ in contents of Se debe a un tag <BR> en el Source del objeto
card.”

“Error : Uncompiled data from http <head>.” La página no es WML es HTML, se debe
configurar la preference ‘Tag Language=WML’

“Error : Invalid element ‘textarea’” Se esta usando un longvarchar o un char de

varias líneas.

“Error : Missing entity “ntilde” Hay algún dato con la letra ñ y el

microbrowser no lo puede interpretar.

“Error : Invalid element ‘P’ in content of ‘p’. Se introdujo algun tag <P> anidado, esto no es
excpectde PCDATA | em | b …” válido en WML

Consideraciones

 Consideraciones a tener en cuenta con el editor

o El editor no toma en cuenta algunas restricciones necesarias para WML y

puede generarse código no válido, es preciso en estos casos modificar el
source en el editor de diseño de GeneXus.

o No es posible hacer Cut & paste de controles y/o del Source.

o Existen algunos tags HTML (no válidos en WML) generados por el editor. Por
ejemplo el tag <BR> es generado por la combinación de teclas Shift+Enter en
el editor.

o Textblock y variables deben generarse entre <P> y </P>. La generación de

estos tags se da con un enter al final del edit o modificando Código en el Tab
‘Source’.

o Subfiles o tablas no deben limitarse por tags <P>. Es posible generar este
código con algunas combinaciones de teclas.

o Igualmente no es recomendable modificar el código WML (bajo el tab “HTML

Source” ) pues pueden dar errores en ejecución .
  No se reciben correctamente variables por parámetro en los llamados realizados
mediante “call”.

TIPO DE DATOS WEBWRAPPER

Introducción
WebWrapper es un nuevo tipo de datos de GeneXus que permite encapsular la ejecución de
los objetos Web (el código HTML generado). En particular permite enviar el contenido de un
Web Panel por mail.

Alcance
- Objetos: Transacciones, Work Panel, Web Panel, Procedimientos

- Lenguajes: Java - Visual Basic – C/SQL – .Net

- Interfaces: Web, Win

Descripción
Para poder enviar el contenido de un Web Panel vía mail desde un objeto GeneXus es
necesario definir una variable de tipo WebWrapper, para luego aplicar los métodos y
propiedades necesarios.

La idea es capturar el contenido de un Web Panel en su código HTML, y enviar este vía mail,
por lo tanto hay que tener en cuenta que el cliente de correo que reciba el mail debe tener la
capacidad de interpretar lenguaje HTML, en caso contrario verá el código del Web Panel.

Propiedades:

BaseURL Es la dirección Base del Web Panel

La dirección base determina el servidor y directorio virtual al que apuntarán los links y a donde
se irá a buscar el Web Panel en caso de que se presione algún botón. La dirección base es
agregada al código HTML que devuelve el método GetResponse.

Object
Objeto Web a encapsular en la variable de tipo WebWrapper

A la propiedad Object debe asignársele siempre el resultado de la función

Create( Objeto, Parámetros)

Metodos:
GetResponse

Retorna el código HTML que devolvería el objeto Web especificado en la propiedad

Source con los parámetros allí indicados.

Consideraciones Generales
Los objetos Web Panel de GeneXus, no son estáticos, por este motivo al enviarlos
vía mail, en realidad se está enviando una imagen estática. Por lo tanto cualquier
evento que se produzca en el Web Panel que realice un post al servidor ( por
ejemplo hacer click en un botón, disparar un procedimiento, etc) producirá que se
abra el web panel en el browser, en la dirección especificada en la propiedad
BaseURL.

Si se desea hacer un WebWrapper de un Web Panel que incluya imágenes, se

puede hacer de dos maneras:
 Poner en el Web Panel las imágenes en forma absoluta, el inconveniente de
esto es que el usuario debe estar conectado en el momento de leer el mail.
 Poner en el Web Panel las imágenes relativas y mandarlas como atachment
en en el mail. En este caso la ruta de la imagen no debe incluir directorios
(i.e. /imágenes/logo.jpg) si no hacer referencia directamente a la misma
(i.e. logo.jpg).

Si se utiliza un objeto WebWrapper para mandar un Web Panel mediante mail, y dicho Web
Panel tiene un botón o evento click, el comportamiento al apretar dicho botón (o control con
evento click) 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 redireccion, call o link, en el evento).

En Outlook XP el comportamiento es el siguiente: el POST lo hace el propio Outlook (no se abre

un browser para hacer el POST). Luego se abre un browser haciendo un GET de la página para
mostrarla. Pero dicho GET se hace solamente si no había una redirección en el evento que
ejecutó el POST. (De todas formas, el evento se ejecuta siempre).
Por ejemplo, si se tiene un evento asociado a un botón que graba algo en la base de datos y
asigna cierto valor a una variable que está en el form. En Outlook 2000 y Outlook Express, al
apretar dicho botón en el mensaje se ejecutará el evento, por lo que se hará el cambio a la
base de datos, y se abrirá un browser donde se verá en el form la variable con el valor que se
le asignó en el evento. En Outlook XP se ejecutará el evento, haciendo el cambio en la base de
datos, pero el form de respuesta nunca se mostrará. Luego se abrirá un browser donde se
desplegará el form SIN MODIFICAR LA VARIABLE.

Otro ejemplo: el evento asociado al botón modifica la base de datos y hace un call a otro
webpanel. En Outlook 2000 y Outlook XP, al apretar el botón se hace la modificación a la base
de datos y se abre un browser donde se muestra el Web Panel llamado. En Outlook XP se hace
la modificación a la base de datos pero no se muestra nada, ni siquiera se abre el browser.

Hay dos formas en las cuales podemos cambiar nuestra programación para asegurarnos de
que el comportamiento sea el mismo en los 3 clientes de mail:

1) No usar eventos. Siempre se pueden usar links.

2) Usar un Web Component. Es decir, el Web Panel que se manda por email está compuesto
solamente por un webcomponent. Dicho WebPanel tendría en el evento Refresh algo así:

Event Refresh

if base de datos fue modificada

webcomponent.object = create( HGracias, pars...)

else

webcomponent.object = create( HMailForm, pars...)

endif

End Event

En el evento de usuario de HMailForm se haría la modificación a la base de datos por la cual se

chequea en la condición. HGracias es el Web Panel al cual se quería hacer la redirección al
procesar el evento.
Consideraciones específicas del generador C/SQL
Al utilizar el tipo de dato WebWrapper con el generador C/SQL, hay que tener en cuenta los
siguientes factores:

 El objeto Web que se crea para enviar por mail por medio de la función Create no
puede ser main, si puede ser un WebComponent.
 La propiedad BaseUrl debe estar después de la función Create.

Consideraciones específicas del generador Visual

Basic
En caso de tener en el Web Panel que se envía como Web Wrapper Link o
Embedded Pages a objetos GeneXus del mismo modelo, se debe indicar la
preferencia del objeto “Generation Mode” en Smart Static Panel.

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 CLIENTE.
Dicha tabla tiene clave primaria CliCod, el cual se pasará como parámetros al
Hnotify. También tiene entre sus atributos secundarios a CliNom, con el nombre
del cliente, y CliMail, con la dirección de correo el electrónico del cliente.

Variables Definidas:
&Wrap del tipo WebWrapper
&MailMsg del tipo MailMessage
&Outlook del tipo OutlookSession

&Wrap.BaseURL = “http://myserver/mysystem/”
For each CliCod
&Wrap.Object = Create(Hnotify, CliCod)
&MailMsg.To.New(CliNom, CliMail)
&MailMsg.HTMLText = &Wrap.GetResponse()
&Oulook.Send(&MailMsg)
EndFor

TIPO DE DATOS HTTPCLIENT, HTTPRESPONSE

Y HTTPREQUEST

Introducción
Esta funcionalidad provee a los usuarios GeneXus una forma de poder utilizar el protocolo
HTTP en sus programas. Para ello se crearon los tipos de datos HttpClient, HttpResponse y
HttpRequest.
Alcance
Objetos: HttpClient (Transacciones, Work Panels, Web Transactions, Web Panels, Reportes,
Procedimientos), HttpResponse y HttpRequest (Procedimientos y Reportes con el valor http en
la propiedad call protocol, Web Panels y WebTransactions ).

Lenguajes: Java – Visual Basic – Visual Fox– C/SQL – C#.

Interfaces: Web Form, Win Form.

Descripción
Los tres tipos de datos que se definen para interactuar con http son:

HttpClient

Permite armar un request, enviarlo a una URL y leer los resultados.

HttpResponse y HttpRequest

Permiten leer los datos del request y grabar el response. Son objetos disponibles solo en
WebProcs.

HttpClient
Este objeto refleja una conexión http. Puede usarse desde cualquier objeto GeneXus.

PROPIEDADES:
Host
Define el nombre del host.
Tipo- String

Port
Define el puerto del host.
Tipo- String

Secure
Indica si el protocolo es http o https.
Tipo- Boolean

Timeout
Determina el Timeout de la conexión.
Tipo- Integer
 BaseURL
Indica la URL base de los request que se hagan al host.
Tipo- String
StatusCode
Retorna el código de error HTTP.
Tipo- Integer

ReasonLine
Retorna el texto del error HTTP.
Tipo- String

ErrCode
Retorna si ocurrió algún error en algún comando, en cuyo caso retorna un
valor distinto de cero.
Tipo- Integer

ErrDescription
Retorna el mensaje del error si ocurrió alguno en algún comando.
Tipo- String

Basic y Digest
Son constantes que determinan un tipo de autenticación. Se utilizan en el
método AddAuthentication.
Basic=0 : Para autentificar se envía el usuario y password sin encriptar.
Digest=1: Para autentificar se envía el usuario y password encriptados.

ProxyHost y ProxyPort
Permiten especificar un proxy http. En ambiente windows se utiliza
automáticamente el que esta configurado en la máquina.
ProxyHost- String
ProxyPort- Integer

MÉTODOS
AddHeader(<Name>, <Value>)
Agrega un header con el valor dado.
Ejemplo: AddHeader(“User-Agent”, “GeneXus”)
<Name>- String
<Value>- String

AddVariable(<Name>,<Value>)
Agrega una variable al ‘form’.

Ejemplo: AddVariable(“CliCod”, &CliCod)

<Name>- String
<Value>- String

AddString(<Value>)
Agrega el contenido del string al buffer de datos a enviar.
<Value>- String

AddFile(<Value>)
Agrega el contenido del archivo al buffer de datos a enviar.
<Value>- String
 Execute(<Method>,<URL>)
Ejecuta un método en la URL definida. Se pondría solo la parte final de la
URL
Ejemplo: execute("POST", "/servlet/awebproc")
<Method>- String
<URL>- String

ToString()
Retorna un String con todo el ‘cuerpo’ del response.

ToFile(<FileName>)
Graba en un archivo el contenido del stream.
<FileName>- String

GetHeader(<Name>,<Value>)
Retorna en <Value> el valor del header convertido al tipo de la variable.
<Name>- String
<Value>- Anytype

AddAuthentication(<Method>, <Realm>, <User>, <Password>)

Se autentifica con <User> y <Password> al dominio <Realm> utilizando el
tipo de autenticación <Method>
<Method>- Integer (Pueden utilizarse las propiedades Basic y Digest)
<Realm>- String
<User>- String
<Password>- String

HttpRequest
Este objeto permite leer el request http. Puede instanciarse solo en el contexto de un
WebProc.

PROPIEDADES
Method
Retorna el método HTTP.
Tipo- String

ServerHost
Retorna el nombre del servidor

Tipo- String

ServerPort
Retorna el puerto en el servidor
Tipo- Integer

Secure
Indica si se esta utilizando HTTPS. Si el valor retornado es 1, se esta
utilizando HTTPS; si es 0, se esta utilizando http.
Tipo- Integer

ScriptPath
Retorna la porción de URL correspondiente el nombre del directorio virtual.
 Tipo- String

ScriptName
Retorna el nombre del objeto con la extensión correspondiente que se esta
ejecutando, tal como aparece en la URL
Tipo- String

Referrer
Retorna la URL del llamador
Tipo-String

QueryString
Retorna la porción de la URL que está después del signo “?”; o sea los
parámetros.
Tipo- String

RemoteAddress
Devuelve la dirección del cliente.
Tipo- String

ErrCode
Retorna si ocurrió algún error en algún comando, en cuyo caso retorna un
valor distinto de cero.
Tipo- Integer

ErrDescrption
Retorna el menaje del error si ocurrió alguno en algún comando.
Tipo- String

MÉTODOS

GetVariable(<Variable>)

Retorna en un String el valor con el que viene cargada la

<Variable> en el post.
<Variable>- String

GetHeader(<Header>)
Retorna un String con el valor del header <Header>.
<Header>- String

ToString()
Retorna un String con todo el ‘cuerpo’ del request.

ToFile(<FileName>)
Graba en un archivo el contenido del stream.
<FileName>- String

HttpResponse
Este objeto permite escribir el response http. Puede instanciarse solo en el contexto de un
WebProc.
 PROPIEDADES

ErrCode
Retorna si ocurrió algún error en algún comando, en cuyo caso retorna un
valor distinto de cero.
Tipo- Integer

ErrDescrption
Retorna el menaje del error si ocurrió alguno en algún comando.
Tipo- String

METODOS
AddHeader(<Name>,<Value>)
Agrega un header con el valor dado.
Ejemplo: AddHeader(“User-Agent”, “GeneXus”)
<Name>- String
<Value>- String

AddString(<Value>)
Agrega el contenido del string al buffer de datos a enviar.
<Value>- String

AddFile(<Value>)
Agrega el contenido del archivo al buffer de datos a enviar.
<Value>- String

Interacción con XML

Estos objetos permiten la interacción con los objetos XMLReader y XMLWriter. Para ello
existen los siguientes métodos:

XMLReader.openRequest(HttpRequest)

Se utiliza en un WebProc para leer un xml que viene en el body del http request.

XMLReader.openResponse(HttpClient)

Se utiliza en cualquier objeto para leer como XML lo que devolvió un request.

XMLWriter.openRequest(HttpClient)

Se utiliza para enviar un XML en el body de un http request.

XMLWriter.openResponse(HttpResponse)

Se utiliza en un WebProc para escribir un xml que se retornara en el body del http response.

Ejemplo
Este ejemplo muestra como un objeto GeneXus llama a otro vía http, pasándole parámetros en
un XML y recibiendo los mismos también en un XML.

El XML a enviar tiene la forma

<parameters>

<a>valor</a>

<b>valor</b>

</parameters>

El XML que se devuelve es igual, con los valores de ‘A’ y ‘B’ modificados.

El programa ‘cliente’ sería:

&Client de tipo HttpClient

&Writer de tipo XMLWriter

&Reader de tipo XMLReader

// Determino el host y el puerto a donde hacer el request

&client.host = "localhost"

&client.port = 88

// Agrego el XML al request

 &writer.openRequest(&client)

&writer.WriteStartElement("parameters")

&writer.WriteElement("a", &A)

&writer.WriteElement("b", &B)

&writer.WriteEndElement()

&writer.close()

// Hago el POST al webproc

&client.execute("POST", "/servlet/awebproc")

// Leo el XML que devuelve y lo cargo en las variables internas

&reader.openResponse(&client)

&reader.read()

&reader.read()

&a = val(&reader.value)

&reader.read()

&b = val(&reader.value)

&reader.close()

El programa ‘servidor’ seria el siguiente WebProc:

&Request de tipo HttpRequest

&Response de tipo HttpResponse

&Writer de tipo XMLWriter

&Reader de tipo XMLReader

// Leo los parámetros del XML

&reader.openRequest(&Request)

&reader.read()

&reader.read()

&a = val(&reader.value)

&reader.read()

&b = val(&reader.value)

&reader.close()

// Le sumo uno a cada valor

&a = &a + 1

&b = &b + 1

// Grabo los parámetros en el response

&writer.openResponse(&Response)

&writer.WriteStartElement("parameters")

&writer.WriteElement("a", &A)

&writer.WriteElement("b", &B)

&writer.WriteEndElement()

&writer.close()
Consideraciones para el generador Java
En el caso de que se ejecute el motor de servlet en Windows, la aplicación obtendrá
automáticamente la configuración del proxy http y la lista de hosts para los que no se debe
utilizar el proxy.

En caso de que se ejecute en otra plataforma, es necesario especificar el proxy como una
‘System Property’ desde la línea de comandos del intérprete, por ej:

java -Dhttp.proxyHost=your.proxy.com -Dhttp.proxyPort=XX <mainclass>

(Consideraciones Generales)
 La propiedad secure del tipo de datos HTTPClient en el generador C/SQL solo puede Con formato: Numeración y viñetas
ser utilizada en clientes Microsoft.

 En los generadores Visual Basic, Visual FoxPro, y C/Sql el tipo de datos HTTPClient Con formato: Numeración y viñetas
permite manipular solamente URLs cuyo Response tenga contenido de tipo texto. No
esta implementado para otros tipos de contenido (por ej. imágenes).

ACCESO AL HEADER DE UN OBJETO WEB

Alcance
Objetos: Web Panels, Transacciones

Lenguajes: C/SQL, Java, Visual Basic, .Net

Interfaz: Web

Introducción
Se introducen controles, con métodos y propiedades para manejar TAG en el header de un
objeto Web. Esto posibilita agregar información descriptiva, que puede utilizarse para ser
referenciado por buscadores, agregar referencias a JavaScript para dar dinamismo a la
aplicación o todo aquello que se pueda definir entre los TAgs <Head></Head> para aprovechar
al máximo las características del HTML.

Descripción
Se denomina Header de un objeto WEB a código HTML definido entre los TAGS <HEAD>
</HEAD>.

Se puede agregar información en el Header, que puede servir, entre otras cosas, para ser
referenciado por buscadores, o simplemente para agregar funcionalidades a la página, como
es el caso de JavaScript.

Dicha información se debe agregar en forma de Tag.

Los Tags HTML que GeneXus permite agregar son:

<meta name=X content=Y/>

<meta http-equiv=X content=Y/>

<script language="JavaScript" src="Y”>

Además permite introducir código libre directamente en el <head> </head>

Para poder trabajar con estos Tag, se implementaron una serie de propiedades y métodos del
Form:

Form.Meta
Esta propiedad permite trabajar con los TAG de la forma <meta name=X content=Y/>.

Los métodos correspondientes son:

AddItem
Permite agregar un TAG <meta name=X content=Y/>, a partir de los valores X e Y pasados por
parámetros

Sintaxis:

Form.Meta.AddItem(<name>,<content>)

Donde

<name>, <content> : Character

Por ejemplo GeneXus agrega por defecto al form el Tag:

<meta name="Generator" content="GeneXus .NET”> Para indicar con que generador fue
creado el objeto.

RemoveItem

Permite eliminar un TAG <meta name=X content=Y/>, a partir del valor X.

Sintaxis:

Form.Meta.Remove(<name>)

Donde

<name> : Character

Text

Retorna el valor correspondiente al name del TAG referenciado.

Sintaxis:

Form.Meta.Text(<indice>)
Donde:

<Indice> : Numérico que representa el número de Tag Meta en el Form

Valor de retorno: Character

Value

Retorna el valor correspondiente al content del TAG referenciado.

Sintaxis:

Form.Meta.Value(<indice>)

Donde:

<Indice> : Numérico, que representa el número de Tag Meta en el Form

Valor de retorno: Character

Count

Retorna la cantidad de TAG de la forma correspondiente

Sintaxis:

Form.Meta.Count

Valor de Retorno: Numérico

Clear

Elimina todos los TAG de la forma correspondiente

Sintaxis:

Form.Meta.Clear()
Form.MetaEquiv
Esta propiedad permite trabajar con los TAG de la forma <meta http-equiv=X content=Y/>.

Los métodos correspondientes son:

AddItem

Permite agregar un TAG <meta http-equiv=X content=Y/>, a partir de los valores X e Y pasados
por parámetros

Sintaxis:

Form.MetaEquiv.AddItem(<name>,<content>)

Donde

<name>, <content> : Character

RemoveItem

Permite eliminar un TAG <meta http-equiv=X content=Y/>, a partir del valor X.

Sintaxis:

Form.MetaEquiv.Remove(<name>)

Donde

<name> : Character
Text

Retorna el valor correspondiente al name del TAG referenciado.

Sintaxis:

Form.MetaEquiv.Text(<indice>)

Donde:

<Indice> : Numérico, que representa el número de Tag MetaEquiv en el Form

Valor de retorno: Character

Value

Retorna el valor correspondiente al content del TAG referenciado.

Sintaxis:

Form.MetaEquiv.Value(<indice>)

Donde:

<Indice> : Numérico, que representa el número de Tag MetaEquiv en el Form

Valor de retorno: Character

Count

Retorna la cantidad de TAG de la forma correspondiente

Sintaxis:

Form.MetaEquiv.Count
Valor de Retorno: Numérico

Clear

Elimina todos los TAG de la forma correspondiente

Sintaxis:

Form.Meta.Clear()

Form.JScriptSrc
Permite referenciar fuentes con código JavaScript que se deseen incluir en el Header de la
página generada, de la forma <script language="JavaScript" src="Y”>

Los métodos correspondientes son:

Add

Agrega un TAG de la forma antes descrita.

Sintaxis:

Form.JScriptSrc.Add(<src>)

Donde:

<src> :Carácter, nombre del arcjivo js con el JavaScript definido

(ej: “ValidarFecha.js”)

Clear

Elimina todas las instancias del TAG

Sintaxis:

Form.JScriptSrc.Clear()

Item

Retorna el elemento correspondiente al src del tag referenciado

Sintaxis:

Form.JScriptSrc.Item(<Indice>)

Donde:

<Indice>:Numérico, que representa el número de Tag JScriptSrc en el Form

Valor de Retorno: Character

Count

Retorna la cantidad de TAG de la forma correspondiente

Sintaxis:

Form.JScriptSrc.Count

Valor de Retorno: Númerico

Form.HeaderRawHTML
Esta propiedad del form permite agregar texto libre en el Header (los Tag <head> </head>)
Sintaxis:

Form.HeaderRawHTML = <Texto>

Donde:

<Texto>: Character

Consideraciones
 GeneXus agrega por defecto en los objetos web los tags Generator, Version y
Description de tipo Meta Name. Por ejemplo:

<meta name="Generator" content="GeneXus C#"/>

<meta name="Version" content="7_6_0-034"/>
<meta name="Description" content="webPanel"/>

TIPOS DE DATOS ESTRUCTURADOS

Alcance
Objetos: Transactions, Work Panels, Web Panels, Procedures, Reports
Lenguajes: Java, .NET, Visual Basic
Interfaces: Web, Win

Introducción
El objeto GeneXus Structured Data Type (SDT), permite definir estructuras de datos. Estas
representan, de una forma simple, datos cuya estructura está compuesta por varios
elementos. Esto facilita y potencia la programación.

Descripción
Los SDT tienen múltiples usos posibles:
 - facilitan el pasaje de parámetros (en particular permite proveer/consumir
información estructurada en el uso de webservices)
- simplifican la lectura y escritura automática de XML (con funciones de alto nivel),
- permite mejorar la legibilidad del código,
- permite el manejo de listas de largo variables de elementos.
Detallamos algunos de los posibles casos de uso.

Se podrán definir variables, en cualquier objeto, basados en un objeto estructurado (SDT) o

una estructura definida en el.

En Edición el objeto tiene dos secciones

- Estructura : aquí mediante un editor es posible definir la estructura del objeto.

- Documentación : documentación del objeto.
Como todos los objetos GeneXus, también tiene asociado un conjunto de propiedades y
métodos.

Estructura
La estructura puede ser multinivel, semejante a la de las transacciones, cada nivel puede tener
uno o más elementos (o ítems). Podemos clasificarlos en elementos simples o elementos
compuestos (por otros elemento).

ELEMENTOS SIMPLES
En el diseño de un SDT, al definir un elemento, se debe especificar la propiedad Name que
identifica al elemento, por lo tanto no pueden existir dos elementos con el mismo nombre. La
propiedad Data type permite seleccionar entre los siguientes tipos de datos :

- Tipos básicos de GeneXus (numérico, date, etc.)

- Dominios
- otro SDT ya definido.

La propiedad Collection indica si el elemento tiene o no múltiples instancias (puede repetirse).

Tiene dos valores posibles, True o False

ELEMENTOS COMPUESTOS
Se identifican con un bullet de color, en el editor, y son aquellos que definen un nuevo
agrupamiento de elementos (una nueva colección o un agrupamiento de elementos simples).
Tiene las mismas propiedades que los elementos simples, pero no se habilita la propiedad
data type. Hay una excepción en el caso de un SDT que sea colección de tipo simple, ver caso
de uso 2.3

Se habilita la propiedad Item Name solo cuando el elemento compuesto define una Collection
(propiedad Collection en True).Esta propiedad indica el nombre de cada uno de sus elementos.
Este nombre, calificado por el nombre del SDT, será seleccionable como tipo de datos para la
definición de variables, esto significa que se crearan dos tipos de datos uno con el “Name”
(nombre del SDT) y otro con Name.ItemName.

Documentación
Permite escribir un texto descriptivo del objeto.

Propiedades del objeto

El objeto SDT tiene un Name que lo identifica, por lo tanto no es posible definir
un SDT con el nombre de otro objeto. El formato es el mismo de los objetos
GeneXus en cuanto a caracteres válidos para inicio, caracteres siguientes al
primero válidos, cantidad de caracteres, etc.
Tiene un Description y un External Name. Este último es el nombre con el que se publica el
tipo de datos en el WSDL, para el caso de Webservices. El valor por defecto es el de la
propiedad Name.

La propiedad External Namespace es un string que representa el name space que aplica al
External name (WSDL). El valor por defecto es el nombre del modelo sustituyendo los
caracteres no válidos.

Operadores
NEW
Este operador retorna una nueva instancia inicializada, o sea una nueva referencia al tipo de
datos que se especifica. La sintáxis es:

New SDTName()

SDTName es el nombre de un SDT o un ítem de una collection (cualquiera que pueda ser el
tipo de datos de una variable). Por ejemplo

A = New Client() o

ClientList.Add( New Client())

Desde la opción Insert/SDT (o con ctrl. + Space) es posible incluir un estructurado.

Métodos
Cualquier SDT tiene los métodos que se describen a continuación.

TOXML
Retorna un string con el formato XML de los datos de la variable SDT.

Sintaxis: &a = &b.ToXml()

devuelve la representación XML del contenido de &b en la variable &a

El XML resultante tiene la siguiente estructura:

 La raíz del XML tiene el nombre de la estructura.

 Un nodo para cada elemento simple. El nombre del nodo será el valor de la propiedad
Name de dicho elemento.
 Un nodo para cada elemento compuesto. El nombre del nodo será el valor de la
propiedad Name de dicho elemento. No tendrá valores sino los nodos
correspondientes a su composición.
 En el caso de colecciones simples define un elemento item por cada campo

Por ejemplo con un estructurado de país:

el contenido del string resultado seria:

<Pais xmlns = “name_Kb”>

<Nombre>Uruguay</Nombre>

<Idioma>Español</Idioma>

<Coordenadas>

<Latitud>30</Latitud >

<Longitud>35</Longitud>

</Coordenadas>
 <Ciudades>

<item> Montevideo </item>

<item> Paysandú </item>

</Ciudades>

FROMXML
Es el opuesto del ToXML. recibe como parámetro un string que tiene una estructura XML
desde la cual se carga el SDT.

Sintaxis: &b.FromXml( &a)

carga la estructura &b a partir del contenido de la variable &a.

CLONE
Crea una nueva área de memoria y copia los datos de la variable en esta. Sintaxis:
&var1 = &var2.clone()

Siempre debe estra asignado a una variable, la única excepción es dentro del comando Add

&var1.add(var2.clone())

Método clone vs Operador New

El método Clone equivale a new de una variable y la asignación de cada item de la misma o
sea:

Z = Y.clone()  Z = New SDT()

z.a = y.a

z.b = y.b

Siendo a y b los elementos del estructurado SDT

Notar que la asignación Z = Y simplemente redirecciona ambas variables al misma área de

memoria y al modificar una estoy modificando la otra.

La ventaja del método clone, frente al new, es que realiza la copia automática de cada item del
estructurado sin necesidad de hacer la asignación.

En el caso de subestructuras dentro del SDT (colecciones o no) no se crea una nueva instancia
de ésta con el método clone (la copia es shallow), es necesario hacer un new o clone explicito
por cada subestructura. En el caso de subestructuras “definidas” dentro del SDT, que no sean
colecciones no esta habilitado el método clone. Por ejemplo, con el SDT

Pais

Nombre Char

Continente

Nombre Char

&Pais.Nombre = 'Uruguay'

&Pais.Continente.Nombre = 'América'
&Paises.Add(&Pais.clone())

&Pais.Nombre = 'Senegal'

&Pais.Continente.Nombre = 'Africa'
&Paises.Add(&Pais.clone())

En ambos países el continente es Africa. Para que cada registro tenga distinto continente se
debe programar con el operador new.

Collections
Existen un conjunto de métodos y propiedades que solo aplican a colecciones de SDT.

La propiedad Count retorna la cantidad de elementos de la colección. Es read only.

Los siguientes métodos solo aplican a SDT que sean colecciones :

 Add( Item[, Position])

Agrega Item en la posición relativa Position de la collection. Si se omite Position o se

especifica “0”, se agrega el Item al final de la collection. Position comienza en 1.

 Item( Position)

Retorna una referencia al elemento con posición relativa Position en la collection. En

caso de especificar posición (de un item de colección ) mayor a la ultima, el programa
cancela.

No es válido asignar un valor con esta propiedad, por lo tanto no es correcto el código
&sdt.item(&i) = Att, para cambiar un valor se debe remover (método remove) y
agregar (método add)
  Remove( Position)

Elimina el elemento en la posición relativa Position de la collection y corre un lugar

todas las posiciones.

 Clear()

Elimina todos los elementos de la collection.

 IndexOf( Item)

Retorna la posición relativa de Item en la collection. 0 (cero) si Item no esta en la

collection.

Tener en cuenta que este método trabaja con las referencias de los elementos y no
con su contenido. Esto implica que si por parámetro se recibe una variable con una
lista de SDT y se carga una variable temporal con el contenido de un item, IndexOf
devolverá 0 (vacío) pues esa referencia no esta dentro de la lista. Puede resultar útil
únicamente al momento de cargar la lista.

Consideraciones
DEFINICIÓN DE VARIABLES
Para cada SDT se define un tipo de datos y otro por cada uno de los Items de sus collections.
Por ejemplo Si se define una colección de Ciudades, se define un tipo de datos Ciudades y otro
Ciudades.Ciudad

Las variables cuyo tipo sea una SDT no pueden ser vectores o matrices.

PASAJE DE PARÁMETROS
No es posible referenciar variables de tipo SDT en:

 parámetro de Objetos Web

 parámetro de Objeto Main con Call protocol Command line

Si bien no se controla, no es posible definir en la rule parm un item de una SDT, por ejemplo:
Parm(&sdt.item)

DISPARO DE RULES
Se deben instanciar los elementos de una variable SDT, para poder disparar rules que
dependen de dicha variable. Para esto se debe cumplir al menos una de las siguientes
condiciones:

 asignar el elemento del SDT en el evento Start o en una regla

 inicializar a la variable SDT:
 - new en Evento Start o
- parámetro de Trn o
- parámetro en Call en el evento Start.

ASIGNACIÓN
La asignación de una variable de tipo Structure a otra del mismo tipo implica un incremento en
la cantidad de referencias a la estructura. Hecha la asignación, una modificación a cualquier
elemento de la estructura se verá reflejado en todas las variables que "apunten" a la
estructura.

Por ejemplo en el código:

&Pais.PaisNom = ‘Uruguay’

&PaisAux = &Pais

&PaisAux.PaisNom = ‘Brasil’

&PaisNom = &Pais.PaisNom

La variable PaisNom tiene el valor ‘Brasil’, pues la dirección de la variable Pais y PaisAux es la
misma luego de la asignación

FORM
No es posible incluir un SDT en el form o printblock de un objeto, en ese caso ocurrirá un error
de spec “spc0071: '%1 cannot be displayed or printed due to its data type (%2)”

RECORRIDA
Para recorrer una colección de elementos, es posible hacerlo con el comando for in array

For &pais in &paises

&paisCod = &pais.Codigo

&PaisNom = &pais.Nombre

Load

Endfor
O con el comando do while:

Do while &I<= &Paises.Count

&Pais =&Paises.Item(&I)

...

&I=&I+1

Enddo

INTEGRIDAD
No es posible eliminar un SDT que esta siendo utilizado por otro objeto.

Si es posible modificar la estructura de un SDT y por ejemplo eliminar un elemento del mismo,
aunque este siendo referenciado por otro objeto.

ESPECIFICACIÓN Y GENERACIÓN
No es posible especificarse/generarse directamente un SDT. La especificación/generación es
implícita cuando se especifica un objeto que lo utiliza si el SDT cambió desde la última vez que
fue especificado o se realiza una generación forzada.

Las variables definidas como estructuras son ignorada si la especificación es para lenguajes que
no las soportan (RPG, Cobol, etc.). Esto evitará errores de generación si las variables no son
utilizadas (esta parte corre por cuenta del desarrollador).

KNOWLEDGE MANAGER
Si es posible exportar/consolidar un objeto SDT, al exportar un objeto que usa un SDT, se
exportan automáticamente los SDT llamados.

Si se exporta un objeto que contiene variables que son estructuras a un modelo que no
contiene la definición de dichas estructuras aparecerá, al especificar, el mensaje: spc0056,
Internal error. Variable %1 definition is incorrect or not available. Data:%2.

En el diálogo de consolidación se agrega un nuevo valor “SDTs” a la opción “Do NOT

overwrite”, esto permite sobrescribir o no las definiciones de los SDT de la knowledge Base
consolidada.
 LISTADOS
Si es posible listar los objetos SDT desde List/Object, o ver el arbol de llamadas desde
List/Browser

WEBSERVICES
Los Web Services normalmente retornan valores en estructuras de datos. Por ejemplo,
retornan un "Cliente" que es una estructura que tiene "Codigo" y "Nombre" que a su vez es
otra estructura que tiene "PrimerNombre", "SegundoNombre", etc.

Ahora es posible acceder a estos datos con variables de tipo "Cliente" y modificar/acceder a
sus "miembros"

Al consumir un servicio, con el WSDL Inspector, en el caso de recibir datos complejos, este
incluirá por lo tanto nuevas definiciones de SDT

RECURSIVIDAD
No son soportadas las definiciones recursivas. El Data type de una elemento de una estructura
no puede ser el mismo que se esta definiendo.

INTRODUCCION AL CAPITULO 10
Cada vez se escucha mas el concepto de ‘Web Services’, fundamentalmente
relacionado con Internet y el futuro de una arquitectura orientada a servicios. Es
por esta razón, que GENEXUS incluye la posibilidad de desarrollar y consumir Web
Services.

Comenzaremos con una introducción al concepto de Web Services para luego

realizar ejercicios prácticos que permitan profundizar los conocimientos adquiridos.
WEB SERVICES

Abstract
En los últimos tiempos ha surgido con mucha fuerza el concepto de ‘web services’, incluso
afirmándose que el mismo cambiaría la forma de programar las aplicaciones orientadas a
Internet hacia una arquitectura orientada a servicios. Todo esto se ha visto potenciado luego
del anuncio de Microsoft de su nueva estrategia .NET que está basada en el modelo de web
services.

Este documento describe que son los web services y como es la arquitectura general del
modelo, adicionalmente se provee una introducción de los estándares en los cuales se basa
este modelo como ser SOAP, WSDL y UDDI.

¿Qué es un web service?

Un web service es una aplicación que puede ser descripta, publicada, localizada e invocada a
través de una red, generalmente Internet. Combinan los mejores aspectos del desarrollo
basado en componentes y la Web.

Al igual que los componentes, los web services son funcionalidades que se encuentran dentro
de una caja negra, que pueden ser reutilizados sin preocuparse de cómo fueron
implementados. A diferencia de la actual tecnología de componentes, no son accedidos por
medio de protocolos específicos del modelo de objetos como ser RMI, DCOM o IIOP; sino que
son accedidos utilizando protocolos web como ser HTTP y XML.

La interface de los web services esta definida en términos de los mensajes que el mismo
acepta y retorna, por lo cual los consumidores de los web services pueden ser implementados
en cualquier plataforma y en cualquier lenguaje de programación, solo tiene que poder crear y
consumir los mensajes definidos por la interface de los web services.

El modelo de web services.

La arquitectura básica del modelo de web services describe a un consumidor, un proveedor y
ocasionalmente un corredor (broker). Relacionados con estos agentes están las operaciones de
publicar, encontrar y enlazar.

La idea básica consiste en que un proveedor publica su servicios en un corredor, luego un

consumidor se conecta el 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.

Proveedor

Publicar Enlazar

Corredor Consumidor

Encontrar

Por todo lo anterior hay ciertos requerimientos a la hora de desarrollar o consumir un web
services:

 Una forma estándar de representar los datos.

XML es la opción obvia para este requerimiento.

 Un formato común y extensible de mensajes.

SOAP es el elegido en este caso; SOAP es un protocolo liviano para el
intercambio de información. Más adelante en este documento lo veremos
con más detalle.
 Un lenguaje común y extensible para describir los servicios.
La opción en este caso es WSDL. Es un lenguaje basado en XML
desarrollado en forma conjunta por IBM y Microsoft. Lo veremos con más
detalle mas adelante en este documento.
 Una forma de descubrir los servicios en Internet.
UDDI se utiliza en este caso; el mismo especifica un mecanismo para publicar y
localizar los servicios por parte de los proveedores y consumidores respectivamente.
Se verá con más detalle mas adelante en este documento.

Ventajas y retos.
Los web services apuntan a ser la piedra fundamental de la nueva generación de sistemas
distribuidos. Estos son algunos puntos para fundamentar esta afirmación:

 Interoperabilidad:
Cualquier web service puede interactuar con otro web service. Como los
web services pueden ser implementados en cualquier lenguaje, los
desarrolladores no necesitan cambiar sus ambientes de desarrollo para
producir o consumir web services.
 Ubicuidad:
 Los web services se comunican utilizando HTTP y XML. Por lo tanto cualquier
dispositivo que soporte estas tecnologías pueden implementar o acceder web services.
Muy pronto estarán presentes en teléfonos, autos e incluso máquinas expendedoras,
las que avisarán a la central cuando el stock sea menor al indicado.

 Encapsular reduce la comlejidad

Todos los componentes en un modelo de web services son web service. Lo
importante es la interface que el servicio provee y no como esta
implementado, por lo cual la complejidad se reduce.
 Fácil de utilizar:
El concepto detrás de los web services es fácil de entender, incluso existen
toolkits de vendedores como IBM o Microsoft que permiten a los
desarrolladores crear web services en forma rápida y fácil.
 Soporte de la Industria:
Todos las empresas de software importantes soportan SOAP, e incluso
están impulsando el desarrollo de web services. Por ejemplo la nueva
plataforma de Microsoft .NET esta basada en web services, haciendo muy
simple el desarrollo de los mismos que luego podrían ser consumidos por
un web service desarrollado utilizando VisualAge de IBM y viceversa.

A la vez hay ciertos retos técnicos que los web services tienen que sortear para
poder tener éxito. Muchos de estos retos están relacionados con el ambiente
abierto en el que tienen que sobrevivir. Estos son algunos de esos puntos:
 Descubrimiento:
¿Como un web service se anuncia para ser descubierto por otro servicio?
¿Qué pasa si el servicio se cambio o se movió luego de ser anunciado?
WSDL y UDDI son dos nuevos estándares que manejan este punto.
 Confiabilidad:
Algunos web services son más confiables que otros. ¿Cómo puede ser
medida esa confiabilidad y comunicada? ¿Qué pasa cuando un web service
esta off-line en forma temporaria? ¿Localizamos y utilizamos un servicio
alternativo brindado por otra empresa o esperamos a que el servicio este
de nuevo on-line?
 Seguridad:
Muchos web services son publicados para ser utilizados sin ninguna
restricción, pero muchos otros van a necesitar autenticación para que los
utilicen solo los usuarios autorizados. ¿Cómo autentifica a los usuarios un
web service? ¿Lo hace a nivel del método que lo implementa o utiliza otro
web service para realizar la autenticación?
 Responsabilidad
En caso de que el web service no sea de acceso libre, ¿Cómo puedo definir
cuantas veces un consumidor puede acceder al web service una vez
contratado? ¿Cómo se cobra su uso? ¿Cómo se indica que un servicio ya no
esta más en línea?
Tecnologías asociadas
El modelo de web services está basado en ciertas tecnologías emergente que es el resultado
del trabajo de varias compañías y organizaciones entre las cuales se destacan IBM y Microsoft.

Estas tecnologías son SOAP, WSDL y UUDI.

SOAP (Simple Object Access Protocol)

SOAP es un protocolo para el intercambio de información en un ambiente descentralizado y
distribuido. Es el protocolo más utilizado para realizar el intercambio de información en el
modelo de web services.

Esta basado en XML y potencialmente puede ser utilizado en combinación con una variedad de
protocolos de comunicación, siendo el más utilizado HTTP. Por lo tanto se utiliza HTTP para
transportar la información, y XML para representar la misma.

El protocolo completo se puede encontrar en http://www.w3.org/TR/soap

EL MODELO DE COMUNICACIÓN DE SOAP

El modelo de comunicación de SOAP es muy similar al de HTTP. Un cliente hace un
requerimiento (request), el servidor que esta escuchando los requerimientos lo atiene y
responde (response) brindando la información solicitada o enviando un mensaje de error en
caso de que el requerimiento no haya sido válido.

El mensaje SOAP consiste en un elemento envelope SOAP obligatorio, un cabezal SOAP

opcional y un cuerpo SOAP obligatorio como un documento XML. El cabezal SOAP es utilizado
para definir información acerca del requerimiento, mientras que el cuerpo SOAP contiene el
método llamado y los parámetros con los que se llama al mismo.

Request

Cliente Servidor
Response

Todo esto es un modelo de mensajes request/response con una forma de describir un

conjunto de métodos y pasarle a los mismos parámetros. Esto parece la base del protocolo
RPC y de hecho es el uso más común de SOAP. El potencial es entregar esto sobre Internet
utilizando HTTP para realizar comunicaciones entre organizaciones permitiendo realizar
comunicaciones entre aplicaciones con diferente plataforma, sistema operativo y lenguaje de
programación.

A continuación se muestra un mensaje SOAP embebido en un request HTTP:

POST /StockQuote HTTP/1.1

Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>

Este ejemplo invoca al servicio StockQuote llamando al método GetLastTradePrice con el

símbolo DIS por parámetro.

Este es la respuesta al requerimiento anterior, el cual retorna el precio de la acción solicitada:

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="Some-URI">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
Si usted quedo asustado por la aparente complejidad del protocolo SOAP pensando lo
engorroso que sería armar los mensajes de requerimiento y parsear los mensajes de respuesta
despreocúpese; la mayoría de los lenguajes de programación proveen o proveerán soporte
para realizar esto. La idea fundamental consiste en utilizar algún objeto al cual se le brinda un
WSDL y se le indica que método se quiere llamar y con que parámetros. Esto arma en tiempo
de ejecución el mensaje SOAP, lo manda y parsea el resultado adjudicándoselo a alguna
variable en forma trasparente para el usuario como si hubiera hecho un call común.

WSDL: Web Services Description Language

WSDL es un lenguaje basado en XML que se utiliza para describir un Web Services. Ha sido
suministrado por la W3C por estandarización.

Un archivo con formato WSDL provee información de los distintos métodos (operaciones) que
el Web Services brinda, muestra cómo accederlos y que formatos deben de tener los mensajes
que se envían y se reciben. Es como un contrato entre el proveedor del servicio y el cliente, en
el cual el proveedor se compromete a brindar ciertos servicios solo si el cliente envía un
requerimiento con determinado formato. Es el documento principal a lo hora de documentar
un Web Services, pero puede no ser el único. En la mayoría de los casos es conveniente que
este acompañado por un documento escrito en lenguaje natural que brinde información de
que es lo que hace cada uno de los métodos brindados por el Web Services así como también
ejemplos, por ejemplo, de los mensajes SOAP que espera y responde el servicio.

En forma resumida podríamos decir que un archivo WSDL describe lo siguiente:

 Mensajes que el servicio espera y mensajes que el servicio responde.

 Protocolos que el servicio soporta.
 A donde mandar los mensajes.

FORMATO DE UN ARCHIVO WSDL:

A continuación se muestra como es el formato básico de un archivo WSDL. La especificación
completa de este lenguaje se puede encontrar en http://www.w3.org/TR/wsdl.html

Un archivo con formato WSDL básicamente contiene los siguientes elementos:

Type: Describe los tipos no estándar usados por los mensajes (Message).

Message: Define los datos que contienen los mensajes pasados de un punto a otro.
PortType: Define una colección de operaciones brindadas por el servicio. Cada operación tiene
un mensaje de entrada y uno de salida que se corresponde con algún Message antes definido.

Binding: Describe los protocolos que se utilizan para llevar a cabo la comunicación en un
determinado PortType; actualmente los protocolos soportados son SOAP, HTTP GET, HTTP
POST y MIME, siendo SOAP el más utilizado.

Port: Define una dirección (URL) para un determinado Binding

Service: Define una colección de Ports.

El siguiente es un ejemplo de archivo WSDL:

El mismo define dos mensajes (Simple.foo y Simple.fooResponse), luego define un método

llamado “foo” el cual recibe el mensaje Simple.foo y retorna el mensaje Simple.fooResponse. A
continuación se define un binding para el método foo asociándolo con el protocolo SOAP. Por
último se da una URL física que implementa lo antes descrito.
<?xml version="1.0" encoding="UTF-8" ?>

<definitions name="FooSample"

targetNamespace=http://tempuri.org/wsdl/

xmlns:wsdlns=http://tempuri.org/wsdl/

xmlns:typens=http://tempuri.org/xsd

xmlns:xsd=http://www.w3.org/2001/XMLSchema

xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/

xmlns:stk=http://schemas.microsoft.com/soaptoolkit/wsdl-extension

xmlns="http://schemas.xmlsoap.org/wsdl/">

<message name="Simple.foo">

<part name="arg" type="xsd:int"/>

</message>

<message name="Simple.fooResponse">

<part name="result" type="xsd:int"/>

</message>

<portType name="SimplePortType">

INTERFASE E IMPLEMENTACIÓN
La estructura básica de archivo con formato WSDL podría ser dividido en dos partes lógicas: la
interfase del servicio, y la implementación del mismo.

Esta división lógica divide los elementos de la siguiente forma:

Interface del servicio:

Type, Message, PortType, Binding.

Contiene una definición abstracta y reusable del servicio que puede ser instanciada y
referenciada por distintos proveedores del mismo.

Implementación del servicio:

Port, Service.

Contiene una implementación de una determinada Interface del servicio.

A partir de esta división lógica se puede definir por medio de una Interfase del servicio una
estándar para realizar, por ejemplo, ordenes de compras que puede ser reutilizada e
implementada por todas las empresas, sin tener que redefinir cada una de ellas la interfase.

Si al igual que con SOAP se siente preocupado por la complejidad de los archivos WSDL de
nuevo despreocúpese; la mayoría de los lenguajes de programación proveen o proveerán
herramientas para generar en forma automática el archivo WSDL a partir de un determinado
método o función.

UDDI (Universal Description, Discovery and Integration).

UDDI (www.uddi.org) es un proyecto inicialmente propuesto por Ariba, Microsoft e IBM; es un
estándar para registrar y descubrir web services. La idea es que las distintas empresas
registran su información acerca de los web services que proveen para que puedan ser
descubiertas y utilizadas por potenciales usuarios.

La información es ingresada al registro de empresas UDDI, un servicio lógicamente

centralizado, y físicamente distribuido a través de múltiples nodos los cuales replican su
información en forma regular. Una vez que una empresa se registra en un determinado nodo
del registro de empresas UDDI la información es replicada a los otros nodos y queda disponible
para ser descubierta por otras empresas.

EL ESQUEMA UDDI
El modelo de información base utilizado por los registros UDDI es definido en un esquema
XML. Este esquema define cuatro tipos básicos de información, cada uno de los cuales proveen
la clase de información que un usuario necesita saber para utilizar un web service de otra
empresa.

Los cuatro tipos de información son:

 Información del negocio.

 Este tipo de información esta definido en el elemento
businessEntity. Contiene información de la empresa, como ser su nombre,
los contactos, el tipo de empresa, etc.

 Información del servicio.

Dentro del elemento businnessEntity se encuentran los elementos
businessServices, estos elementos contienen información sobre web
services generalmente agrupados por procesos de negocio o categorías de
servicios.

 Información del enlace (binding).

Dentro de cada elemento businessServices se encuentran los elementos
bindingTemplate. Cada uno de ellos brinda una dirección fisica para hacer contacto
con los servicios descriptos anteriormente.

 Información sobre las especificaciones del servicio.

Cada bindingTemplate tiene asociado un tModel, el cual brinda
informacíon sobre las especificaciones del servicio, por ejemplo, como
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 especificaión del servicio. Utilizando entonces los
tModels se pueden encontrar todas las empresas que brindan tal servicio.

businessEntity

tModel

businnessEntity

bindingTemplate

Por más información sobre el esquema UDDI:

http://www.uddi.org/pubs/ProgrammersAPI_v2.pdf

API UDDI
El acceso al registro UDDI, ya sea para realizar búsquedas o para ingresar o
modificar un registro, se puede realizar a través de una página web que
implemente el acceso o utilizando ciertas interfaces (web services) que provee la
especificación de UDDI. Estas interfaces están descriptas en una API, que puede
ser dividida en dos partes lógicas, la API de consultas y la API de publicación.
Por más información sobre la API UDDI: http://www.uddi.org/pubs/ProgrammersAPI_v2.pdf
Un ejemplo
Las formas en que se puede realizar negocios utilizando web services es muy variada. El
consumidor podría pagar por utilizar los servicios brindados por un proveedor, o el proveedor
podría pagar para que aparezcan los servicios que él ofrece en un determinado consumidor, o
incluso existen casos en los cuales ni el consumidor ni el proveedor pagan por consumir o
proveer los servicios en forma respectiva. Este es el caso que se presenta a continuación.

El ejemplo es tomado de la vida real y es sobre la compañía aérea Southwest. En su portal

http://www.southwest.com/ , esta compañía aérea permite hacer reservas de boletos, pero
además como valor agregado a los clientes permite hacer reservas de hoteles y reservas de
alquileres de autos. Los datos para poder realizar estas reservas están tomados de web
services que brindan los distintos hoteles y rentadoras de autos.

Este es un ejemplo de uso de web services en el cual ni el consumidor ni los proveedores

pagan; a ambos le sirve este intercambio ya que la compañía de aviones le brinda un valor
agregado a sus clientes, y los hoteles y rentadoras de autos están expuestos a ser contratos
por potenciales clientes. Es más, estas empresas no publicaron sus servicios para que fueran
exclusivamente utilizados por la compañía aérea, sino que los mismos pueden ser descubiertos
y utilizados por cualquier empresa que los necesite.

Claramente se muestra en este ejemplo el gran poder de los web services, y la ventaja que
tendrán las empresas que los sepan utilizar en forma adecuada con respecto a las otras.
Imagínese en este caso si usted fuera a reservar boletos de avión y pudiera elegir por una
compañía que además de reservar los boletos le permitiera hacer la reserva de hotel, y otra
que no; ¿por cual haría la reserva? Por otro lado imagine que usted es dueño de una rentadora
de autos y sabe que su competencia esta brindando sus servicios en un portal de una
compañía aérea y usted no, ¿qué haría?.

XML

Introducción
Hoy en día, se pueden encontrar muchísimos sitios web que brindan servicios on-line como
por ejemplo reservas de asientos para espectáculos, aviones, reportes meteorológicos, etc.;
para poder brindar estos servicios a los usuarios, los diseñadores y los programadores web
deben combinar los datos y la presentación en un documento HTML. Muchas veces el
proveedor de determinada información no es quien la va a “procesar” (sea esto publicarla en
un sitio, ingresarla en una aplicación, etc).

La necesidad de generar grandes cantidades de datos dinámicos y complejos por un lado y la

necesidad de procesarlos y publicarlos por otro, han provocado la definición de un formato de
datos universal: XML.
Descripción
La idea principal detrás de XML es el desarrollo de un lenguaje estándar de etiquetas (similar a
HTML) para describir datos en forma estructurada. Este lenguaje debe poder ser interpretado
tanto por computadoras como por seres humanos. Si una aplicación en el servidor del servicio
meteorológico graba un documento XML con el reporte del tiempo y luego otro sitio web
puede leer dicho documento, se puede publicar el estado del tiempo en forma automática, sin
necesidad de ingresarlo dentro de la aplicación del sitio web cada día o convertir la
información recibida.

El lenguaje XML está compuesto por etiquetas que describen el contenido del documento. Un
elemento XML queda definido por una etiqueta de comienzo y otra de fin con el valor del
elemento entre ambas etiquetas. Los elementos pueden estar anidados y además pueden
contener en forma opcional, uno o más atributos. Los atributos son usados para adjuntar
información secundaria a los elementos.

A continuación se visualiza un ejemplo de un documento XML:

<weather-report>

<date>March 25, 2000</date>

<time>08:00</time>

<area>

<city>Montevideo</city>

<country>Uruguay</country>

</area>

<measurements>

<skies>partly cloudy</skies> <temperature>26</temperature>

<wind>

<direction>SW</direction> <windspeed>6</windspeed>

</wind>

<humidity>87</humidity>

<visibility>10</visibility>

</measurements>
</weather-report>

El ejemplo anterior está compuesto únicamente por elementos XML, pero el mismo podría
redefinirse, de forma que la información correspondiente al área estuviese representada por
atributos, como se representa a continuación:

<weather-report city=Montevideo country=Uruguay>

<date>March 25, 2000</date>

<time>08:00</time>

<measurements>

<skies>partly cloudy</skies> <temperature>26</temperature>

<wind>

<direction>SW</direction> <windspeed>6</windspeed>

</wind>

<humidity>87</humidity>

<visibility>10</visibility>

</measurements>

</weather-report>

Si bien el hecho de estar compuesto por etiquetas hace que sea parecido a HTML, hay una
diferencia muy importante: en un documento XML no hay información acerca de cómo deben
ser presentados los datos.

Así, como HTML provee etiquetas específicas para formatear un documento, XML provee un
marco para crear etiquetas.

Resumiendo, XML es un lenguaje estándar definido por el Consorcio World Wide Web para
permitir grabar y leer datos en forma estructurada con formato estándar independiente de
aplicaciones y vendedores.

En GeneXus, se cuenta con funciones para el manejo de XML : XMLWriter, XMLReader.

PROTOCOLO SOAP

Introducción
SOAP es un protocolo “liviano” basado en XML, para invocar procedimientos en forma remota
(Remote Procedure Call). Utiliza cualquier protocolo que permita transportar mensajes de
texto, siendo HTTP el más utilizado.

Su especificación describe el contenido que debe tener un mensaje XML para ser usado en una
invocación remota.

Cualquier aplicación que cumpla la especificación puede invocar y proveer servicios sin
importar en que lenguaje o plataforma esté implementado, lo único necesario es que la
aplicación sea capaz de interpretar el mensaje SOAP que recibe, realizar el procesamiento que
el mensaje requiera, y devolver otro mensaje SOAP con la respuesta.

En las aplicaciones generadas por GeneXus se utiliza SOAP para invocar a objetos
en forma remota, usando HTTP como protocolo de transporte.

Alcance
Objetos llamadores (Clientes)
Objetos: Todos los objetos

Lenguajes: C/SQL - Java - Visual Basic – Visual FoxPro – .Net

Interfaces: Win/Web

Los objetos llamadores son los que invocan servicios mediante SOAP

Objetos llamados (Servidores)

Objetos: Procedimientos y Reportes

Lenguajes: C/SQL - Java - Visual Basic – .Net

Interfaces: Web
Los objetos llamados son los brindan un servicio invocado mediante SOAP

Descripción
Algunas de las ventajas de utilizar este protocolo en aplicaciones GeneXus son la posibilidad de
desarrollar servicios web, asi como el poder hacer invocaciones entre objetos de diferentes
generadores (por ej. llamar desde Visual Basic a Java, o desde C/Sql a Visual Basic),
funcionalidad que no estaba permitida en versiones anteriores, excepto llamadas RPC desde
los generadores visuales a los generadores CSql/Cobol/RPG.

Servidor
Para indicar en GeneXus que un objeto main va a ser llamado utilizando el protocolo SOAP, se
deberá seleccionar el valor “SOAP” en la propiedad “Options/Call Protocol”. Nos referiremos
en adelante a dichos objetos como ‘Servidores’ o ‘Servicios web’. Solo pueden ser reportes o
procedimientos, sin ningún tipo de interfaz con el usuario.

Se requiere un servidor Web que haga el hosting de los servicios a ser invocados.

Los programas Servidores reciben la invocación http, procesan el mensaje SOAP que envía el
Cliente con sus parámetros, realizan la acción requerida, y generan otro mensaje SOAP de
respuesta (eventualmente con los parámetros modificados).

Cliente
Los objetos que van a invocar al servicio web, a los que llamaremos
‘Clientes’, pueden ser cualquier objeto GeneXus. La invocación se hace con
el comando call() de GeneXus.

Los programas Clientes realizan las tareas necesarias para ensamblar el

mensaje SOAP, hacer la invocación http, y desensamblar la respuesta,
obteniendo los parametros modificados en forma automática. Todo esto se
realiza en forma automática y transparente para el usuario.

Locations
Para indicar cual va a ser la ubicación de los servicios invocados se utiliza un esquema conocido
como Locations.

Manejo de errores
Comportamiento frente a un error

Si al hacer un llamado SOAP desde un objeto GeneXus se produce un error, normalmente la

ejecución del llamador se cancelará mostrando el error que ocurrió.

Si el objeto llamado es un procedimiento o reporte GeneXus, es posible indicar que se detenga

la ejecución de los programas llamadores en caso de fallar la llamada. Esto se hace mediante la
propiedad ‘Cancel Caller Execution on Error’:

Esta propiedad se habilita solamente cuando la propiedad ‘Call Protocol’ tiene el valor ‘SOAP’.
El valor por defecto es ‘Yes’. De tener valor ‘No’, la ejecución no se cancelará y se podrá
obtener el código numérico de error con la función GetSOAPErr(), y el mensaje de error
mediante la función GetSOAPErrMsg().

Códigos de error en el cliente

Los posibles códigos de error que pueden ser retornados mediante la función GetSOAPErr()
son los siguientes:

 0: Operación completada con éxito.

 Mayor que 0 y menor que 10000: Algún parámetro retornado por el servidor no
tiene el nombre esperado. El código de error indica la posición del parámetro que
ocasionó el conflicto.

 Menor que 0 y mayor que -10000: Sucedió un error al interpretar el XML de

respuesta. Sucederá por lo general si la respuesta no es XML o no es XML bien
formado. Si se toma el valor absoluto del código de error el resultado corresponderá
a un código de error del objeto XMLReader. De todas formas, getSOAPErrMsg()
retornará una descripción del error.

 Menor que -10000: Sucedió un error en la comunicación HTTP. Si se toma el valor

absoluto del código de error y se le resta 10000 el resultado corresponderá a un
código de error del objeto HTTPClient. De todas formas, getSOAPErrMsg() retornará
una descripción del error.

 -20001: La respuesta recibida es un XML válido pero no es un mensaje SOAP válido.

 -20004: El servidor retornó que hay un error en el pedido SOAP realizado por el
cliente. En este caso getSOAPErrMsg() retornará un mensaje conteniendo el código y
el mensaje de error retornados por el servidor. Si el servidor es un procedimiento o
reporte GeneXus, retornará alguno de los códigos de error descriptos más abajo.

 -20006: Sucedió un error no identificado. En este caso getSOAPErrMsg() retornará un

mensaje conteniendo el código y el mensaje de error retornados por el servidor.

 -20007: Nombre de location no válido. Sucede cuando se llama a la función

GetLocation(Nombre) con un nombre de location que no está definido para ningún
objeto en la KB.

Códigos de error en el servidor

Un procedimiento o reporte GeneXus que es llamado mediante SOAP puede retornar alguno
de los siguientes códigos de error:
  -20000: No se recibió un mensaje SOAP.

 -20001: El mensaje recibido es un XML válido pero no es un mensaje SOAP válido

(igual que en el cliente).

 -20002: El método llamado no es el esperado. (El método SOAP de los objetos

GeneXus siempre se llama “Execute”).

Casos de Web Services en GeneXus

Proveedores
El Servidor o proveedor es un procedimiento o reporte main con la propiedad ‘Call Protocol’ =
‘SOAP’. El archivo WSDL se genera automáticamente.

Por la naturaleza del protocolo SOAP los programas generados con GeneXus
pueden ser invocados por cualquier cliente SOAP, sea o no generado por
GeneXus.

La información acerca de cómo invocarlo se encuentra en el archivo WSDL (Web

Services Description Language) que es generado automáticamente. Dicho archivo
se obtiene pasándole el parámetro wsdl a la URL del servicio, por ejemplo:

http://localhost:80/c/sqlsolis/prg/nombredeprograma?wsdl

En el caso particular en que el Cliente es cualquier objeto de la misma KB, la

invocación se resuelve haciendo un call() al Web Service. La ubicación del Web
Service se configura utilizando el esquema de locations.
Los objetos Cliente y Servidor pueden estar generados con diferentes
generadores, teniendo en cuenta la sección ‘Alcance’:

Cliente C/SQL Java Visual Visual

Basic FoxPro
Servidor

C/SQL    

(*) (*) (*) (*)
Java    

Visual Basic    
Visual Fox
X X X X
(*) – El generador C/Sql adoptó desde la versión 7.5 el SOAP como protocolo por defecto para
las llamadas RPC, por lo que una llamada RPC a un programa C/Sql siempre se va a hacer vía
SOAP, no importando el generador con el que se genere el objeto llamador (con el valor
‘Internal’ para la propiedad Call Protocol; en este caso no esta disponible la propiedad ‘Cancel
Caller Execution on Error’, y cancelará el programa llamador en el caso de que se produzca un
error en el programa llamado). Es posible a partir de esta característica hacer llamadas RPC
desde programas C/Sql hacia programas generados por cualquier generador que genere
servicios SOAP. Por ejemplo es posible llamar desde un objeto main C/Sql a otro objeto main
C/Sql, característica no disponible hasta la versión 7.5 de GeneXus.

En caso en que el Servidor es un objeto externo a la KB, se cuenta a partir

de la versión 8.0 de GeneXus con el WSDL Inspector. La invocación se haría
usando el WSDL Inspector desde la KB consumidora.

En la versión 7.5, se resolvería creando en la KB del Cliente un objeto ‘dummy’

con el mismo nombre y parámetros que el objeto Servidor, y haciendo un call() a
dicho objeto desde el objeto Cliente.

NOTA: Se esta generando dentro del archivo WSDL de los servidores SOAP un
elemento <documentation> que incluye el Help del objeto. Esto permite incluir en
el WSDL información acerca del uso del Servicio, parámetros que recibe, para que
sirve, etc. El elemento tiene los siguientes subelementos:

<documentation>

<URL>Character</URL>

<line>Character</line>

<line>Character</line>

</documentation>

En el elemento URL se indica la URL al Help HTML del objeto que se genera.

En los elementos line se genera el Help del objeto. Solo la parte de texto es
generada, ignorándose el resto. Se generan líneas con un máximo de 80
caracteres, en caso de que la línea de Help sea mas larga, se generan tantos
elementos line como sean necesarios.
Consumidores a Web Services externos
Usando GeneXus 8.0 o posterior se utiliza el WSDL Inspector, que permite
importar la definición del servicio que se desea consumir.

Igualmente en la versión 7.5 es posible invocar a un servicio web externo utilizando los tipos
de datos HttpClient, XmlWriter y XmlReader.

WEB SERVICES CON GENEXUS

A continuación se detallarán 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 web server, con lo que el web service queda operativo para
ser invocado.

El WSDL del servicio queda disponible agregando el parámetro wsdl a la URL del mismo. Por
ej.:
http://server/baseurl/aservice.aspx?wsdl

Estas funcionalidades están disponibles a partir de la versión 7.5 de GeneXus.

Consumir
Usando GeneXus 8.0 o posterior:
Se utiliza el WSDL Inspector, que permite importar la definición del servicio que se desea
consumir. Se debe indicar el WSDL del mismo, y el utilitario definirá los tipos de datos
necesarios para poder consumirlo desde GeneXus.

En el caso de que el web service utilice tipos de datos estructurados, los mismos serán
agregados a la base de conocimiento al importar la definición con el WSDL Inspector.

Además, es necesario configurar la propiedad de objeto Location. Esto servirá luego para
configurar, en los objetos GeneXus que vayan a invocar al web service, la ubicación del mismo
(host, port, etc).

CREACION DE WEB SERVICE GENEXUS

En esta sección crearemos un Web Service GeneXus, y veremos como consumirlo desde una
aplicación GeneXus.

Supongamos que quisiéramos publicar un servicio de nuestro sitio web, por ejemplo un
ranking con las 10 películas más vendidas.

Vamos a definir entonces un Web Service al que llamaremos “Ranking”.

Lo primero es definir un SDT con las siguientes características, que nos permita
almacenar la información de las películas que nos interesa publicar:

Nombre: Moviesdt

Structure Type
MovieId Identifier

MovieTitle Character(60)

Moviesdt será una Collection.

Haga clic aquí para ver la demostración

Para programar el procedimiento “Ranking” se recorre la tabla “Movies” en forma

descendente por MovieQtity, que indica para una película en particular, qué cantidad
ha sido vendida. De esa forma, obtendremos las 10 más vendidas.

Definiremos una variable que nos permita contar la cantidad de películas: &Qty, más
una variable que permita almacenar toda la colección de películas más vendidas
(Movie) junto con una variable que cargue cada uno de los items de esa colección de
películas (MovieItem).

Las variables a definir entonces son las siguientes:

Name Type
Qty N(2)

Movie S(Moviesdt)

MovieItem S(Moviesdt.MoviesdtItem)
&Qty = 1

for each (MovieQtity)

&MovieItem.MovieId = MovieId

&MovieItem.MovieTitle = MovieTitle

&Movie.Add(&MovieItem)

&MovieItem = new Moviesdt.MoviesdtItem()

&Qty +=1

if &Qty > 10

exit

endif

endfor

Rules:

parm(out:&Movie);

Haga clic aquí para ver la demostración.

Observe que es necesario que el procedimiento sea main, y configurar la propiedad “Call
protocol” con el valor “SOAP”.

Luego de generar y compilar el procedimiento “Ranking”, verifique el Web Service generado

automáticamente por GeneXus, digitando la siguiente URL en el browser:

http://localhost/services/aranking.aspx?wsdl

Creación del Consumidor del Web Service

A continuación crearemos un web panel que será el consumidor del Web Service “Ranking”
recientemente creado.
En general un Web Service será externo a la KB, por lo cual vamos a crear una nueva base de
conocimiento para crear ese web panel al que llamaremos “ViewRanking”.

1. Creación de una nueva base de conocimiento, de nombre “Consumer”

Haga clic aquí para ver la demostración.

2. Desde diseño, ejecutar el WSDL Inspector, (“Tools->WSDL Inspector”).

En “web service URL” colocar la siguiente URL
http://localhost/services/aranking.aspx?wsdl y clickear en el botón “Inspect”·

Observe que el método del Web Service es “Execute” y el tipo de datos que
devuelve es “Moviesdt”.

Cuando Clickeamos en el botón “Add Reference” se definen los tipos de datos

además de toda la información necesaria para poder consumir el Web Service.

Pasar a prototipo forzando el impacto.

Haga clic aquí para ver la demostración.

3. Vamos a crear el web panel “ViewRanking”, para eso definiremos las

siguientes variables:

Name Type

MovieId N(3)

MovieTitle Character(60)

Movie S(Moviesdt)

MovieItem S(Moviesdt_MoviesdtItem)

Rank O(org_tempuriaction_.Ranking)
 Observe que los tipos de datos Moviesdt (colección de películas),
Moviesdt_MoviesdtItem (cada item de la colección) y
org_tempuriaction_.Ranking (Web Service) se crearon automáticamente al
inspeccionar el servicio con el WSDL Inspector.
El form del web panel “ViewRanking” contendrá un grid con las variables &MovieId y
&MovieTitle.

Programaremos los eventos “Refresh” y “Load” del web panel, como se muestra a
continuación:

Event Refresh

&Movie = &Rank.Execute() //aquí se invoca la ejecución del Web Service y se carga la

colección en la

//variable &Movie

EndEvent // Refresh

Event Grid1.Load

for &MovieItem in &Movie //se recorre la colección y se carga el grid

&MovieId = &MovieItem.MovieId

&MovieTitle = &MovieItem.MovieTitle

load

endfor

EndEvent // Grid1.Load

Haga clic aquí para ver la demostración.

Ejecute el web panel “ViewRanking” y observe como se obtiene la información requerida.

EJEMPLO DE CÓMO CONSUMIR UN WEB
SERVICE EXTERNO
Una de las características interesantes de los web services, es que podemos
agregar valor a nuestro sitio web, sin necesidad que el usuario deba ir a otro sitio.
Es importante evitar “perder” el usuario al llevarlo a otras paginas web.

Lo que queremos ver en esta sección es como incluir un web service externo no
GeneXus en nuestra aplicación (Ya hemos visto en este capítulo un ejemplo de
como crear y consumir un web service hecho con GeneXus).

Lo que haremos es importar un web service que provée Google. Google es una
compañía especializada en la búsqueda de información en la web. En su página web
(http://www.google.com) se puede ingresar una lista de palabras por las cuales buscar
y retorna todos los sitios web en las cuales encontró esas palabras. Esta misma
funcionalidad Google la provee por medio de un web service.

El WSDL de dicho web service es: http://api.google.com/GoogleSearch.wsdl

El WSDL Inspector permite a partir del WSDL de un web service definir los tipos de
datos necesarios en GeneXus para poder consumir el web service en forma
transparente, sin tener que preocuparse de los protocolos involucrados en el
proceso y la definición del mismo.

¿Que es wsdl?

WSDL es un lenguaje basado en XML que se utiliza para describir un web service.
Un archivo con formato WSDL provee información de los distintos métodos
(operaciones) que el web service brinda y sus parámetros, muestra cómo
accederlos y que formatos deben de tener los mensajes que se envían y se reciben.

Entonces, el procedimiento a seguir para incluir el web service de Google en el sitio

de películas es el siguiente:

 Ejecutar el WSDL Inspector (Tools/WSDL Inspector en el modelo de diseño).

 En “Web Service URL” ingresar: http://api.google.com/GoogleSearch.wsdl.
 Presionar el botón “Inspect”.
 Notar que el WSDL Inspector determinó que el web service tiene los
siguientes métodos: doGetCachedPage, doSpellingSuggestion y
doGoogleSearch (este último es el que luego vamos a consumir).
  Notar en el costado inferior izquierdo los tipos de datos complejos que va a
crear GeneXus para consumir el web service en forma adecuada.
 Presionar el botón “Add Reference” para que GeneXus cree en la base de
conocimientos todo lo necesario para consumir el web service.
 Cerrar el WSDL Inspector.
 Impactar el modelo de diseño.

Haga clic aquí para ver la demostración

A continuación es necesario consolidar el “GoogleSearch.xpz”, que contiene el web

panel “GoogleSearch” donde vamos a consumir el web service de Google.

En ese web panel, crear las siguientes variables:

Tipo
NOMBRE

Ws GoogleSearch.GoogleSearchService

Return GoogleSearchResult

ResultElements ResultElementArray

ResultElement ResultElement

Ya están definidas en el xpz el resto de las variables necesarias para hacer el

ejercicio.

Luego, debemos programar el evento search.click de la siguiente forma:

Event search.click

&Key = "3yHXpPZQFHKdexiyPjqTPYNqVvnYj8cZ"

&MaxResult = 10

&Filter = 1

&SafeSearch = 1

&Return=
&Ws.doGoogleSearch(&Key,trim(&Query),&Start,&MaxResult,&Filter,
&Restrict,&Safesearch,&Lr,&Ie,&Oe)
 &ResultElements = &Return.resultElements

&searchTime = &return.searchTime

EndEvent

En este evento se realiza la invocación al método doGoogleSearch del web service.

Los resultados son devueltos en una Collection de un tipo de datos estructurado, el que
es definido automáticamente en GeneXus por el WSDL Inspector.

Programar el evento Load de la grilla de la siguiente forma:

Event Grid1.Load

For &ResultElement in &ResultElements

Title.Caption = &ResultElement.title

&url = &resultElement.URL

Title.LinkTarget = "_BLANK"

Title.Link = link(&ResultElement.URL)

&Summary = &ResultElement.snippet

&cachedsize = &resultelement.cachedSize

grid1.Load()

Endfor

EndEvent

En este evento se recorre la Collection con los resultados devueltos por el web
service y se realiza la carga del grid.

Haga clic aquí para ver la demostración.

Especificar, generar, compilar y ejecutar el web panel GoogleSearch.

Haga clic aquí para ver la ejecución.

Nota:

La especificación del web service del ejemplo, se puede leer de:

http://www.google.com/apis/reference.html

INTRODUCCIÓN AL CAPÍTULO 11
Cada vez mas, el uso masivo de Internet propicia el desarrollo de aplicaciones de mayor
versatilidad y complejidad para ambiente Web. Es por esto que está surgiendo la necesidad de
aplicar una reingeniería a las aplicaciones existentes y también, en muchos casos, la necesidad
de desarrollar nuevas aplicaciones para Internet.

Existen varias diferencias entre los ambientes GUI (aplicaciones con Interfaz de Usuario
Grafica) y WEB, las que deberán evaluarse al momento de determinar la conveniencia del tipo
de aplicación a desarrollar.

En este capítulo veremos los principales aspectos a ser tenidos en cuenta para los usuarios
GeneXus.

COMPARACIÓN GUI – WEB

Objetivo.

El objetivo de este artículo es brindar una herramienta de referencia, para asistir en la decisión
de migrar o desarrollar una aplicación con interfaz de usuario grafica (GUI), o una aplicación
web.

Para analizar las diferencias entre los dos tipos de aplicaciones se compararán las ventajas y
desventajas de las aplicaciones web frente a las aplicaciones GUI.
Existe otro articulo (Conversión de Aplicaciones GUI a WEB) sobre esta misma temática
en donde se dan los detalles técnicos de cómo realizar esta tarea, por lo que aquí no se
mencionarán esos detalles.

Introducción.

Aplicaciones con interfaz de usuario gráfica.

Las aplicaciones con Interfaz de Usuario Grafica (GUI) están compuestas por uno o varios
programas GeneXus que utilizan objetos de tipo, transacción, work panel, procedimientos y
reportes.

Aplicaciones Web.

Se entenderá por aplicaciones Full Web a aquellas aplicaciones en las que la interfaz del
usuario es únicamente realizada utilizando el lenguaje HTML y son accedidas desde un
browser. En GeneXus estas aplicaciones se implementan con objetos web como web panels o
Transacciones Web.

El lenguaje HTML es un lenguaje de marcas (tags) para la estructuración de un documento. Si

bien el lenguaje es estándar, en la práctica, cada browser toma algunas partes de la
especificación, agrega e ignora otras. Como consecuencia de esto una aplicación Web puede
quedar levemente distinta según el browser que se utilice.

Características de las aplicaciones Web.

Ventajas de las aplicaciones Web.

Una aplicación Web tiene diversas ventajas frente a las aplicaciones GUI.

INSTALACIÓN.

Las aplicaciones Web presentan varias ventajas tanto en la instalación y actualización como en
los requerimientos necesarios para utilizarlas.
Cliente ‘fino’. Para utilizar la aplicación Web solo se necesita un browser. Los browsers son
distribuidos por Internet y no tienen costo. Generalmente vienen incluidos al instalar el
sistema operativo. Adicionalmente se pueden instalar plugs-in, que son programas que
agregan funcionalidades adicionales al browser. Un ejemplo muy común es el plug-in de
Acrobat, utilizado para visualizar archivos en formato PDF o plugs-in para video o sonido.

Flexibilidad en software y hardware en el cliente. En las aplicaciones Web, el cliente puede

tener instalado cualquier sistema operativo en cualquier versión. Las aplicaciones Web no
utilizan tantos recursos de hardware por lo que el costo de las computadoras clientes es
menor y no necesita actualizaciones frecuentes.

La aplicación solo se instala en el servidor. Generalmente la instalación y actualización de

aplicaciones GUI en arquitecturas cliente / servidor implica, alguna instalación en las
computadoras cliente. En el caso de aplicaciones Java GUI, esta instalación es automática,
pero también existe ya que es necesario bajar la aplicación.

En el caso de una aplicación web no se requiere ninguna instalación adicional a la del browser,
para poder accederla o acceder a otras aplicaciones web.

ESCALABILIDAD.

Las aplicaciones Web utilizan una arquitectura de tres capas compuesta por la capa cliente,
donde está únicamente el browser, la capa del Servidor Web donde esta la aplicación y la capa
de datos donde se encuentra la Base de Datos.

Capa
Capa Cliente
Servidor Web
Aplicación

Web

Capa
Browser
de Datos
BD
Arquitectura en tres capas.

Esta arquitectura presenta varias ventajas en cuanto a la escalabilidad.

Escalabilidad de usuarios. En la concepción de la aplicación, no se tiene en cuenta la cantidad
de usuarios que van a utilizarla. Es decir que la misma aplicación puede ser utilizada por
algunos pocos usuarios o varios cientos. El limite estará determinado por el desempeño de la
aplicación, que depende principalmente de la potencia de los servidores y las características de
la red.

Una ventaja de la arquitectura en tres capas es que no es necesario pagar nuevas licencias por
cada nuevo usuario que accede a la aplicación (por ejemplo los drivers de acceso a la base de
datos se pagan por cantidad de usuarios concurrentes).

Escalabilidad de servidores. El desempeño de la aplicación depende directamente de la

potencia de los servidores en la que este instalada. Se puede migrar la aplicación a servidores
más potentes, sin necesidad de que los usuarios cambien el modo en que acceden a la
aplicación.

INDEPENDENCIA.

Acceso. La aplicación puede ser accedida desde cualquier lugar que cuente con acceso a
Internet. Esto puede tener un fuerte impacto en el modo de trabajo ya que se pueden acceder
a las aplicaciones desde la oficina, el hogar o incluso desde otros países.

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

INTERFAZ GRÁFICA.

Uniformidad. La forma de navegar por la aplicación web será siguiendo links o presionando
botones y si bien hay mas opciones, estas son las más comunes y se mantendrán por toda la
aplicación. Si bien este modo de interacción es limitado con respecto a las aplicaciones GUI, al
ser tan simple y uniforme en toda la aplicación, al usuario final le resultará sencillo e intuitivo
aprender a utilizar nuevas funcionalidades.
El diseño gráfico es realizado por expertos. Un aspecto sumamente importante en la interfaz
grafica de una aplicación Web es el diseño grafico. Este aspecto sumamente delicado se deja a
cargo de diseñadores gráficos especializados, que hacen que las aplicaciones tengan aspectos
atractivos y funcionales.

El trabajo con los diseñadores gráficos sigue pautas similares a la metodología de

prototipación utilizada en el desarrollo de aplicaciones GeneXus. Cuando los diseñadores
tienen listo un prototipo, es conveniente que los desarrolladores lo evalúen para validarlo
desde el punto de vista del desarrollo.

Para esto se cuenta a partir de la versión 8.0 de GeneXus, con el Editor de Temas, herramienta
que puede ser usada tanto desde GeneXus como en forma independiente, por lo cual
flexibiliza notablemente la interacción con el diseñador gráfico, además de todas las ventajas
adicionales que trae el uso de Temas en el diseño de la aplicación WEB. Por detalles sobre
Temas ver el documento “Themes”

Al evaluar un diseño hay que tener en cuenta ciertos aspectos:

 Impacto del diseño de las páginas Web finales. Si se utilizan demasiadas imágenes,
con muchos botones, el tamaño final de la página, puede ser excesivamente grande,
por lo que se demorará mucho el acceso. La recomendación es cuidar de que las
imágenes sean de pocos Kbytes. Los links de texto son muy livianos, en el caso de
una aplicación muy accedida, puede ser conveniente utilizarlos. Los sitios web de
Amazon y Yahoo, son buenos ejemplos de interfaces livianas, con pocas imágenes y
muchos links de texto.
 El diseño debe ser consistente. Por ejemplo la tipografía, los colores, la ubicación de
botones, etc. debe seguir una pauta bien definida, que los desarrolladores deben
respetar al máximo.
 El diseño debe ser simple y sencillo. El exceso de detalles gráficos, puede complicar el
desarrollo y evolución del sitio.
 El diseño debe ser robusto de modo de poder soportar evoluciones, y nuevos
requerimientos.
 Componentización. Es muy importante que la estructura de las páginas pueda ser
separado en componentes, de modo de poder reutilizar los mismos objetos para
simplificarle al usuario el conocimiento del sitio. En GeneXus esto, se implementa
utilizando Web Components.

Mantenimiento. La posibilidad de desarrollar una página dividida en Web Components,

permite tratar cada componente en forma independiente. Esto no solo hace las interfaces más
robustas frente a cambios y extensiones, sino que además al cambiar un componente, se
reflejan los cambios en todas las páginas que lo incluyen. O sea que no es necesario
reprogramar todas las páginas, solo el componente adecuado, haciendo del mantenimiento de
la aplicación sencillo.
Integración de nuevas aplicaciones. La interfaz con el usuario se puede personalizar
dinámicamente, de acuerdo a las características del usuario. Por ejemplo con menúes donde
las opciones se cargan dinámicamente, según las aplicaciones a las que puede acceder el
usuario. De este modo se logran aplicaciones mas integradas y donde es más sencillo
incorporar nuevas aplicaciones.

Interfaz multimedia. Es muy sencillo incluir en las aplicaciones web características multimedia
como audio, video, imágenes, etc.

APPLICATION SERVICE PROVIDERS Y SERVICIOS WEB.

Los Application Service Providers (ASP), son empresas que brindan servicios y soluciones,
basadas en software, a través de Internet. Ejemplos muy comunes de ASP en portales de
Internet son los proveedores de noticias, banners, clima, etc.

Tener aplicaciones web habilita a la empresa a funcionar como ASP, brindando como servicio
el uso de las aplicaciones web desarrolladas.

También habilita a contratar a otros ASP para potenciar las aplicaciones propias.

INTEGRACIÓN DE APLICACIONES INTERNET E INTRANET.

Las aplicaciones web desarrolladas pueden ser utilizadas en Internet o en una Intranet, para
uso interno. Además las aplicaciones web ya existentes, utilizadas en la Intranet pueden ser
integradas a las nuevas aplicaciones web desarrolladas.

EXTENSIONES CON JAVA Y JAVASCRIPT.

En las aplicaciones Web se pueden incorporar extensiones en lenguajes como Java y
JavaScript.

Para controlar distintos aspectos de la interacción con páginas web se utiliza el lenguaje
JavaScript. El código escrito en este lenguaje es incorporado en el HTML e interpretado por el
browser.

Java es un lenguaje de programación muy potente, entre sus propiedades, se destaca la de ser
multiplataforma. Esto quiere decir que las aplicaciones desarrolladas en Java pueden
ejecutarse en cualquier sistema operativo y cualquier plataforma de hardware. Esta propiedad
lo hace especialmente atractivo para aplicaciones que ejecutan a través de Internet. Por lo
tanto se pueden incorporar aplicaciones GUI desarrolladas en Java, para potenciar la aplicación
web.
 MÚLTIPLES FORMAS DE ACCESO.
Múltiples tecnologías como computadores de bolsillo y teléfonos celulares están teniendo un
fuerte desarrollo, principalmente como formas alternativas de acceso a Internet. Las
características de hardware de estos dispositivos hacen que las aplicaciones web sean las mas
adecuadas. La principal diferencia con las aplicaciones web para estos dispositivos es el
tamaño reducido de la pantalla. Si bien es necesario crear una versión particular para el
dispositivo, se puede reutilizar mucho conocimiento de una aplicación web ya desarrollada.

Inconvenientes de las aplicaciones web.

En la siguiente sección se discuten las desventajas que presentan las aplicaciones web frente a
las aplicaciones GUI.

Es necesaria una reingeniería de la aplicación. El lenguaje HTML presenta ciertas

limitaciones que implica que migrar aplicaciones GUI a aplicaciones Web no sea una
AS que deben tenerse en cuenta al realizar la
tarea automática. Entre los puntos
reingeniería de la aplicación sepedestacan los siguientes:
lr
iv
Seguridad. Es imprescindible tener
ci un esquema de seguridad en la aplicación, de
modo de restringir el acceso a determinadas aplicaciones. Este puede basarse en
ad
definir roles con determinados accesos o un esquema en el cual a cada usuario se le
asignan permisos particulares. cPor
o otro lado la aplicación puede requerir que algunas
ir un esquema mas fuerte de seguridad y requieran
aplicaciones particulares necesiten
ó seguros.
páginas Web seguras y servidores
nW
e
Transacciones e Integridad transaccional. Las Transacciones Web utilizan la misma
b
W En la figura se ve la secuencia de acciones que
arquitectura que los Web Panels.
ocurren al someter las Transacciones
e Web al servidor.
b
Respuesta HTML
F
del programa O
R
M

Browser
 Funcionamiento de las Transacciones Web y Web Panels.

El tiempo de vida de las UTL (unidades de trabajo lógicas) en los objetos web, se mantiene
únicamente durante la ejecución del objeto. Cuando la ejecución termina se deben hacer
commit o roll back. Por lo tanto no es posible definir una UTL a través de varias Transacciones
Web. Sin embargo, es posible mantener la UTL a través de varios procedimientos que se
invoquen unos a otros, siempre que se mantengan dentro de la misma ejecución. En las
aplicaciones GUI es común encontrar que durante varias transacciones se van ingresando
datos y luego en la última transacción se hace el commit de todos los datos ingresados, por lo
que se deben contemplar estos casos en la reingeniería de la aplicación. Las alternativas
posibles a esta situación son:

Unificar todas las transacciones GUI en una sola Transacción Web.

Dividir el proceso de ingreso en varias etapas y utilizar múltiples Transacciones Web. Al

finalizar el ingreso podría tenerse un procedimiento que valide que el ingreso en varias etapas
es consistente.

Ingresar toda la información en tablas temporales y luego ingresar la información a la base de

datos mediante procedimientos.
Validación de datos. La validación se realiza a nivel de todo el documento. Esto implica que en
un documento con cabezal y líneas no se puedan ejecutar reglas al pasar del cabezal a las
líneas o luego de ingresar un valor, etc. Por lo tanto la validación de todos los datos se realiza
cuando se completa toda la información y se presiona el botón de confirmación, si los datos
cumplen las reglas, entonces el botón de confirmación cambia para que se ingresen
efectivamente los datos. También es posible trabajar sin confirmación y en este caso si la
información cumple las reglas se ingresa directamente a la base de datos.

Limitación entre la interacción de objetos GeneXus. La interacción entre objetos GeneXus, en

aplicaciones web es mas limitada que la interacción en aplicaciones GUI. Las Transacciones
Web y los Web Panels pueden ser invocados entre sí, y ambos pueden invocar a
procedimientos. Desde objetos web no es posible invocar objetos no web como transacciones,
work panels y reportes, aunque para los reportes existe la posibilidad de generarlos en
formato PDF. Este tipo de comportamiento que puede encontrarse en una aplicación GUI,
debe ser tratado en la reingeniería de la aplicación.

Diferencias en los Work Panel “Trabajar con”. En las aplicaciones Web, los work panels de
tipo “Trabajar con” presentan algunas diferencias que en las aplicaciones GUI.

El alto de la pantalla cambia, dependiendo de la cantidad de líneas del subfile. En las

aplicaciones GUI, el tamaño de los formularios se determina en el diseño de este y queda fijo
en el momento de ejecución. En las aplicaciones Web, el tamaño de la página web se puede
extender (horizontal o verticalmente) si se presentan muchas líneas en los grids.

La selección de líneas es diferente. En las aplicaciones GUI, las líneas se seleccionan al hacer
clic en ellas, además se puede seleccionar un rango de líneas, continuo o con líneas salteadas,
todo esto sin necesidad de programación extra. En las aplicaciones Web, la selección múltiple
de líneas debe programarse mediante campos de chequeo.

Una posibilidad es permitir la selección de múltiples líneas y utilizar el carrito de compras (se
describe más adelante).

Se puede usar la propiedad “AllowSelection” de los grids para que sea posible seleccionar de a
una línea.

El modelo del carrito de compras. El carrito de compras, es muy utilizado en los sitios web con
e-commerce y permite ‘recordar’ los objetos que compra los usuarios. En el carrito de compras
se van seleccionando distintos items que se desean comprar. El carrito mantiene almacenado
el contenido hasta que el dueño decide comprar alguno o todos los items. Esta idea resulta
practica en casos como estos:

Factura de compras. La factura se va armando seleccionando los elementos que la componen:

lista de productos disponibles, lista de clientes, formas de pago, monedas, etc. Cuando se
termino de armar, se construye la factura con toda la información del carrito.

Si se quiere realizar alguna acción a una serie de líneas en un ‘Trabajar con’, se pueden
ingresar en el carrito y luego automáticamente se van presentando una a una las paginas
adecuadas para la acción determinada, hasta vaciar el carrito.

Ejecución en el servidor. A diferencia de las aplicaciones GUI cliente / servidor, donde pueden
ejecutarse acciones tanto en el cliente como en el servidor, en las aplicaciones web, solo se
pueden ejecutar acciones en el servidor. Podría decirse que el cliente prácticamente no tiene
capacidad de computo, además como se mencionó anteriormente tampoco tienen memoria.
Es decir que no es posible definir un valor, almacenarlo en la computadora del cliente y luego
recuperarlo. Sin embargo hay algunas alternativas:

Cookies. Son archivos de texto, que quedan salvados en las computadoras cliente. En ellos se
puede guardar variables y luego recuperar su valor. Aunque browser permite al usuario a
opción de deshabilitar el uso de cookies, son ampliamente utilizadas.

Pasaje de parámetros. En este método se utiliza el pasaje de parámetros entre los objetos web
para el pasaje de información. Todos los objetos web de la aplicación tendrán los primeros
parámetros iguales, en donde se pasarán datos comunes a toda la aplicación, como número de
cliente, etc. y luego tendrán parámetros específicos de cada uno. La ventaja de este método es
que los usuarios que no permiten cookies no tienen problemas en utilizar la aplicación, la
desventaja es que los cambios en los parámetros tienen un fuerte impacto. Como el pasaje de
parámetros se realiza a través de la url de la aplicación y los browsers permiten que se vea esa
url, el usuario puede ver el valor de los parámetros, e incluso modificarlos. Sin embargo,
GeneXus brinda la posibilidad de encriptar los parámetros en forma transparente al
desarrollador, esto es importante porque se puede pasar números de cliente, números de
factura, etc. en forma segura.

Crear sesiones. Este método mantiene la información en sesiones que son almacenadas en la
base de datos. Por cada usuario que utiliza la aplicación debe crearse su sesión particular.
Además debe ser complementada con el pasaje de parámetros o cookies para recuperar el
número de sesión. La ventaja sobre el método anterior es que si se necesita almacenar mas
información se afecta solo los objetos que necesitan esa información.

Infraestructura de hardware. La performance de una aplicación Web depende en gran medida

de la cantidad de usuarios concurrentes accediendo a la aplicación, el ancho de banda de la
conexión y la potencia de los servidores. Por lo tanto los servidores (web y de base de datos) y
el ancho de banda de ‘salida’ debe ser adecuado a la cantidad de usuarios esperada. También
es imprescindible un esquema fuerte de seguridad principalmente de la base de datos.

Una aplicación web debe estar disponible los 7 días de la semana, durante las 24 horas del día.
Esto implica un servicio de alta disponibilidad en el cual posiblemente se maneje redundancia
de servidores y de información.
Conclusiones.

Las aplicaciones web son una nueva alternativa a las aplicaciones de interfaz grafica. Ambos
tipos de aplicación tienen sus características propias por lo que en cada aplicación se debe
evaluar si conviene realizarla como web o GUI. Los puntos discutidos en este articulo pueden
ser considerados como una guía para tomar esta decisión. Como requisito para tomar una
decisión correcta se debe comprender:

 El funcionamiento de la interfaz web y las limitaciones que ello trae como

consecuencia.
 Las limitaciones en la integridad transaccional.

Algunos puntos a tener en cuenta para evaluar la creación o migración a aplicaciones web son:

 Requerimientos y proceso de instalación de la aplicación final

 Ambiente en donde se ejecute la aplicación.
 Requerimientos en el acceso.
 Interfaz gráfica en cuanto a facilidad de uso, diseño grafico atractivo y capacidades
multimedia.
 Acceso desde múltiples plataformas como computadoras de bolsillo, etc.
 Requerimientos de seguridad en la aplicación.
 Complejidad en las transacciones GeneXus, especialmente en la validación de datos y
disparo de reglas.
 Restricciones en la interacción de objetos GeneXus. Debe ser evaluado
cuidadosamente en el caso de migrar una aplicación GUI a web.
 Servidores. En las aplicaciones web la ejecución se realiza completamente en el
servidor.

Como punto final hay que tener en cuenta evolución de la aplicación en cuanto a la creación
de nuevos módulos, cantidad de usuarios y mantenimiento.

CONVERSIÓN DE APLICACIONES GUI A WEB

Objetivo

El objetivo de este documento es describir los principales aspectos técnicos a tener en cuenta
al momento de convertir una aplicación GeneXus de tipo GUI-Windows a una aplicación Web.
Introducción

Aplicación GUI
Entendemos como aplicación GUI (Graphic User Interface) a toda aquella que tiene interfaz
gráfica Windows, compuesta básicamente por los objetos transacciones, work panels,
procedimientos y reportes, generadas con los generadores GeneXus Visual Basic, Visual Fox,
Java y .Net.

Aplicación Web
Una aplicación Full Web tiene una interfaz HTML (HyperText Markup Language) y se ejecuta
dentro de un browser. Este tipo de aplicaciones se desarrolla básicamente con los objetos Web
de GeneXus: web panels y web transactions. Se generan con cualquiera de los generadores
Web: Visual Basic, Java, .Net y C/SQL

Reingeniería de la aplicación
La premisa fundamental para convertir una aplicación WIN a WEB es que los ambientes
implicados (gráfico, html) son diferentes y por lo tanto la conversión implicará algo mas que la
mera conversión de los objetos.

Deberá programarse con “estilo web”.

En este documento centralizamos consideraciones a tenerse en cuenta para los diferentes

objetos y modalidades de programación.

La conversión de los objetos implica:

1. Conversión de Work Panels

2. Conversión de Transacciones
3. Conversión de Reportes

1. Conversión de Work Panels a Web Panels

Una posibilidad para realizar la conversión de los Work Panels a Web Panels es utilizar la
facilidad de SAVE AS que brinda GeneXus. De esta forma, se convierte en forma automática el
form gráfico al form html y se mantiene toda la lógica del objeto. Algunos controles WIN no
son soportados en WEB (por ejemplo el tab control), con lo cual no siempre es automática la
conversión de un form a otro.

Otra posibilidad es crear un nuevo objeto (Web panel) y copiar la lógica del work panel hacia el
web panel.

Observe que se debe revisar la lógica ya que existen ciertas diferencias en la interfaz que
obligan a cambios en la programación.

Se recomienda leer el documento Comparación entre Web Panels y Work Panels donde se
comparan generalidades de ambos tipos de objetos.

NOTA – Luego de convertir el objeto, se debe editar el código HTML del mismo y quitar los tags
<pre> y </pre> que quedan al principio y al final respectivamente del mismo. Hay que tener en
cuenta que la conversión no crea una tabla con los controles dentro, por lo tanto al quitar los
tags mencionados anteriormente la pantalla se “desarma” y quedan todos los controles juntos.
Se aconseja por lo tanto, crear primero una tabla donde se pueden “arrastrar” los controles y
finalmente quitar los tags <pre> y </pre>

2. Conversión de Transacciones a Transacciones Web

Se cuenta con un form HTML default por cada transacción web (con los atributos de la
transacción, así como los controles propios de Transacciones Web, como ser el Error Viewer).
Luego ese form se puede modificar a gusto del programador.

En algunos aspectos, el comportamiento de las Transacciones Web es diferente al de las

Transacciones con interfaz gráfica por lo tanto se recomienda la lectura del documento
‘Transacciones Web’.

3. Conversión de Reportes

Una posibilidad para manejar reportes es programar un webpanel, de forma que el usuario
final pueda imprimirlo con las opciones de impresión del browser.

Otra posibilidad como solución a la necesidad de implementar un reporte en ambiente WEB es

generar un reporte con salida PDF.
Diferencias entre los ambientes y como manejarlas
Work Panel “Trabajar con”
Es muy común el uso de web panels del estilo ‘Trabajar con’ donde se despliega un grid con
registros y una cantidad de opciones aplicables a cada una de las líneas del mismo. Por
ejemplo: 2 – Modificar, 3 – Visualizar, etc.

MANEJO DE OPCIONES

En el objeto Web Panel, existen algunas alternativas para implementarlo:

1. Agregar en el grid una variable de tipo Combobox y programar las diferentes

acciones en el evento Clic de la misma.
2. Definir una imagen o un text block en el grid por cada una de las opciones y
programar la acción en el evento clic.
3. Si se utiliza un grid free-style, puede utilizarse en lugar de una imagen con el evento
CLIC, un botón para cada una de las opciones.
4. Configurar la propiedad “AllowSelection” del grid.

FILTROS
Si un Web Panel ‘Trabajar con’ tiene variables que se aplican como filtro a los
registros desplegados en el grid, al seleccionar un registro y llamar a otro
objeto (por ej. Transacción Web) que tiene un return, se vuelve al Web Panel
‘Trabajar con’ pero se pierden los valores ingresados a los filtros. Para poder
mantener el comportamiento de los Work Panels ‘Trabajar con’ se deberían
utilizar cookies que almacenen los filtros ingresados.
REFRESH
En Work Panels ‘Trabajar con’, es común tener un comando Refresh o Refresh
keep dentro de un evento, luego de llamar a una transacción. Cuando estos se
convierten a Web Panels ‘Trabajar con’ el Refresh no es necesario, ya que al
ejecutar el comando Return hay un refresh implícito del Web Panel. Por lo
tanto, los comandos Refresh y Refresh keep deben ser eliminados de los
eventos mencionados anteriormente.

Procesamiento de varias filas en grid - For each line selected

En web panels, no existe la forma de seleccionar con el mouse varias líneas del grid ya que no
existe posicionamiento en ninguna parte del form. Para implementar la selección múltiple, se
debe definir una variable en el grid y asignarle un valor a cada una de las líneas que se quieren
procesar. Luego, se debe usar el comando For each line para procesar cada una de las líneas y
filtrar por las que estén seleccionadas (&valor = X).

Debe considerarse que se puede utilizar únicamente para invocar a objetos sin interfaz. Si se
invoca a otro web panel, solamente se ejecuta para el último registro del grid.
Para la selección de una linea se cuenta con la propiedad “AllowSelection”.

Call de un objeto sin interfaz a otro con interfaz

En las aplicaciones GUI puede definirse una cadena de llamadas entre objetos del estilo: work
panel -> call procedure -> call work panel.

En las aplicaciones HTML esto no puede usarse. Las llamadas a un web panel solamente
pueden realizarse desde otro web panel (mediante el call o el link).

Por lo tanto, deberá modificarse la programación a algo del estilo:

Web panel -> call procedure

-> Call web panel

Integridad transaccional: manejo de UTL’s

Las transacciones Web siempre hacen commit, por lo que el manejo de transacciones
anidadas, con la propiedad ‘commit on exit en NO’ no se puede lograr. En muchos casos la
alternativa es utilizar la lógica del modelo del ‘Carrito de Compras’

Uso de Tab Dialogs

En las aplicaciones GUI, se pueden definir tab dialogs para organizar los datos del form en
varias secciones. En las aplicaciones HTML no se tiene este control por lo que será necesario
rediseñar el form. Una alternativa puede ser definir un objeto por cada Tab Dialog.

Otra alternativa es usar código HTML externo que permite simular estos tabs

Styles para Web Panels.

En web panels los styles sirven – a diferencia del resto de los objetos GeneXus- únicamente
para inicializarlos pero no tienen dinamismo por lo que las modificaciones realizadas al style
después de haberlo aplicado no se reflejarán en los objetos. Esto se debe a que el concepto
de “Data Area” en el cual se basa el dinamismo de los styles no es aplicable a la interfaz HTML
por la diversidad de los diseños.
La forma de obtener el dinamismo en este caso es utilizando el concepto de Web Components
que permite incluir un mismo objeto en varios, simplificando así el mantenimiento. De esta
forma, lo que deberia hacerse es definir un style con el diseño del form y los web components
que incluirá y aplicarlo a los nuevos objetos Web Panel creados. Las modificaciones de cada
web component se reflejarán automáticamente en todos los web panels.

INTRODUCCIÓN CAPÍTULO 12
Una solución para la generación de reportes en WEB es trabajar con reportes PDF.

Con este tipo de reporte, se cuenta con mayor potencialidad para el desarrollo de aplicaciones
web. El reporte generado como PDF puede visualizarse directamente desde el browser.

En este capítulo profundizaremos en la generación de reportes PDF.

Aplicación práctica de 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 “MovieCatalog”, de manera de
poder imprimir el catálogo completo de películas.

El nombre del objeto será “ViewCatalog”.

Lo primero es crear un objeto reporte con el siguiente layout:

(Puede diseñar el layout del reporte como usted lo crea más conveniente)

Haga clic aquí para ver el diseño del reporte.

Lo que haremos es un corte de control sobre la tabla “Gen_Movie”, de forma similar a como se
hizo en el webpanel “MovieCatalog”.

Haga clic aquí para ver la demostración..

Es necesario configurar las siguientes propiedades al objeto reporte recién creado:

 Main
 Call Protocol = HTTP
 Report OutPut = “Only to File”

Y la siguiente rule:

output_file('movies.pdf','PDF');
Haga clic aquí para ver la demostración..

Nota:

Para comprobar que el reporte ejecuta correctamente, basta con ejecutarlo directamente
desde el browser, digitando en nuestro caso la siguiente URL:

http://localhost/services/oViewCatalog.aspx

Haga clic aquí para ver la ejecución del reporte..

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

Seguidamente, pongamos en el webpanel “MovieCatalog” un link a este reporte.

Para eso, agregar un textblock en el form del webpanel, de nombre “PrintCatalog”, y en el

evento start del webpanel “MovieCatalog” agregar:

PrintCatalog.Caption = 'Print Catalog'

PrintCatalog.Link = link(RViewCatalog )
INTRODUCCION AL CAPITULO 13
Como mencionamos al comienzo del curso, los sitios están compuestos
normalmente de una combinación de paginas estáticas y dinámicas. Las páginas
dinámicas tardan mas en bajar que las estáticas, por la simple razón que tienen
que ejecutar antes de poder enviar la información al browser del usuario. Dentro de
este tiempo esta la conexión a la base de datos, la ejecución de las sentencias, etc.
Algunas veces este tiempo de ejecución no es necesario, ya que los datos no han
cambiado. Es por esta razón, que GENEXUS incluye una característica denominada
Smart Static Panels (SSP) que permite estatizar paginas de la aplicación. En este
capítulo vamos a ver que posibilidades nos brinda esta característica…

SMART STATIC PANELS

Introducción
El objetivo es posibilitar la generación inteligente de páginas estáticas desde GeneXus. Como
SSP entendemos la ejecución de un web panel dinámico para una instancia de datos que
recibe como parámetro, es decir archivos de texto conteniendo HTML con la información
obtenida a partir de la base de datos.

Estas SSP pueden convivir con los web panels dinámicos, tanto pudiendo llamarlos como
pudiendo ser llamados. Esto será muy útil en sitios de información (portales) donde gran parte
de la información, después de generada será estática.
Alcance
Lenguaje: C/SQL, Java, Visual Basic

Interfaces: Web

Descripción
La finalidad es permitir desde GeneXus la generación de páginas estáticas de una forma
inteligente, es decir consultando dinámicamente a la base de datos.

Porque usar SSP?

1. Se comportan con mejor performance que los objetos dinámicos

2. Recargan menos al servidor en tiempo de ejecución.

En que casos es viable la utilización de SSP?

1. Si existen páginas cuyo contenido varía en la base de datos con una periodicidad
conocida.
2. Si la aplicación puede soportar mostrar alguna información no on-line sino que se
actualice hacia el web con cierta periodicidad.

Generación de SSP
La preferencia a nivel del modelo denominada ‘Generation Mode’ de la sección Web
Information permite la generación de las páginas estáticas. Las opciones son:

1. Dynamic Panels
Este es el valor por defecto . Significa que el web panel se generará con acceso
dinámico a la base de datos.

2. Smart Static Panels’

Este valor significa que el web panel se generara en forma estática (SSP).
Esta generación de las páginas debe resolverse con anteriordad.

3. Create Static panels on request

Este valor significa que al ejecutar el web panel con acceso dinámico,
automaticamente se generará la página estática correspondiente a la
instancia de datos.

Este valor, permite tener un sitio compuesto por paginas dinámicas y

páginas estáticas sin que sea necesario ejecutar un proceso que genere
todo el sitio en forma estática con anterioridad, sino que estas páginas
estáticas se generarán para las instancias de datos que se requiera cuando
se ejecute la página dinámica correspondiente en el sitio.
Además de la preferencia Generation Mode, existe también la propiedad –con el
mismo nombre- a nivel de objeto. Los valores posibles son ‘Dynamic Panels’,
‘Smart Static Panels’, Create Static panels on request y ‘Use model’s preference
value’ (que es el valor por defecto).

Esta ejecución puede hacerse desde la línea de comandos o desde otro objeto GeneXus no
web. Analizaremos ambos casos.

¿Cómo funcionan las SSP?

La generación de SSP se logra a partir de la ejecución del web panel dinámico. Cuando este
web panel recibe parámetros existirá una SSP por cada instancia de datos posible.

El nombre de las SSP resulta de la concatenación del nombre del objeto web panel con la lista
de parámetros que recibe separados por el carácter ‘_’ y la extensión HTML.

Por ejemplo, se tiene el web panel Clientes que recibe como parámetros la Empresa (atributo
EmpID –num(3))y la categoría (CatId –char(1)), algunos nombres de las SSP son:

hcliente_203_A.html

hcliente_999_S.html

Si el web panel dinámico tiene eventos que ocurren en el servidor asociados a

controles del form (por ejemplo botones, o eventos Click asociados a imágenes,
etc) las SSP invocarán al web panel dinámico al ejecutar dicho evento.

Independientemente de la property Generation Mode por cada link a un web panel, si este
web panel esta marcado como estático, hace un call al web panel (de modo que este también
generará un .html, etc), y el link lo deja apuntando al archivo .html.

Los links a web transactions siempre seran a la transaccion web porque estas no se estatizan

Estatización de SSP
Denominamos Estatización al proceso de generación de las SSP correspondientes a un web
panel.
Existen varias formas de estatizar un sitio web:

 Generación a Pedido
 Generación desde objetos GeneXus.
 Generación desde la línea de comandos

La primera opción aplica cuando el web panel tiene el valor Create Static panels on request. La
generación de SSP a partir de objetos GeneXus y a partir de la línea de comandos aplican
cuando el web panel tiene el valor Static Panel y son útiles para generar estas páginas en
forma masiva para las posibles instancias de datos que existan en la base de datos.

GENERACIÓN A PEDIDO
La generación a pedido de las páginas SSP se realiza cuando la preferencia del modelo o del
objeto tienen el valor Create Static panels on request.

El sitio funcionará siempre como si fuera dinámico, esto significa que los links
siempre son al objeto web panel dinámico.

Al ejecutarse el web panel dinámico, lo primero que se controla es que exista la

página estática (.html ) correspondiente a si mismo incluyendo tambien los
parámetros que se le pasaron.
Si este archivo existe, se redirecciona la llamada a dicho html.
Si no existe automáticamente se crea el .html y luego se redirecciona.

Existen dos preferencias:

On request SSP server directory

Esta preferencia indica el directorio del servidor en donde el webpanel
genera los archivos .HTML. El directorio debe existir previamente.
Si no se especifica esta preferencia, se generarán en el directorio donde esta
el web panel.

On request SSP client URL

Esta preferencia indica la URL en donde estan los archivos html. Se
corresponde físicamente al mismo directorio que se configuró en la
preferencia anterior.

GENERACIÓN DE SSP A PARTIR DE OTRO OBJETO GENEXUS

Al invocar a un web panel -que tiene la preferencia Generation Mode con el valor
‘Static Panel’ - desde otro objeto GeneXus, se genera las página SSP
correspondiente al mismo para la instancia de datos recibida como parámetro.
Esto permite, por ejemplo, poner el mecanismo de generación de los SSP dentro
de un workflow.
PARÁMETROS ADICIONALES
Existen ciertos parámetros adicionales configurables al momento de invocar al
web panel que cambian el funcionamiento del programa.
Los parámetros soportados son:

SSP Directory

Indica el directorio en donde se generarán las SSP. Si no se especifica se

generan en el directorio corriente.

SSP Dynamic URL

Indica la URL base para los web panels dinámicos. Si una SSP tiene
un link a un web panel dinámico, se agrega esta URL antes del nombre del
mismo. Además, si la SSP tiene un evento que ocurre en el servidor (por
ej. Un botón) , al dispararlo se hace un ‘POST’ al web panel dinámico cuyo
nombre es el valor de este parámetro y el nombre del web panel. Esto
implica que se puede tener un SSP en el cual cuando se dispara un evento
se llama al dinámico.

Si no se especifica esta propiedad, no se agrega ningún prefijo a los web

panels dinámicos que se invoquen.

SSP Overwrite pages

Indica si se generan las SSP para los que ya existe un archivo .html con ese
nombre. Si no se especifica esta propiedad siempre se sobrescribe (se
asume ‘true’ ).

Este parámetro es útil en muchos casos en que una nueva generación de SSP no significa
que toda la información anterior deje de ser válida.

Un ejemplo de esto es una lista con información clasificada según la fechas

(calendario de cursos, calendario de partidos jugados, etc) donde en la
página se tiene la información –que después de generada no cambiará – y
un link a la fecha anterior y a la fecha siguiente.
Si la generación de las SSP se hace en forma diaria, el parámetro deberá
tener el valor overwrite en false para que no regenere todas las páginas sino
solamente la última (la del día). Además habrá que borrar la de la fecha
inmediata anterior para que se genere nuevamente con el link a la fecha
siguiente corregido (ya que la última página no tiene habilitado el link a la
siguiente).

SSP Expand Links

Indica que se recorran todos los links del web panel principal. Si no se
especifica esta propiedad siempre se recorren (se asume ‘true’)
 SSP Copy directory
Indica el directorio al que se copian las SSP una vez terminada la
generación. Se copian en orden inverso al que fueron generadas, de modo
que primero se pongan los ‘hijos’ y luego los ‘padres’.

Si no se especifica esta propiedad, no se copian a ningún lugar

FUNCIÓN SETENVPROPERTY
La función SetEnvProperty permite configurar los parámetros adicionales.
La sintaxis es:

&aux = Setenvproperty('genexus.property', &value)

Por ejemplo:

&aux = Setenvproperty('genexus.staticwebdir', ‘d:\ssp’)

FUNCIÓN COPYSTATICFILES.
Esta función permite realizar la copia de las SSP generadas a otro directorio, por
ejemplo:

&aux = copystaticfiles()

GENERACIÓN DE SSP A PARTIR DE LA LÍNEA DE COMANDOS

Las SSP se generan como resultado de la ejecución de un web panel -que tiene la
preferencia Generation Mode con el valor ‘Static Panel’ - desde la línea de
comandos. Los parámetros adicionales tambien pueden configurarse desde la
línea de comandos pero la sintaxis es diferente según el generador. Por mas
detalles referirse a los documentos:

 Consideraciones en C/SQL
 Consideraciones en Java
 Consideraciones en Visual Basic
Estatización de Web Components
Cuando se genera como Static Panel un Web Panel que incluye Web Components,
tambien se estatiza el Web Component dentro de la página.

Consideraciones
En la generación de los smart static panels, los parámetros juegan un papel muy importante,
ya que el nombre del archivo creado depende de los valores de los mismos, por lo que para
que funcione correctamente la llamada entre web panels dinámicos y smart static panels es
necesario que se pasen y se reciban los parámetros con el mismo tipo de datos.

Por ejemplo, tener un programa A que llame a uno B pasando un parámetro en un Numérico
de 10 (N(10)) y el B lo reciba en un N(10,2) dará problemas ya que se generará con decimales
(como el llamado)pero se invocará sin decimales (como el llamador).

Ejecución desde el browser

Cuando el SSP se invoca desde el browser, se comporta como un web panel normal,
resolviendo automáticamente para cada link si el web panel llamado es estático o dinámico.

FAQ – Preguntas frecuentes

P: ¿Qué es un SSP?.

R: un SSP en si no es nada mas que un objeto GX que tiene esa propiedad

marcada. En si es muy similar a cualquier webobject solo que genera el HTML

en lugar de mandarlo al browser y que cualquier link a él apuntara al HTML

y no al exe o servlet correspondiente.

P: ¿Porque se llaman SSP y no Páginas Estáticas ? ¿No confunde eso?

R: Estatico es el HTML resultado de la ejecución de un SSP. Es decir, hay web panels dinámicos
(un EXE, un servlet) hay SSP (un EXE o servlet con la property "generation mode" en SSP) y hay
HTMLs que son el resultado de la ejecución de un SSP.
Normalmente un sitio se formará con dinámicos y/o HTMLS pero en el "background" se tienen
dinámicos y SSPs que generaron esos HTMLs.

P: ¿Se pueden tener combinadas, es decir, algunas dinámicas y otras SSPs ?

R: si, es decir, puedo tener algunos dinámicos y otras generadas mediante SSP.

P: ¿Puede un web panel dinámico llamar a un SSP?

R: si claro, puede haber cualquier combinación de llamadas. SSP-SSP,

SSP-Dinámico, Dinámico-SSP.

P: En que casos aplica una solucion 100% SSP?

R: La solución de los SSPs puede aplicar a muchos problemas diferentes y

dependiendo del mismo es lo que se hace. Normalmente serán sitios con web panels
dinámicos y tambien SSP. Pero un ejemplo totalmente SSP puede ser para armar un CD tipo
Demo de mi sitio y distribuirlo. Se indican todos los objetos como SSP, y ejecutando
CALL(HMAIN) generarán todos los HTMLS del mismo.

Como solución para bajar la carga del servidor Web, se pueden definir algunos SSPs y otros
Dinámicos.

SSP - Consideraciones del generador C/SQL

Generación de SSP a partir de la línea de comandos
Los parámetros adicionales necesarios para la generación de páginas SSP a configurar en C/SQL
son los siguientes:
Static Web Directory /sd:<dir>

Static Web Dynamic URL /su:<url>

Static Web Overwrite pages /so:< true|false>

Static Web Links /sl:< true|false>

Static Web Copy directory Parámetro no soportado

Estos parámetros adicionales se pasan en la línea de comandos después de los parámetros que
el nombre del programa C pudiera tener.

Ejemplo:

Hmainwp “/sd=c:\\” /su=http://server/mydirectory /so:false /sl=true

Limitaciones
El generador C/SQL no soporta la propiedad genexus.static.copydir y la función copystaticfiles.

SSP - Consideraciones del Generador JAVA

Generación de SSP a partir de la línea de comandos
Los parámetros adicionales necesarios para la generación de páginas SSP a configurar en Java
son los siguientes:

Static Web Directory genexus.staticweb.dir=<dir>

Static Web Dynamic URL genexus.staticweb.dynurl=<url>

Static Web Overwrite pages Genexus.staticweb.overwrite=<true|false>

Static Web Links genexus.staticweb.links=<true|false>

Static Web Copy directory genexus.staticweb.copydir=<dir>

Estos parámetros adicionales se pasan en la línea de comandos antes del nombre del
programa Java. La sintaxis es diferente dependiendo de la máquina virtual que se utilice.
Máquina Virtual

Sun/IBM java –Dparámetro = valor <objeto a ejecutar>

Microsoft jview /d:parámetro = valor <objeto a

ejecutar>

Si se ejecuta con la maquina virtual de Sun o IBM, y la cantidad de web panels estáticos a
generar es grande, se recomienda aumentar la memoria máxima disponible para la aplicación.
Esto se hace agregando un parámetro -Xmx<memoria en MB>m al 'java.exe'.

Por ejemplo:

java -Xmx100m hmywebpanel

Esto le da 100 MB de memoria máxima a la máquina virtual Java.

EJEMPLO:

java -dgenexus.staticweb.dir=c:\

-dgenexus.staticweb.dynurl=http://server:8080/servlets

-dgenexus.staticweb.overwrite=false

-dgenexus.staticweb.links=true –dgenexus.staticweb.copydir=d:\ hmainwp

Antes de ejecutar el comando, es necesario configurar correctamente el classpath de la

aplicación, agregando las clases de GeneXus, el archivo ‘servlet.jar’, los drivers JDBC, las clases
standard de Java y el directorio corriente.

Por ejemplo:
set
classpath=GeneXusclassr.zip;j:\tomcat\lib\servlet.jar;j:\drivers\jt400.jar;j:\jdk11\lib\classes.zip
;

SSP - Consideraciones Visual Basic

A diferencia de otros generadores, con Visual Basic no es posible ejecutar los SSP desde la línea
de comandos, solo pueden ser ejecutados al ser llamados por otro objeto.

Los parámetros a configurar son:

Parámetro

SSP Directory genexus.staticweb.dir=<dir>

SSP Dynamic URL genexus.staticweb.dynurl=<url>

SSP Overwrite pages genexus.staticweb.overwrite=<”true”|”false”>

SSP Expand Links genexus.staticweb.links=<”true”|”false”>

SSP Copy directory Parámetro no soportado

NOTA: Para poder utilizar las funciones que permiten configurar los parámetros adicionales
desde las aplicaciones GeneXus (función setenvproperty), se debe configurar la preference
‘Functions = Allow non-standard functions’ tanto en diseño como en prototipo.

Para poder ejecutar los SPPs y que los mismos generen los HTMLs correspondientes se deben
seguir los siguientes pasos:

- Compilar el Web Panel que tiene la propiedad ‘Generation Mode=Smart Static Panel’
(generando la página ASP y la DLL), o alternativamente ejecutarlo en forma
interpretada (si se quiere se puede cerrar el browser y dejar solamente la ejecución
del VBP).
- Ejecutar el objeto que va a establecer los parámetros y llamar al SSP.
- Al ejecutarse los SSP se despliega una ventana que indica cuales fueron los HTMLs
generados por la ejecución de los SPPs. Esta ventana se corresponde con un utilitario
llamado GXLOG.EXE.

Ejemplo
Se tiene un Web Panel (PruebaSSP) que será ejecutado como SSP y Work Panel (Llamador)
que será el encargado de ejecutarlo.
A continuación se detallan los pasos a seguir para ejecutar los SSP:

Agregar en el Work Panel ‘Llamador’ un evento como el siguiente:

Event 'Llamada’

&aux = setenvproperty('genexus.staticweb.dir', 'd:\ssp')

&aux1 = setenvproperty('genexus.staticweb.dynurl', 'http://localhost/cgi-bin/')

&aux2 = setenvproperty('genexus.staticweb.overwrite', false)

call(HPruebaSSP, ….)

EndEvent

Los parámetros adicionales que se configuraron fueron:

genexus.staticweb.dir para indicar donde quedarán las páginas HTML (d:\ssp)

genexus.staticweb.dynurl para indicar la URL correspondiente a los Web Panels dinámicos que
serán llamados desde los SSPs (http://localhost/cgi-bin/)

genexus.staticweb.overwrite para que no se sobreescriban los SSP para los que ya existe un
archivo .html con ese nombre.

 Compilar el Web Panel ‘PruebaSSP’ (se genera la página ASP y la DLL) o si se quiere
ejecutarlo en forma interpretada.
 Ejecutar el Work Panel ‘Llamador’, y ejecutar el evento ‘Llamada’.

Al ejecutar el evento ‘Llamador’ se generan las páginas HTML correspondientes al SSP, que
quedarán en el directorio ‘d:\ssp’.

Limitaciones temporales
 El generador VB no soporta el parámetro genexus.static.copydir y la función
copystaticfiles.
 No se pueden encriptar los parámetros de los Web Panels generados como estáticos.
 No se pueden utilizar funciones de Cookies en Web Panels generados como
estáticos.
  Si se realiza la ejecución de SSPs, se cierra el utilitario GXLOG.EXE y se vuelve a
realizar una nueva ejecución (sin haber cerrado previamente el programa que
ejecutó el SSP y el proyecto del Web Panel con la propiedad ‘Generation
Mode=Smart Static Panel’ en caso de ejecutarlo interpretado) se produce el siguiente
error:

Para que no ocurra, se debe cerrar el programa que ejecutó el SSP (y el proyecto del Web
Panel en caso de ejecutarlo interpretado), y volverlos a ejecutar.

INTRODUCCION AL CAPITULO 14
En el desarrollo de una aplicación web, la calidad de la interfaz con la que
interactúa el usuario determina el éxito de la aplicación. La calidad de la misma
está definida por una serie de pautas y técnicas. A este conocimiento se le llama
“Usabilidad”.

La interfaz de una aplicación web está determinada a grandes rasgos por la

estructura de la aplicación, el diseño de la misma y de su contenido.

Con estructura de la aplicación nos referimos a la ubicación de los diferentes

elementos para que sean encontrados de forma intuitiva por el usuario y utilizados
de forma correcta. Hay que tener esta estructura bien definida antes de aplicar un
diseño.

El diseño de la aplicación es la parte gráfica de la misma, el conjunto de

imágenes, colores, formas que va a tener la aplicación.
El diseño del contenido permite que el mismo sea cómodamente leído y
correctamente interpretado.

A lo largo de este capítulo desarrollaremos cada uno de estos puntos para lograr
aplicaciones web exitosas y fáciles de usar.

 Estructura de la aplicación
 Diseño de la aplicación
 Diseño del contenido

ESTRUCTURA DE LA APLICACIÓN
Con estructura de la aplicación nos referimos a la ubicación de los diferentes elementos para
que sean encontrados de forma intuitiva por el usuario y utilizados de forma correcta. Hay que
tener esta estructura bien definida antes de aplicar un diseño.

Es importante que la estructura del sitio esté reflejada en todas las páginas en
forma consistente.

A la hora de definir la estructura en sitios corporativos, en general es

recomendable no reflejar el organigrama de la empresa, sino reflejar una
estructura de acciones a realizar o de información a encontrar. No invente la
rueda, siempre que pueda aprenda de sitios exitosos de su misma área o
aplicación para realizar una estructura similar, que resulte intuitiva para el mismo
público objetivo.

Es recomendable:

Mostrar las barras de navegación en todas las páginas. Con formato: Numeración y viñetas

No cambiar la ubicación de las opciones de los menús según cambien las
páginas (mantener consistencia).

Aplicar los mismos conceptos para las mismas acciones (links, botones,
bullets, etc.).

No poner links a la misma página en la que me encuentro.

Permitir que el usuario siempre controle la navegación: no deshabilitar botones
estándares de los navegadores ni botones del mouse.

Si usa un mapa del sitio (Sitemap) brinde la información de donde está el
usuario en cada momento. Puede incluir una pequeña descripción de qué
ofrece cada opción del menú.

Navegación
La navegación de una aplicación permite ir a las distintas partes, sectores,
páginas de la aplicación rápidamente y en forma intuitiva. La estructura del sitio
se debe reflejar en la navegación permitiendo contestar las siguientes preguntas:

¿Dónde estoy?
- Dentro del universo de sitios/ aplicaciones web
 Esto se logra mostrando el logo del sitio/ aplicación web en todas las
páginas. La ubicación habitual del mismo, y por lo tanto el lugar donde el
usuario lo irá a buscar, es la esquina superior izquierda. Esta imagen debe
tener siempre un enlace a la página de inicio de la aplicación o la página
principal del sitio.

- Dentro de la estructura de la aplicación web. Para ello se

recomienda:
 Marcar la opción seleccionada en la barra de navegación.
 Usar títulos en cada una de las páginas, dentro del área de contenido de
forma que el usuario sepa dónde se encuentra.
 Nombrar las páginas en el cabezal de las mismas para que se identifiquen
en el grupo de páginas que tiene abiertas el usuario. En GENEXUS esto se
hace usando la propiedad Caption del Form (Form.Caption). Para mostrar
el nombre de la aplicación y de la página se puede usar un formato como
los siguientes:
 Sitio: página (Ej: GeneXus: Capacitación)
 Sitio – página
 Sitio > página
 Usar nombres cortos para las páginas igual que para los sitios de modo que
se puedan visualizar bien en el cabezal de la página.

¿Dónde estaba?
- Para indicar las páginas que el usuario ya visitó, conviene dejar los
colores de los enlaces con los colores por defecto del navegador.
-
¿A dónde puedo ir?
- Mostrar todas las opciones a donde puede ir el usuario desde la página
actual, sin marearlo con demasiadas opciones. Si las opciones son
muchas, convieene agruparlas por áreas o sectores y dentro de los
mismos mostrar submenús.

Herramientas de búsquedas (search)

Si usa una herramienta de búsqueda, ésta debe de estar en todas las páginas del
sitio, en un lugar siempre visible sin tener que usar las barras de desplazamiento.
El lugar más intuitivo es el cabezal superior derecho, o la columna del menú
izquierdo.
Se recomienda hacer esta funcionalidad lo más simple posible de manera que sea
fácil de usar. Lo más sencillo es tener una caja de texto (textbox) y un botón que
diga buscar. El uso de iconos, etiquetas, etc. necesita que el usuario las interprete
y por lo tanto demore unos segundos en entender su uso.
El resultado de la búsqueda debe ser claro, debe mostrar la cantidad de instancias
encontradas, el texto usado para realizar la búsqueda, el título de cada página
que contiene el texto buscado y un enlace en ese título a la página
correspondiente.
Menús
Menú superior
Tanto en sitios corporativos como en intranets y extranets se usa comúnmente un menú
superior que contiene generalmente las siguientes opciones:

1. Página de Inicio
Si bien hay un enlace en el logo de cada página, nunca está de más
repetirlo ya que la página inicial es a la que se retorna con más asiduidad.

2. Acerca de, Acerca de Nosotros, Acerca de La Empresa, La Empresa, Quiénes somos,

etc.
Siempre es válido un enlace a información sobre la empresa que
representa ese sitio, el producto que se vende a través del sitio, etc. que
respalde la seriedad y veracidad del contenido presentado en el mismo.

3. Mapa del sitio, Mapa, etc.

En la zona superior derecha se ubican las herramientas para encontrar páginas y contenido
dentro del sitio, la ubicación de la herramienta de búsqueda y del mapa del sitio.

4. Contacto, Contáctenos, Contáctese, etc.

Este enlace debe conducir a una página que contenga información para contactar a la
empresa a través de teléfonos, emails y direcciones físicas. Esta opción del menú no debe
ser un enlace a un correo electrónico, ya que incomoda al usuario porque ejecuta su
aplicación de manejo de emails.

En aplicaciones web, este menú generalmente contiene:

Enlace a la página de inicio de la aplicación Con formato: Numeración y viñetas

Enlaces a información importante, no relativa a la aplicación en particular o a
la parte de la aplicación desplegada en la página, pero que sirva para la
aplicación entera, que sirva de respaldo, etc. Ejemplo: información de
registro del usuario (a la izquierda), idiomas de la aplicación, área de ayuda,
contacto con soporte, página de la información de la empresa, etc.

Menú de áreas
Muchas veces se usa el área de cabezal para ubicar un menú de áreas o categorías dentro
de la aplicación o del sitio. Generalmente se utiliza cuando hay demasiadas opciones
para ubicar en el menú izquierdo (más de 10). Categorizar los enlaces y agruparlos en
áreas simplifica la navegación haciéndola más intuitiva.
Menú izquierdo
Este menú contiene las opciones de navegación del sitio, todos los lugares del sitio a
donde se puede acceder.
En muchos sitios el menú izquierdo cambia según el área en la que el usuario se
encuentre.
Se debe mantener el mismo diseño del menú, independientemente de las opciones, para
que al usuario sepa cómo usarlo ya que aprendió su uso en otras áreas del sitio.

Links
Hay tres tipos de links:

Links estructurales (de navegación) Con formato: Numeración y viñetas

Links asociativos. Los clásicos links que se asocian a una palabra para ver más
información relacionada a la misma.

Links de información relacionada (Related links)

Algunas recomendaciones para la definición de links:

Cuando se definen links subrayar las palabras importantes y brindar Con formato: Numeración y viñetas
información suficiente para que el usuario se sienta atraído a seguir el link.

Relacionar la información con links del tipo "más sobre tal tema", o sobre el
autor, etc.

Usar “link title” siempre que no sea obvio a donde va el link, para que
aparezcan los tooltips:
oSi el link es externo, el nombre del sitio
oSi es interno, el nombre del subsitio.
oInformación adicional que se aplique
oEl tooltip debe tener menos de 60 caracteres.

Mantener siempre el color predeterminado para los diferentes links.

Siempre usar los mismos nombres para acceder al mismo contenido.

DISEÑO DE LAS PÁGINAS DE LA APLICACIÓN

El diseño de la aplicación es la parte gráfica de la misma, el conjunto de imágenes, colores,
formas que va a tener la aplicación.
Se debe diseñar pensando en

1. Velocidad de carga
2. Público objetivo
3. Uso de la aplicación
4. Máximo aprovechamiento de los temas

Velocidad de carga
El tiempo que demora en cargarse la totalidad de una página determina la percepción que va a
tener el usuario de ese sitio o aplicación. Si la aplicación demora en cargarse, el usuario
pensará que no es buena, que no le solucionará sus problemas de forma correcta. Si la demora
es excesiva, el usuario puede llegar a pensar que la empresa no es fiable.

Para mejorar los tiempos de carga se recomienda:

Usar texto en vez de imágenes siempre que se pueda (ej: para los menús) Con formato: Numeración y viñetas

El formato de las imágenes siempre debe de ser .gif o .jpg, nunca .bmp, ya que
este formato pesa mucho más que los anteriores.

Usar herramientas para disminuir el peso de las imágenes. Ej:
http://www.netmechanic.com/GIFBot/optimize-graphic.htm

No usar imágenes animadas.

No usar flash, ya que no sólo demora más la carga de la página, sino que
muchas veces requiere que el usuario instale la tecnología.

No hacer páginas que requieran el uso excesivo de las barras de
desplazamiento horizontal. Esto no sólo ahuyenta al usuario por el tiempo
que le consume, sino también por la cantidad de contenido que se le
presenta. Es mejor hacer páginas más cortas, con la información suficiente, o
armar más páginas a partir de una.

Público objetivo
Debe tener en cuenta quién será el público objetivo –a quién se dirige, quiénes serán los
usuarios- a la hora de diseñar y elegir los colores, los tamaños de las letras y tamaños de las
pantallas.

Por ejemplo, si el público objetivo está integrado por desarrolladores, se puede hacer un sitio
o una aplicación con letras de tamaño 8 puntos, pero no se recomienda usar este tamaño para
un público masivo.

Uso de la aplicación
Cuando está diseñando también debe considerar cuál es la finalidad de la aplicación para no
entorpecer el uso del servicio que se desea brindar.
Si se trata de un sitio Web donde se ofrece bastante texto para leer no es recomendable que
las páginas tengan sectores que llamen más la atención que el contenido principal de la
página. Por ejemplo, las imágenes animadas son centros de atención. Es realmente molesto
tener imágenes moviéndose en distintas partes de la página cuando se tiene que leer.

Se pueden usar imágenes animadas si su movimiento se detiene una vez presentada la

animación. De esta forma, se logra captar la atención del usuario que ingresa a la página para
transmitir el mensaje que se desea con esas imágenes, y luego, se facilita al usuario la
concentración para la lectura del texto principal.

Si el sitio web es un portal, donde se espera encontrar muchos focos de atención (textos
cortos, muchos links) es más adecuado usar imágenes animadas.

Máximo aprovechamiento de los temas (Themes)

Maximizar el uso de los temas permite ajustar el diseño en tiempo de ejecución. Es
recomendable que cada ítem que se use esté definido en el tema, de forma por ejemplo, que
todos los títulos tengan la misma apariencia y si más tarde se quiere agregar espacio entre el
título y el contenido se pueda modificar automáticamente en todos los títulos de la aplicación.
Esto es válido para cada tabla usada en la aplicación, desde la que contiene las opciones del
menú hasta la que contiene el contenido, las grillas, las etiquetas de los formularios, etc.

DISEÑO DEL CONTENIDO

La forma de escribir en Internet difiere a la usada en publicaciones físicas, principalmente
porque es más difícil leer en la pantalla y el público es más exigente con el tiempo que le
consume obtener una información. Debido a esto hay que escribir para Internet teniendo en
cuenta las siguientes pautas:

Escribir lo más corto y conciso posible. Se dice que en Internet hay que escribir
entre un 50% y un 25% menos de lo que se escribiría en papel
Poner las conclusiones al principio y una opción para ver el detalle de esa
conclusión
Tipo de letras
Se deben tener las siguientes consideraciones a la hora de elegir el tipo de letra a utilizar en
una aplicación Web:

1- El tipo de fuente debe estar instalada en las máquinas destino

2- El tamaño debe ser adecuado para el público objetivo y para la resolución más
usada

3- Elegir un estilo de letra (serif o sans serif) y no mezclar estilos

Los tipos de fuentes que en general se encuentran instaladas en todas las

máquinas son Arial, Verdana y Times New Roman.

Legibilidad

Definición de Legibilidad. f. Capacidad o posibilidad de ser leído, por su claridad.

La buena tipografía depende -entre muchas otras variables- del contraste visual
entre una fuente y otra, y entre los bloques de texto, los títulos, y el espacio en
blanco alrededor. Lo que más atrae al ojo es el contraste fuerte con patrones
distintivos.

Seguir patrones que conserven la forma de organizar el texto y las imágenes en

las distintas páginas de un sitio o una aplicación permite entender la organización
de la información, intuir la ubicación de más información y se aumenta la
legibilidad de la misma.

La lectura va a ser más cómoda cuanto mayor sea el contraste de los colores. El
mayor contraste se logra con fondo blanco y letras negras.

Se pueden establecer las combinaciones de colores en el editor de temas, en la

clase "Form" y jugar con las mismas sin tener que cambiar ni una línea de código.

Márgenes
Los márgenes definen el área de lectura de una página, separando el texto
principal de lo que lo rodea.

Los márgenes y el espacio en blanco se usan para delinear el texto principal de

otros elementos de una página, y usados de igual manera en todas las páginas
proveen uniformidad a través del sitio creando una estructura consistente y una
identidad visual.

Es recomendable que los textos principales tengan un margen de 5 a 10 píxeles.

Esto se logra en GeneXus poniendo el texto dentro de una tabla con borderwidht
=0 y cellpadding=10.

Cellpadding: especifica la distancia en píxeles entre el contenido y los bordes de la celda.

Cellspacing: especifica el ancho en píxeles de los bordes de la celda.

Alineación de los textos

La alineación izquierda de títulos y contenidos es la más recomendable para el público
occidental.

Los usuarios en Internet en general no leen los textos palabra a palabra, sino que escanean las
páginas tomando algunas palabras de cada párrafo para entender la idea general de la página.
La alineación izquierda facilita este tipo de lectura.

LINKS DE INTERÉS

Usabilidad
Sitios con artículos sobre usabilidad y temas relacionados con mejora en los sitios Web

En español
http://www.masterdisseny.com/

http://sunsite.dcc.uchile.cl/~rbaeza/inf/usabilidad.html

http://www.alzado.org/

En inglés
http://www.useit.com/

http://www.37signals.com/

http://www.usabilitynet.org/

http://usableweb.com

http://www.w3.org/TR/WCAG20/

http://www.hildesheim.co.uk/usability/index.html

Herramientas
Herramientas para reducir el peso de las imágenes
http://www.netmechanic.com/GIFBot/optimize-graphic.htm

http://www.creatingonline.com/crunchers.htm

http://www.gifworks.com/
Toolbar con varias herramientas de análisis y optimización de
sitios
http://www.nils.org.au/ais/web/resources/toolbar/install.html

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

REQUERIMIENTOS DEL GENERADOR C/SQL

El generador GENEXUS C/SQL permite que el ciclo de desarrollo se realice con independencia
de una conexión a una red (local o Internet) o, utilizando un servidor (máquina diferente a la
de desarrollo).

Llamaremos instalación local a aquella que es independiente de una conexión a una red e
instalación remota a la restante.

La instalación local es soportada únicamente en Windows.

Además, como el generador GENEXUS C/SQL permite acceder a los datos utilizando la
tecnología de acceso SQL Embedded u ODBC, llamaremos instalación SQL Embebida a aquella
que accede a los datos mediante sentencias SQL embebidas en el código fuente e instalación
ODBC a la que se conecta vía ODBC.
Es posible tener cualquiera de las combinaciones, instalación SQL embebida local, SQL
embebida remota, ODBC local, ODBC remota. Detallaremos a continuación los requerimientos
específicos de cada caso.

Siempre es requerido en ambiente de desarrollo:

 Compilador C
 Rutinas de soporte del generador

Compilador
Normalmente en ambientes UNIX, el compilador C viene incluido con el sistema
operativo. Si se utiliza ODBC como tecnología de acceso a los datos, se requiere
un compilador C++, el cual no viene incluido. Puede utilizarse el compilador GCC,
que puede obtenerse en http://gcc.gnu.org

En ambientes Windows, el compilador no viene incluido con el sistema operativo. En este

caso, lo mas común es utilizar Microsoft Visual C++.

Rutinas de soporte del generador C/SQL

Las rutinas de soporte son un conjunto de archivos (bibliotecas, include files, etc.)
que son utilizadas (referenciados) por los programas generados por el generador
C/SQL. Estas rutinas se distribuyen en formato fuente y deben ser instaladas
(compiladas, etc.) antes de intentar compilar o ejecutar una aplicación
generada.

Durante el proceso de instalación el utilitario GENEXUS C/SQL Setup Wizard

instala, en cada ejecución, las rutinas necesarias para cada DBMS. Si se quiere
instalar para más de un DBMS, en el caso en que la tecnología de acceso sea Sql
embebido, será necesario ejecutar el GENEXUS C/SQL Setup Wizard tantas veces
como DBMSs se tenga.
Estas rutinas debe ser instaladas una única vez por servidor (salvo nuevas
versiones).

Por más información sobre el proceso de instalación de las rutinas de soporte, referirse a
“GeneXus C/SQL Setup Wizard”.

Instalación SQL embebida

Se requiere:

 Precompilador del DBMS correspondiente

 Instalar las rutinas de soporte para el DBMS
Precompilador
Cada proveedor de DBMSs tiene su propio precompilador, que normalmente se
vende como un producto adicional. Solo es necesario si la tecnología de acceso a
utilizar en las aplicaciones desarrolladas es SQL embebido.

DBMS Precompilador

DB2 Client Application Enabler

Informix ESQL C

Oracle Pro*C

Instalación ODBC
 Instalar las rutinas de soporte para ODBC.
Ver “Configuración de ODBC en ambiente Uníx”.

Instalación remota
Los siguientes son requerimientos específicos para el caso de realizar una instalación remota:

 Conexión TCP/IP
 Esquema de transferencia: Copy/FTP
 Activación del servicio REXEC

Conexión TCP/IP desde la estación de trabajo

Cada estación de trabajo deberá disponer de una conexión vía TCP/IP con el servidor donde se
realizará la compilación.

Esta conexión se utiliza para transferir los fuentes generados al servidor y para la ejecución de
comandos remotos (REXEC) requeridos para efectuar la compilación de programas.

El esquema de transferencia vía FTP y ejecución remota se basa en la especificación Winsock

1.1 por lo que, prácticamente, cualquier producto que provea soporte TCP/IP puede ser
utilizado.
El programa que realiza la transferencia y compilación (GXWC.DLL) requiere directamente los
servicios de la WINSOCK.DLL. Esta DLL puede, dependiendo del proveedor de conexión de
TCP/IP, requerir a su vez otras DLLs.

Transferencia de fuentes
La transferencia de fuentes de los programas generados permite tres esquemas
básicos: FTP, Copy y Don't transfer.

Los dos primeros asumen que el directorio del modelo (especificado en Model
Properties/Target path) no está en el servidor (o no coinciden con el directorio de
programas a donde se desea transferir/copiar los fuentes) y que, por
consiguiente, se necesita transferir los fuentes allí generados para poder
compilarlos.

El tercer esquema (Don' transfer) asume que el directorio mencionado arriba

coincide con el directorio de los programas (es decir, donde se desea generar los
ejecutables) y, en consecuencia, no es necesaria la transferencia.
Si se selecciona FTP como esquema de transferencia, es necesario que el servidor
tenga disponible y 'escuchando' el servicio de FTP (ver más adelante cómo
activarlo y consultar con el administrador del servidor por particularidades de su
instalación).

Si se selecciona Copy o Don't transfer como esquemas de transferencia, la

estación de trabajo debe 'ver' los discos del servidor como discos de red. En otras
palabras, el servidor debe funcionar también como servidor de archivos para la
estación. En esta situación, no es necesario activar el FTP.
Activación del servicio de FTP
Para activarlo, la operativa varía en función del sistema operativo del
servidor.

Unix
Normalmente, este servicio se encuentra instalado y activo. Si no lo
estuviera, los siguientes son los pasos a seguir para activarlo. Se requiere
autorización especial (root) para realizar esta tarea.

 Conectarse al servidor en una terminal (telnet por ejemplo) con un

usuario administrador (root).
 Modificar el archivo /etc/inetd.conf agregando/modificando la línea:
ftp stream tcp nowait root /etc/ftpd ftpd
 Ejecutar el comando: refresh -s inetd

Windows
Para usar el servicio de FTP se requiere tener instalado Internet Information
Server 4.0 o Personal Web Server 4.O en adelante.
En el caso de Personal Web Server el servicio de FTP no se instala por
defecto.
Activación del servicio de REXEC
Con el fin de realizar la compilación de los fuentes generados, se requiere el
servicio de ejecución remota (REXEC) activo en el servidor.

El servicio REXEC siempre debe estar activo para compilar los fuentes generados.
Para hacerlo la operativa varía en función del sistema operativo del servidor.

Unix
Normalmente, este servicio se encuentra instalado y activo. Para verificar
que el servicio está activo, ejecute los siguientes pasos:

 Acceda a una terminal del servidor o utilice un programa de emulación

de terminal (telnet) y realice el login.
 Ejecute el siguiente comando; el resultado debe ser que la fecha y hora
de servidor se muestran en la pantalla.

rexec host_name time

host_name es el nombre simbólico del servidor o su dirección IP.

Nota: Aún cuando esté activado (el test anterior fue satisfactorio), puede
que no sea posible acceder al servicio desde su PC (máquina de desarrollo
donde está instalado GENEXUS y el generador C/SQL). Normalmente, esto
se manifiesta al intentar instalar las rutinas de soporte o compilar un
programa generado, mediante un mensaje del tipo ‘Invalid login’ o 'The
login is not correct' (el mensaje puede variar dependiendo del servidor Unix
pero el sentido es el mismo). En este caso, la causa probable del problema
es que la dirección IP del PC no es una dirección válida desde la cual, el
servidor Unix, pueda recibir solicitudes de REXEC o que la dirección IP del PC
varíe pues se está utilizando DHCP. Ver comentarios del mensaje ‘Invalid
login’ en la sección Problemas Comunes.

Si el servicio no está activado, los siguientes son los pasos a seguir para
activarlo. Se requiere autorización especial (root) para realizar esta tarea.

 Conectarse al servidor en una terminal (telnet por ejemplo) con un

usuario administrador (root).
 Modificar el archivo /etc/inetd.conf agregando/modificando la línea:
exec stream tcp nowait root /etc/rexecd rexecd
 Ejecutar el comando: refresh -s inetd

Windows
Este sistema operativo no provee en forma nativa (al momento de la
escritura de este manual) del servicio de ejecución remota REXEC. El
servicio necesario puede ser provisto por programas de diferentes casas de
software y debe ser comprado aparte.

Nuestra empresa ha evaluado el que vende la firma Ataman Software, Inc.

(Fort Collins, Colorado USA) que funciona correctamente y tiene un bajo
precio.
Ver la dirección internet http://www.ataman.com/atrls_info.htm.
Instalación local

En el caso de realizar la instalación local solo se requiere del Compilador C, y la

instalación de las rutinas de soporte (luego los requerimientos van a depender de
si la Tecnología de acceso es ODBC o Embebido- lo cual se especifica en este
mismo documento)
Nota: Usuarios de Oracle en ambientes Unix

Para compilar en este ambiente, el generador C/SQL, utiliza archivos del Pro*C
que el usuario debe copiar al directorio de las rutinas de soporte, modificando
dicha copia según el siguiente detalle.
Hacer una copia del archivo 'proc.mk' que, normalmente, está en el directorio
$ORACLE_HOME/precomp/demo/proc en el directorio donde se instalaron las
rutinas de soporte.

Modificar el archivo proc.mk (del directorio de rutinas de soporte) de la siguiente

manera:

Buscar una línea que tiene el siguiente código (o similar):

INCLUDE=$(I_SYM). $(PRECOMPPUBLIC)

Si encuentra la línea, realizar los siguientes cambios:

INCLUDE=$(I_SYM). $(PRECOMPPUBLIC) $(GX_INC)

Si no la encuentra, buscar la línea que tiene el siguiente código (o similar):

CFLAGS=-I. -O

Realizar los siguientes cambios:

CFLAGS=-I. -O $(GX_INC)

Buscar el siguiente bloque de código (o similar):

# Rule to compile any program (specify EXE= and OBJS= …

if [ "$(ORA_CLIENT_LIB)" = "shared" ]; then \
$(CC) -o $(EXE) $(OBJS) -L$(LIBHOME) $(PROLDLIBS); \
else \
$(CC) -o $(EXE) $(OBJS) -L$(LIBHOME) $(PROLLS); \
fi
Realizar los siguientes cambios:

# Rule to compile any program (specify EXE= and OBJS= …

if [ "$(ORA_CLIENT_LIB)" = "shared" ]; then \
$(CC) $(GX_CFLAGS) -o $(EXE) $(OBJS) -L$(LIBHOME)
$(GX_LIBS) $(PROLDLIBS); \
else \
$(CC) $(GX_CFLAGS) -o $(EXE) $(OBJS) -L$(LIBHOME)
$(GX_LIBS) $(PROLLS); \

El proc.mk es dependiente de la plataforma y la versión de Oracle utilizados.

El siguiente es otro ejemplo que pertenece a AIX 4.3 y Oracle 8i:

$(MAKE) -f $(MAKEFILE) samples LIBHOME=$(ORACLE_HOME)/lib64/
PRODLIBHOME=$(PRODLIBHOME64) CFLAGS="$(CFLAGS64)" LFLAGS="-q64 -
b64"

build: $(OBJS)

$(CC) $(LFLAGS) -o $(EXE) $(OBJS) -L$(LIBHOME) $(GX_LIBS)

$(PROLDLIBS)

build64:

$(MAKE) -f $(MAKEFILE) build LIBHOME=$(ORACLE_HOME)/lib64/

PRDLIBHOME=$(PRODLIBHOME64) RDBMSLIB=$(ORACLE_HOME)/rdbms/lib64/
CFLAGS="$(CFLAGS64)" LFLAGS="-q64 -b64"

build_static: $(OBJS)

$(CC) $(LFLAGS) -o $(EXE) $(OBJS) -L$(LIBHOME)

$(STATICPROLDLIBS) $(AIXIMP)

build_static64:

$(MAKE) -f $(MAKEFILE) build_static

LIBHOME=$(ORACLE_HOME)/lib64/ PRODLIBHOME=$(PRODLIBHOME64)
RDBMSLIB=$(ORACLE_HOME)/rdbms/lib64/ CFLAGS="$(CFLAGS64)"
LFLAGS="-q64 -b64"

$(SAMPLES) $(OBJECT_SAMPLES):

$(MAKE) -f $(MAKEFILE) OBJS=$@.o EXE=$@ build

LIBHOME="$(LIBHOME)" PRODLIBHOME="$(PRODLIBHOME)"
CFLAGS="$(CFLAGS)" LFLAGS="$(LFLAGS)"

INCLUDE=$(I_SYM). $(GX_INC) $(I_SYM)$(PRECOMPHOME)public

$(I_SYM)$(RDBMSHOME)public $(I_SYM)$(RDBMSHOME)demo
$(I_SYM)$(PLSQLHOME)public $(I_SYM)$(NETWORKHOME)public

Requerimientos .Net

Los requerimientos de software de Web objects en .Net se van a dividir en dos partes, los
requerimientos para el ambiente de desarrollo y los requerimientos en producción.
Requerimientos para desarrollo
Además de los requerimientos básicos de GeneXus 8.0 (espacio en disco, cantidad de
memoria, etc.), cada equipo deberá disponer de:

PLATAFORMA .NET
Para utilizar esta versión es necesario tener instalada la versión release del
Framework Redistributable 1.1 y el runtime de Jsharp (en caso de generar
reportes PDF).

GENEXUS
o Development environment GeneXus 8.0
o Generador .Net 8.0
OTROS
- Cliente y servidor de Base de datos de prototipo.

- Internet Information Server para prototipación.

IMPORTANTE: El mismo debe ser instalado antes del .NET Framework SDK.

Importante: Para usuarios Oracle se requiere en el cliente el driver 8.1.75 o superior

Requerimientos en producción
REQUERIMIENTOS ESTACIÓN DE TRABAJO
En la estación de trabajo de los usuarios de una aplicación desarrollada con Web objects lo
único que se necesita es disponer de un browser y una conexión al servidor donde están los
Web Panels.

REQUERIMIENTOS SERVIDOR
Los requerimientos en producción son similares al ambiente de desarrollo.

 Servidor Web: Internet Information Server (5.0 o superior)

• Microsoft J# .Net Redistributable Package 1.1 (para reportes PDF)

• Microsoft .Net Framework 1.1

• Driver ODBC y dlls de acceso ODBC (solo si la conexión es ODBC y no ADO)

Instalación en el Cliente
Alcanza solamente con un browser.

Instalación en el servidor
Alcanza solamente con una copia de los objetos y el archivo de configuración web.config.

REQUERIMIENTOS GENERADOR VISUAL BASIC

Requerimientos para desarrollo

En Visual Basic 6.0 existen nuevas facilidades para generar aplicaciones para Internet, la más
notoria son las llamadas WebClasses Designers. Estos objetos son programados en Visual
Basic y al compilarlos se crea una DLL, que será ejecutada por el Web Server (Microsoft
Internet Information Server), y un archivo .ASP (Active Server Page) que sirve como punto de
entrada para cada clase en la DLL.

Requerimientos estación de trabajo

Para poder compilar y/o ejecutar en forma interpretada los objetos Web generados como
WebClasses se necesita:

 Windows 98, Windows 2000, Windows XP con un Personal Web Server instalado o con
Internet Information Server 4.0 o superior.
En principio puede ser también Windows 95 o cualquier sistema operativo
que soporte un Personal Web Server de Microsoft.
En el caso de Windows NT 4.0 (o superior) se necesita el Internet Service
Manager.
 Instalar Visual Basic 6.0 SP3 o superior
 Instalar Visual Interdev
 Permisos de creación de objetos COM
Hay que ejecutar la aplicación Dcomcnfg, que se encuentra en el directorio
system32 del servidor, para dar permisos de creación de objetos al usuario
que ejecuta los objetos Web.

Para ejecutar y/o compilar Objetos Web Cliente/Servidor, se necesita además:

 Software cliente del DBMS

 Drivers ODBC
 Datasource del modelo definido
  Configurar la preference “Show Connection Dialog = No”, y setear el usuario y la
password de conexión a la base de datos para que no se despliegue el diálogo de
conexión a la base de datos. Si no se configura esta preference con el valor No, se va a
producir un error en el momento de ejecutar los objetos Web.

Puesta en producción
Una vez que los objetos Web fueron probados en forma interpretada se deben compilar y
llevar al servidor de producción.

La información sobre como poner en producción los objetos Web VB generados como
WebClasses se encuentra en:

Puesta en produccion de objetos Web VB generados como WebClasses

Por más información se recomienda el documento:

Objetos Web Visual Basic generados como WebClasses

APLICACIONES WEBGENERADOR JAVA

Introducción

Existe una API especificada por Sun Microsystems que se llama 'Java Servlet API'. Esta API
define la forma de ejecutar lo equivalente a los objetos web de GENEXUS (web panels, web
transactions, web components), por lo tanto, el generador Java, por cada objeto web de
GENEXUS, genera lo que se llama un Servlet.

Los Servlets proveen una gran cantidad de ventajas que el generador Java aprovecha, como
por ejemplo, la utilización de un pool de conexiones a la base de datos y la multiplataforma.

A su vez, el generador Java provee una funcionalidad adicional que consiste en que los Objetos
objetos Web web pueden enviar la página HTML comprimida, para que sea descomprimida en
tiempo real por el navegador. La compresión se realiza solo si el navegador indica que es capaz
de descomprimirlo. Esta opción puede deshabilitarse con la preferencia 'Auto compress web
pages', para contemplar el hecho de que algunos navegadores no reporten correctamente su
capacidad para descomprimir las páginas, y no las puedan desplegar correctamente. En las
pruebas que hemos realizado, esta funcionalidad se ha comportado de forma correcta con
todos los navegadores.
Requerimientos
Para poder ejecutar Servlets, es necesario contar con:

1) Un Servidor Web
2) Un Motor de Servlets
3) JavaServer Web Development Kit

El Servidor Web y Motor de Servlets, son dos servicios que se requieren (en un mismo servidor
físico, o no) para poder ejecutar Servlets.

En teoría, las aplicaciones GENEXUS pueden ejecutarse con cualquier Motor de Servlets que
sea compatible con la especificación de Servlets 2.1 o posterior.

Algunos de los motores que se han utilizado exitosamente son:

 IBM WebSphere en Windows, RS/6000, Unix OS/390, Linux y AS/400

 JRun en Windows
 Jakarta Tomcat en Windows y Linux
 Resin en Windows y Linux
 Apache Jserv en Windows y Linux

Por su parte, el JavaServer Web Development Kit, se instala automáticamente con la

instalación del Motor de Servlets, y permite que el desarrollador pueda compilar los Servlets
(objetos web de GENEXUS).

A continuación explicaremos los pasos en orden, que se deben seguir para configurar y utilizar
estos requerimientos. Explicaremos en forma conceptual y genérica cada punto, y tomaremos
a modo de ejemplo, la opción de utilizar el Motor de Servlets RESIN para Windows, en forma
local, con el fin de mostrar un ejemplo práctico concreto.

Al final de este capítulo, se incluyen URL’s a papers técnicos que describen la configuración de
otros motores de servlets.
Configuración de un Motor de Servlets
Para ejecutar una aplicación web Java, se debe configurar un motor de servlets; para ello se
deben realizar algunos pasos, que si bien varían un poco según el motor de servlets que se
vaya a utilizar, básicamente los pasos a seguir, son similares.

Primeramente, vamos a introducir el concepto de webapp, relacionado a los motores de

servlets.

Qué es una webapp?

Cada motor de servlets crea y maneja una webapp. El nombre webapp resulta de la
abreviación de "web application" y consiste en un directorio base, que contiene a su vez una
estructura de subdirectorios determinada, en la cual se deben distribuir los archivos que sean
necesarios para la ejecución de una aplicación web.

Los tipos de archivos involucrados en la ejecución de una aplicación web, pueden ser los
servlets (archivos .class), contenido estático y librerías adicionales (archivos .JAR).

Una vez visto este concepto, pasemos a detallar entonces los pasos a seguir para configurar un
motor de servlets:

1) Instalar el motor de servlets.

2) Definir una webapp o bien identificar cuál es la webapp por defecto para utilizarla.
3) Copiar drivers JDBC y clases standard de GENEXUS (gxclassr.zip) al directorio “lib” de la
webapp.
4) Levantar el motor de servlets.
5) Tests
a. Ejecutar el servlet de ejemplo del motor de servlets, para comprobar que la
instalación haya sido correcta, así como comprobar que el motor haya
levantado bien.
 b. Ejecutar el servlet: com.genexus.webpanels.gxver, que devuelve la versión de
las clases standard de GENEXUS. Mediante la ejecución de este servlet se
puede comprobar primeramente que se están encontrando las clases standard
de GENEXUS y luego, que se trata de la misma versión con las que se
generaron los servlets.

A modo de ejemplo, si se utiliza RESIN en Windows, en forma local, se deben seguir los
siguientes pasos:

1) Instalar el motor de servlets: para ello, simplemente se debe descomprimir un

archivo de instalación .ZIP en algún directorio del equipo servidor (por ejemplo en
c:\resin).
2) La webapp por defecto en este caso, es: C:\resin\doc\
3) Copiar las clases standard de GENEXUS (gxclassr.zip) y las clases del driver JDBC al
directorio C:\resin\doc\WEB-INF\lib
4) Para levantar el motor de servlets, se debe ejecutar c:\resin\bin\httpd.exe.
5) Tests
a. Para verificar que el RESIN haya levantado bien, se debe ejecutar el servlet
que viene de ejemplo accediendo de la siguiente forma:
http://localhost:8080/examples/basic/servlet/HelloServlet

b. Para verificar que se estén tomando las standard de GENEXUS y cuál versión,
se debe ejecutar:
http://localhost:8080/servlet/com.genexus.webpanels.gxver

PROPIEDADES DE EJECUCION C/SQL

A continuación se detalla el significado de cada una de las opciones que figuran en el diálogo
de configuración del F5.

Host Name: Corresponde al nombre del servidor o su dirección IP.

Script Name: Indica el nombre del script utilizado para compilar los objetos C/SQL. Se asume
que este archivo se encuentra en el directorio especificado en Support Files.

Program Directory: Esta opción es sólo informativa e indica el valor especificado en la opción
"Programs directory".

Transfer
FTP Service: se selecciona para transferir vía FTP.
Copy Files: se selecciona para copiar los fuentes.

Don’t Transfer: se selecciona si se está trabajando sobre la misma máquina donde se va a

realizar la compilación.

Force transfer: bajo el directorio de la aplicación se crea un directorio "Update" que contiene
un archivo vacío con el mismo nombre del archivo que se transfiere, de forma que al transferir
se comparan las fechas y si está actualizado la transferencia no se realiza. Si se marca, siempre
se transfieren todos los archivos.

Submit Mode
REXEC: se selecciona si se desea ejecutar la compilación en forma remota (otro servidor).

Local Exec: se selecciona si se compila sobre la misma máquina donde está el modelo.

Port: Es el número de puerto activo del servicio REXEC. Normalmente es el 512. Este servicio
es utilizado para ejecutar comandos remotos, es requerido para compilar los programas.

Timeout (sec.): Esta opción le indica a GeneXus cuánto tiempo debe dar al servidor para
responder. 0 le indica que espere en forma indefinida.

PROGRAMS DIRECTORY AS SEEN FROM CLIENT: Este campo es válido sólo si se seleccionó
Copy files como método de transferencia de archivos. Es el nombre del directorio donde van
los programas visto desde el cliente.

PROGRAMS DIRECTORY AS SEEN FROM FTP: Es análogo al anterior, pero cuando se elige FTP
service como método de transferencia. Si el directorio no existe el mismo es creado al realizar
la transferencia.

START URL: Es el directorio base para los objetos web. Al seleccionar un objeto web del
diálogo del F5 (Run) y presionar el botón Execute, se va a abrir el browser por defecto definido
en la estación de trabajo.

USER NAME/PASSWORD: es el usuario y la password utilizas para la transferencia.

REMEMBER PASSWORD: se selecciona para guardar la contraseña.

Propiedades de ejecución .Net
A continuación se detalla el significado de cada una de las opciones que figuran en el diálogo
de configuración del F5.

COMPILER PATH: Determina el path del compilador (csc.exe), este se encuentra bajo el
directorio de instalación del framework en

C:\WINNT\Microsoft.NET\Framework\v1.1.4322

VIRTUAL DIRECTORY: Determina la URL base de ejecución, esta contiene el directorio virtual a
ser creado (si no existe) por GeneXus en el Internet Information Service (IIS) local. El momento
de la creación es luego de la compilación y reorganización.

Propiedades de ejecución Visual Basic

Visual Basic 6.0 Path:
Indica el path del ejecutable VB6.EXE.

Execution Mode

Compile & Execute

Esta es la opción por defecto cuando se está trabajando con Web Panels Visual Basic, ya que
para poder ejecutar estos objetos, es necesario compilarlos antes. También se utiliza esta
opción antes de poner en producción los Web Panels Visual Basic, ya que es necesario
compilarlos para poder ejecutarlos en el servidor.

Opciones Propiedades de ejecución para aplicaciones

webJava
Para la ejecución de aplicaciones web con Java, se debe:

1) Referenciar en el classpath las clases necesarias para compilar los servlets (clases
correspondientes al JavaServer Web Development Kit). El archivo puede llamarse servlet.jar o
jsdk.jar o jsdk22.jar (dependiendo del Motor de Servlets que se utilice) y por lo general se
encuentra en el subdirectorio LIB del Motor de Servlets. Estas clases se deben referenciar en el
classpath, además, del resto de los archivos de clase que se requieran referenciar en dicha
variable de entorno.

2) Indicar en el Web Server Root la URL que el navegador utilizará como base para la
ejecución de los servlets.

Siguiendo el ejemplo que venimos viendo en el cual se utiliza el Motor de Servlets RESIN para
Windows, instalado en forma local, a continuación indicamos lo que corresponde
completar en las opciones de ejecución para dicho caso:

1) classpath=gxclassr.zip;.;<driverjdbc>;c:\resin\lib\jsdk23.jar

2) Web Server Root= http://servername:8080/servlet

PROPERTIES A CONSIDERAR EN EL
DESARROLLO DE OBJETOS WEB
En los modelos GeneXus, existen properties que aplican exclusivamente a los objetos web.
Algunas a nivel del modelo de diseño por lo que aplican a toda la base de conocimiento y otras
se encuentran a nivel de los generadores (por lo que aplican al modelo de prototipo o
producción que lo utilice).

Properties generales
Estas properties se definen a nivel del modelo de Diseño. Se setean mediante la opción
File/Edit Model/Properties teniendo abierto el modelo de diseño.

Las relacionadas con objetos web son:

  Base Image Path

Propertiess a nivel del Generador

A nivel de cada modelo, existen algunas properties (en la sección Web Information) que
aplican exclusivamente a los web panels.

GENERATION MODE
Esta property permite especificar si los objetos web del modelo se generarán
como objetos dinámicos (acceden a la base de datos) o como páginas html
inteligentes (smart static panels).

También existe la posibildad de generar smart static panels a pedido mediante

el valor “Create Static panels on request” de esta preferencia. Si se elige este
valor, cuando se ejecuta un webpanel, chequea si existe un .html que
corresponda a si mismo, con los parámetros que se le pasaron. Si existe, se
redirecciona la llamada a dicho html. Si no existe, se crea el .html y luego se
redirecciona.

Por mas información referirse a la documentación de Smart Static Panels

Existe también la propiedad a nivel de objeto con los mismos valores que la
propiedad del modelo y también el valor Use model's property value.

FOCUS CONTROL
Esta property permite determinar si los objetos web, al mostrar su página,
intentan posicionar el foco en el primer control de entrada (no read-only) o
dejan librado al Browser la posición del foco.

Los valores posibles son:

First input att/var on the page
Browser dependent

Existe también la propiedad a nivel de objeto con los mismos valores que la
propiedad del modelo y también el valor Use model's property value.

PROTOCOL SPECIFICATION
Esta property permite especificar el protocolo a utilizar en la url generada para
invocar a los objetos web.
Tiene tres valores posibles: Unsecure (HTTP), Secure (HTTPS) y 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 generar HTTPS como protocolo e indica que el
protocolo a utilizar es el Secure Hypertext Transfer Protocol. Para utilizar este
protocolo es necesario disponer de un servidor seguro.

El valor Do not specify indica que no se especificará un protocolo particular,

 sino que se utiliza el mismo protocolo empleado para acceder al web panel
actual.
En el caso de tener aplicaciones con un esquema mixto: algunas páginas
seguras y otras no, la property del modelo deberá setearse 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 property permite especificar si se desea encriptar los parámetros que se
envían entre objetos y que son visibles en la URL del browser.
Por más información referirse a la documentación: Encriptación de parámetros.

ON REQUEST SSP SERVER DIRECTORY

La property ‘On request SSP server directory’ es requerida cuando se generan
SSP (Smart Static Pages) en forma dinámica. Por más información referirse a la
documentación de Smart Static Panels.

ON REQUEST SSP CLIENT URL

La property ‘On request SSP client URL’ es requerida cuando se generan SSP
(Smart Static Pages) en forma dinámica. Por más información referirse a la
documentación de Smart Static Panels.

Properties de .Net
Estas properties se definen a nivel del modelo .Net y se setean mediante la opción File/Edit
Model/Properties teniendo abierto dicho modelo.

Namespace

Determina el namespace de la aplicación. Los programas generados por GeneXus y compilados

con .Net se encuentran disponibles bajo el namespace indicado por esta property. El default es
GeneXus.Programs. Sirve para los usuarios avanzados que quieren hacer algun tipo de
deployment en el GAC.

Valor por defecto : GeneXus.Program.

Use .Net control

Determina la forma de hacer el rendering de los controles HTML ( para EditBox, CheckBox,
RadioButtons, ListBox y Buttons), en web panels y web transactions. Por default esta en "No".
Cuando el valor es Yes, indica que el rendering se hace utilizando controles .Net para generar
el HTML necesario. Estando en "No" indica que use el rendering standard generado por
GeneXus en todas sus plataformas, este último garantiza compatibilidad en el look and feel
entre las distintas plataformas Web generadas por GeneXus.

Valor por defecto : No

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

Compiler options
La información de esta property se incluirá en el .rsp que se usa para compilar el main.

Es útil por ejemplo para generar información de debug (incluyendo el string “/debug”) o para
incluir una dll dentro del namespace (/r:xxx.dll ).

Manejo de contenido estático

Las aplicaciones web manejan además del código (servlets) y archivos de configuración
(client.cfg), contenido estático. El mismo consiste en imágenes, javascripts y en particular un
archivo denominado Styles.css que contiene información sobre formato, colores, fuentes, etc.
utilizados en el diseño del objeto web.

Para el manejo del contenido estático, se centralizan todos estos archivos en un directorio
determinado, en el servidor donde correrá la aplicación web. Para indicar este directorio se
utiliza la preference Static content base URL.

Entonces, el servlet generado buscará el contenido estático en el path resultante de

concatenar la URL de la webapp en donde está corriendo el servlet, con el nombre del
directorio donde se encuentre el contenido estático (indicado en la preference Static content
base URL). Esto podrá visualizarse con “View source” del html generado por el servlet y al
ejecutar el servlet (en el navegador).
Por ejemplo, si se inserta en un objeto web una imagen con el nombre "Imagen.jpg", y en la
preference Static content base URL se especifica el valor "/imagenes" y el servlet se instala en
la webapp cuya URL es "/Ejemplo", el camino a la imagen va a quedar de la siguiente forma:
/Ejemplo/imagenes/Imagen.jpg. Por lo tanto, se debe crear un directorio ‘imagenes’ bajo la
URL de la webapp y copiar la imagen en él para que se visualice al ejecutar el objeto web.

Nota: Esto es válido para las imágenes que no estén involucradas con los objetos HTML. Por
ejemplo las imágenes que se ponen en los background de las tablas o celdas no están
comprendidas en el caso anterior. Este tipo de imágenes no van a concatenar ni la URL de la
webapp, ni la preference Static content base URL.

El resto del contenido estático como ser los javascripts (*.js) y el archivo styles.css que también
debe estar físicamente en el mismo directorio que las imágenes, no es necesario copiarlos
manualmente como el caso de las imágenes, sino que en tiempo de compilación, el generador
los copia al mismo. Para ello hay que especificarle en la preference Static content directory
seen from client el path al mismo, con formato X:\imagenes, donde X:\ es el mapping a la URL
de la webapp.

Preference Servlet Directory

Para ejecutar los Servlets, una vez compilados, deben estar en un directorio específico de la
estructura obtenida al instalar el Motor de Servlets. La misma varía en cada caso, dependiendo
del Motor de Servlets que se utilice.

El propósito de la preference, es el siguiente:

Propósito
Permite especificar el directorio donde se transferirán los servlets
generados. En tiempo de compilación de cada objeto web, el generador los
copiará al directorio especificado.

Notas:
 Es necesario especificar este valor antes de generar, ya que se utiliza
para la generación del archivo de make.
 El path debe ser relativo al cliente, es decir un path visto desde el PC
en el que se está trabajando con GENEXUS.
 Se copiarán además de los archivos .class, los archivos .cfg, los
cuales contienen la información de las preferencias ingresadas; por lo
tanto, si se modifica algún valor de las preferencias del modelo, es
necesario volver a generar y compilar algún objeto web. Además,
para que se tome en cuenta este cambio al ejecutar, es necesario
reiniciar el servidor de servlets.

Ejemplos de valores
 H:\servlets - Si el motor de servlets está instalado en una máquina
mapeada con el “drive” H y servlets es el nombre del directorio
 donde deben residir los servlets.
 C:\resin\doc\web_inf\classes – Si el motor de servlets es el RESIN y
esta instalado localmente en el directorio C:\resin.

Preference Static Content base URL

Propósito
Indica el directorio donde los servlets buscarán el contenido estático
(imágenes, javascritps y styles.css) utilizado en los objetos web
correspondientes. Los servlets siempre ejecutan en el servidor, por lo que
este directorio debe especificarse relativo al directorio correspondiente a la
“base URL” de la webapp.

Notas:

Cambiar el valor de esta preference no implica regenerar la aplicación, sino

solo un objeto web. Si está en producción, solo basta con modificar el
archivo client.cfg.

Ejemplo de valores
Si se crea un directorio llamado “images” bajo el directorio raíz del webapp
donde se instalaron los servlets, y a él se copian todas las imágenes
necesarias, y en diseño solo se especifica el nombre de la imagen, entonces
en esta preference habría que poner /images.
Preference Static Content directory seen from client
Propósito
Permite especificar el directorio donde se transferirán los javascripts (archivos
*.js) que se generan para los menubars de objetos web y web panels
generados como estáticos. En tiempo de compilación, el generador los copiará
al directorio especificado.

Notas:
 En este mismo directorio también habrán archivos de imágenes que se
utilicen en los objetos web. Los mismos se deben copiar manualmente
a este directorio, y en los programas generados se referenciarán
utilizando el valor de la preference “Static Content Base URL”
concatenada con el nombre de cada imágen.

 El path especificado debe ser relativo al cliente, es decir un path visto

desde el PC en el que se está trabajando con GENEXUS.

Ejemplos de valores
 X:\images - Si el servidor web está instalado en una máquina, mapeada
con el “drive” X y es el directorio “images” el utilizado para dejar el
contenido estático.
 C:\resin\doc\images – Si el motor de servlets es el RESIN, está instalado
localmente en el directorio C:\resin y se le creó el directorio images
donde se copiaron las imágenes.
 Con formato: Ancho: 21 cm, Alto:
29,7 cm, Distancia del encabezado
desde el borde: 1,25 cm, Distancia del
Preference Auto compress web pages pie de página desde el borde: 1,25
cm, Sin Encabezado de primera página
Propósito diferente

Los objetos web, en Java, pueden enviar la página HTML comprimida, de

modo que sea descomprimida en tiempo real por el navegador. La
compresión se realiza solo si el navegador indica que es capaz de
descomprimirlo.

Valores
Yes: envían la página comprimida.
No: no envían la página comprimida. Es posible que algunos navegadores
no reporten correctamente su capacidad para descomprimir las páginas, y
no puedan desplegarlas correctamente.

Default Value = Yes