1

Diseño de Aplicaciones para Internet

INTRODUCCIÓN
Conceptos básicos Web. Arquitectura y alternativas con GX Web Objects Web Panels Web Transactions Web Components Requerimientos y Configuración C/ SQL JAVA VB

2

CONCEPTOS BÁSICOS WEB WEB Páginas gráficas con hipertexto Dos tipos fundamentales: Páginas estáticas Páginas dinámicas (Aplicaciones) En el Web se distinguen, básicamente, dos tipos de páginas: •Páginas Estáticas •Páginas Dinámicas Páginas estáticas: Las páginas estáticas son las más sencillas. Se realizan usando un editor de páginas Web o bien escribiendo 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. Ej: Información general, Marketing, Información similar a la que se distribuye en folletos y documentos, Acceso rápido y cómodo a información, Direcciones 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 creada 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 favorecer los negocios de la empresa. De esta forma 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.

3
Páginas dinámicas (Aplicaciones): Clasificación (según frecuencia de visitas): Usuarios causales: Páginas dinámicas. Usuarios frecuentes: Aplicación JAVA. Una posible clasificación de las aplicaciones en Internet es teniendo en cuenta la frecuencia con que los usuarios las acceden: Usuarios casuales: Los usuarios de este tipo de aplicaciones son OCASIONALES, es decir, es alta la probabilidad de usarla una sola vez, o con una baja frecuencia (digamos una vez al mes). Además, se trata de aplicaciones sencillas, de muy fácil uso, que no requiera experiencia ni conocimiento previo por parte de sus usuarios. Un ejemplo de estas aplicaciones son las compras por Internet. Solución GeneXus: HTML - Web Paneis Usuarios frecuentes: los usuarios de este tipo de aplicaciones son más avanzados, y realizan un uso altamente frecuente, diario o hasta más de una vez al día. Un ejemplo de estas aplicaciones son sucursales, vendedores fuera de la central conectándose a los datos de la base centralizada, incluso ingresando y actualizando datos de sus ventas, stock, etc. Solución GeneXus: Java Algunas definiciones: URL: Uniform Resource Locator HTTP: HyperTex Transfer Protocol HTML: HyperTex Markup Language 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: HTTP: HTML: Uniform Resource Locator HyperText Transfer Protocol HyperText Markup Language URL: 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.artech.com Path/filename: Ubicación y nombre del documento en el servidos.

4
[Parm1, …, [parmn]]: Información opcional para consultas. 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. 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: Conexión Solicitud Respuesta Cierre 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á.

5
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. Si el servidor encuentra el recurso, éste es enviado al browser y se cierra la conexión. De lo contrario, un mensaje de error es enviado y la conexión es cerrada. Si el servidor retornó el recurso solicitado, el browser realizará la carga del mismo y será desplegado al usuario. HTML: <HTML> <HEAD> <TITLE> Esta es mi primera página</TITLE> </HEAD> <BODY> Esto muestra de una forma muy <I> simple </I>, la estructura básica de un documento HTML. </BODY> </HTML> 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 Generalizad 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 o Lynx 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.

6

El código HTML de la página anterior, se vería de esta forma en el browser Web.

Otros conceptos: CGI: Common Gateway Interface Web Classes Servlet ISAPI Para poder comprender mejor la tecnología escondida detrás de las aplicaciones desarrolladas para el web, es necesario aclarar algunos conceptos adicionales: CGI (Common Gatewav Interface): CGI es un estándar que define la interface 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: La solución de Microsoft para la ejecución de procesos en el servidor son las ASP o Active Server Pages. El servidor puede alterar una página utilizando ASP antes de enviarla al browser. Para poder utilizarlas se debe estar corriendo un servidor web de Microsoft (específicamente IIS 3.0 en adelante). De todas formas existen algunos productos de otras compañías que permiten correrlas sobre otras plataformas como UN IX. Serviets: Junto con JAVA aparecieron componentes para el web con la misma funcionalidad mencionada anteriormente en relación a CGI y ASP denominados serviets. Son clases JAVA que ejecutan en el servidor y permiten obtener información en forma dinámica que luego envían al cliente.

7

ISAPI (Internet Server Application Interface): Provee un mecanismo para desarrollar aplicaciones que se ejecutan en el espacio de direcciones del servidor Web en ambiente Windows, teniendo acceso a todos los recursos disponibles por dicho servidos.

8

ARQUITECTURA Y ALTERNATIVAS CON GX

Arquitectura General:

En la imagen 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 mismo 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.

9
Servidor Web:

¿Qué es un Servidor Web? Es un software que habilita al servidor la publicación de páginas Web (Web Server). Debe ser configurado, de forma que permita el acceso de usuarios de Internet. La imagen que se muestra, es simplemente un ejemplo de Servidor Web, hay que tener en cuenta que si bien la información a configurar es siempre la misma, el diálogo de configuración va a variar dependiendo del Servidor que se esté utilizando. 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. Usualmente este directorio raíz se denomina '/', para que los usuarios digiten únicamente la dirección Web en el browser para acceder a la página principal del sitio Web. Este directorio sólo tiene permiso de lectura. Para poder publicar páginas dinámicas, normalmente se debe definir uno o varios directorios adicionales con permisos de ejecución. Es muy común que este directorio sea denominado cgibin, cuando las páginas dinámicas utilizan cgi para acceder a la base de datos. Cabe destacar, que el nombre de este directorio puede ser cualquiera, y que también se puede definir más de uno. También en este caso se debe indicar el nombre "virtual" que será utilizado por los usuarios de Internet y su correspondiente ubicación en el disco del servidor.

10
Plataformas y alternativas:

Los generadores disponibles para generar Objetos Web son: •Visual Basic •C/SQL •Java Por lo tanto, pueden ejecutarse en un servidor Windows NT (VB, C/SQL, Java), en servidores UNIX (usando C/SQL, Java) o en servidores AS/400 (Java). Los Web panels podrán usar todas las bases de datos soportadas, dentro de las plataformas soportadas por cada uno de los generadores. 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. Bojetos Web: Arquitectura:

11

Al utilizar Web Objects 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 Web Object que realizara 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 Web Object (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. Bojetos Web: Arquitectura (Continuación)

12
Anteriormente se explicó el funcionamiento de un Web Object al ser ejecutado desde el browser. Los diferentes generadores utilizan diferentes tecnologías para solucionar el acceso a la base de datos. C/SQL: En el caso de C/SQL se utiliza CGI o ISAPI para los programas que devuelven la información requerida de la base de datos. Visual Basic: Si se generan Web Objects con Visual Basic, la tecnología va a depender de la versión utilizada. VB 5.0 genera programas CGI, mientras que con VB 6.0 se tiene la posibilidad de utilizar una nueva facilidad llamada 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 Web Objects 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, así como que permiten compartir conexiones a la base de datos. También permiten la compresión de páginas HTML.

13

WEB OBJECTS

Web Objects – Introducción:

Editor WYSIWYG orientado a páginas. Trabajando en pantalla completa. Ejecuta en el servidor.

Los Web Objects agrupan los objetos Web que se pueden desarrollar con GeneXus: Web Panels y Web Transactions. 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 Web Objects. •El trabajo se realiza a pantalla completa (diálogo full screen en lugar de campo a campo). •Los objetos ejecutan en el servidor. Editor de Web Objects: Tiempo de desarrollo ocupado en ‘armado’ de la página. Editor ‘WYSIWYG’ (similar al From Page). En la versión GeneXus 7.0, se incluyó un nuevo editor para objetos Web, cuya finalidad es potenciar y simplificar la edición del form de estos objetos, permitiendo crear fácilmente Web sites 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. La diferencia fundamental existente con respecto al editor que se disponía hasta el momento, es que el nuevo editor está 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.

14
FORM – Propiedades:

Al form de los web objects se le pueden asignar propiedades en tiempo de diseño y algunas de ellas pueden modificarse en tiempo de ejecución (mediante eventos). La última columna del diálogo indica si el valor asignado a la propiedad es el valor por defecto o no. El asterisco de color negro significa que el valor es el valor por defecto, el gris es que fue modificado. Backcolor: Se usa para setear el color del fondo del panel. Si se indica un background, el backcolor no va a tener efecto. Text Color: Color de los textos por defecto que estarán en el form. Background: Se utiliza para seleccionar el fondo del panel. Deben usarse bitmaps con extensión JPG o .GIF. Lo aconsejable es que estén en un directorio debajo de la raíz del Servidor Web. Background Properties: Esta propiedad es exclusiva de Internet Explorer y sólo funciona con la propiedad Background. Tiene un valor único fixed, el cual inmoviliza la imagen de fondo en la ventana del navegador, de modo que no se desplaza con el resto del contenido de la ventana. TooltipText: Texto que se muestra en tiempo de ejecución sobre cualquier parte del control. Word Wrap: Permite indicar si los controles del form tendrán o no word-wrap. Controles: De objetos Standard de Genexus: Edit Combo/ Combo dinámico/ List Box Checkbox Radio Button Botones Imágenes (*) Subfilo (*)

15

De Web objects de Genexus: Texto Text Block Tabla Subfile Free Style Embedded Page Web Component Los controles disponibles en Web Objects pueden dividirse en dos categorías: 1.2.Los que están disponibles en el resto de los objetos GeneXus, y Los que son particulares de estos objetos.

Dentro de la primera categoría tenemos: •Edit •Combo/Combo dinámico/List Box •Checkbox •Radio Button •Botones •Imágenes (*) •Subfile (*) Los controles marcados por (*) presentan algunas diferencias con respecto a su comportamiento en otros objetos GeneXus. Dentro de la categoría de controles particulares a los Web Panels se encuentran los siguientes controles: •Texto •Text Block •Tabla •Subfíle Free Styie •Embedded Page •Web Component Texto: Se puede escribir directamente dentro del Form. Es posible formatearlo utilizando la barra de herramientas del editor HTML.

16

Dentro de un Web Object se puede escribir un texto directamente dentro del form al igual que si se estuviera trabajando con un editor de texto. Esto ejemplifica una de las diferencias importantes entre el editor de objetos web y el editor del resto de los objetos GeneXus. Como se mencionó al comienzo, el editor de Web Panels es orientado a páginas y por lo tanto permite formatear el texto de la misma forma en que se realizan estas operaciones en un editor como Word. Link: Característica principal de WWW Permiten navegar entre páginas. Existe como función y como comando. El link o hipervínculo es una característica única del World Wide Web, y es lo que permite "navegar" al usuario. Puede estar asociado a una imagen o a un texto/de forma que cuando el usuario hace click sobre el mismo llama a otra página HTML. 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: Asociada a la propiedad Link de los controles. Sintaxis: • Control.link = link(‘html://www.artech.com.uy’) • Control.link = link(<objeto>, [par1],…[parn]) Para definir un link en GeneXus, existe una función llamada link, la cual puede ser asociada a una imagen, un texto, un atributo o variable que recibe una serie de parámetros como se detalla a continuación. La sintaxis de la función es: Link(UsrPgm/URL,[<Parl>,...,<ParN>]) Donde: UsrPgm/URL: Puede ser otro Web Panel o la URL absoluta o relativa de otra página estática o dinámica. <Parl>...<ParN>: son los parámetros que recibe la página llamada.

17

Estos parámetros son opcionales, ya que como mencionamos anteriormente se puede estar llamando a una página estática. Ejemplos de uso: Llamada con objeto (relativa): Unk(Hregistracion) Llamada absoluta: LinkChttp^/www.artech.com.uy/webpnl.htmr) Llamada relativa con pasaje de parámetros: LinkChupdcl¡.exe/,CliCod) Llamada con contenido de atributo: link(att:CI¡Lnk) Comando Link: Permite redireccionar a una URL. Equivalente al comando call. Sintaxis: Link(<URL> , <parm1>, ...,<parmn>) Link(‘http://www.artech.com.uy') El comando link es equivalente al comando call para llamar a páginas estáticas o redireccionar a una URL estática. Este comando puede ser utilizado dentro de cualquier evento en un Web Panel 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: l¡nk(<URL> , <parm1>, ...,<parmn>) Donde: <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. Ej.: Event ENTER Link(‘http://www.artech.com.uy') Endevent CALL en Web Objects: Sintaxis análoga a la del resto de los objetos. No pueden realizarse llamadas a programas que tengan salida: De un Web Object o a un procedimiento o reporte que no tenga salida en pantalla.

18
Tener en cuenta que el programa está ejecutado en el servidor. El comando call no presenta grandes diferencias con respecto al resto de los objetos. Es importante siempre tener en cuenta que los Web Objects 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.

Calls v/s Links: Pueden hacerse call’s a: • Web Objects • Procedimientos Son permitidos link’s a: • Web Objects • Páginas HTML estáticas. Para relacionar Web Objects 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 web object se puede hacer CALL a: •Web Objects •Procedimientos (que no tengan "salida") La función y el comando LINK puede hacer referencia a: •Web Objects •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 Web Object. La única forma de llamar a un procedimiento es con un call. Frames: Frames: división de página (o ventana) en varias áreas. División vertical y horizontal. Sintaxis: <FRAMESET rows/cols = “XX%, *”> <FAME src = “page.html” name = “namef1”> … </FRAMESET> No se pueden definir Frames desde Gexexus, pero se puede trabajar con Frame en Genexus.

19
La división de una página (o ventana) en varias áreas es muy utilizada para facilitar la navegación del usuario dentro de un sitio. Cada una de estas áreas donde se cargan diferentes páginas en forma simultánea se denomina frames. Todas las páginas que definen trames comienzan con el tag <frameset>, que remplaza el tag <body> de las paginas HTML normales. Este tag describe la forma en que la página se divide. Estas secciones a su vez, también pueden ser divididas en otros frames. La sintaxis utilizada para definir trames, es la siguiente: <FRAMESET rows/cols="XX,*"> Con el valor rows o cols se indica si las secciones (trames) definidas son horizontales o verticales. A continuación, separados con coma, se indican los anchos de cada uno de los frames a definir. El ancho de los trames puede estar definido como porcentaje (Ej.: 20%) o en pixeles (Ej.: 200). El valor asterisco (*), indica que el último valor se calcula como la diferencia del ancho total de la ventana con anchos de los trames previamente definidos. Ejemplo: <frameset cols="66%,*"> En el ejemplo se definen dos columnas, la primera (izquierda) ocupa el 66% del ancho total de la ventana, mientras que la segunda ocupa la diferencia, es decir, el 34%. A continuación se debe definir un tag <FRAME> por cada una de las secciones. En este caso la sintaxis es: <FRAME src = "page.html" frame ="framef1"> En SRC se define la página inicial que se carga y en FRAME se debe indicar un nombre (interno) que será utilizado cuando se quieran definir links entre los frames. Para definir un trame el tag correspondiente debe ir fuera del tag <BODY>, en caso contrario crea una página en blanco y no considera los tags del trame. Por este motivo, no es posible definir trames desde GeneXus, ya que todo lo que se encuentra dentro del Form del Web Panel, así como el código de los eventos va entre los tags <BODY></BODY>. Sí es posible usar trames con GeneXus. Para esto, se deberá definir en HTML una página, solamente con la definición de los trames y que invoque a los web panels. LinkTarget: Propiedad asociada a la propiedad link. Permite trabajar con Frames en genexus.

20
Hacer referencia al “name” de un frame definido. Sintaxis: Control.linktarget = ‘ namef1’ El uso de la propiedad esta orientado al manejo de Frames y/o ventanas del Browser y tiene sentido cuando la propiedad Link del control tiene un valor diferente al string vacío. Esta propiedad, asociada a la propiedad Link del control permite establecer en qué ventana (o instancia) del Browser se mostrará un Link cuando sea seleccionado. Todos los Links cuyo LinkTarget tenga el mismo valor se mostrarán en la misma ventana (o instancia). La excepción es para el valor "_blank" de la propiedad LinkTarget. Este es un valor especial que fuerza al Browser a crear una nueva ventana cada vez que se selecciona un Link. Edit – Propiedades diseño: En diseño:

El control edit es el mismo que se encuentra en el resto de los objetos GeneXus, salvo que posee algunas propiedades que son particulares de los objetos web. En diseño se pueden modificar las siguientes propiedades: ControlType: Esta propiedad permite indicar el tipo del control asociado a variables. Los tipos posibles son: Check Box, Combo Box, Dynamic Combo Box, Dynamic List Box, Edit, List Box, Radio Button. ReadOnly: Esta propiedad permite indicar si un control es modificable o no. Es válido únicamente para variables. Tiene dos valores posibles: 1. True: se despliega el contenido de la variable en el control y no es posible modificarlo. Es el único valor posible para los atributos.

21
2. False: aplica únicamente a variables y es el valor que tienen por defecto. Se puede ingresar el contenido de la variable. AutoResize: Esta propiedad permite indicar si el control mantendrá o no el tamaño por detecto. Se dispone de dos valores: 1. True: mantiene el tamaño por defecto del control. 2. False: habilita la modificación del tamaño del control. Fill: Esta propiedad permite indicar si el control toma el color de fondo del form o no. Es válido únicamente para controles Read Only. Tiene dos valores posibles: 1. True: se despliega el color de fondo seleccionado. 2. False; se despliega el color de fondo del Web Object. Backcolor: permite indicar el color de fondo del control. Forecolor: permite indicar el color del contenido del control. Si el control es editable depende del browser la visualización del mismo. Font: permite indicar el tipo, tamaño y formato del tipo de letra del control. Si el usuario no tiene instalada dicha font en su PC, se ignora esta configuración. Format: se verá más adelante. ReturnOnClick: está relacionada con Prompts. Se verá más adelante. Edit – propiedades ejecución: En ejecución: Enabled Backstyle FontUnderline FonBold, FontItalic, FontName, FontSize, FontStrikeThru, FontUnderline ForeColor IsPassword Link LinkTarget Visible

Enabled: La propiedad Enabled de Runtime tiene el mismo comportamiento que la propiedad Read only en diseño, pero los valores son los opuestos, es decir readonly = true es lo mismo que enabled = 0 y por otro lado readonly = false es lo mismo que enabled = 1.

22
Backstyie: La propiedad Backstyle es equivalente a la propiedad Fill de diseño. Indica si el control va a ser transparente o no. FontBold, Fontitalic, FontName, FontSize, FontStrikeThru, FontUnderline: permiten Forma-tear el tipo de letra a utilizar. ForeColor: Se usa para setear el color del contenido del control. IsPassword: Tiene como resultado el desplegar * en lugar de lo digitado por el usuario. Ej.: &var.IsPassword=1 Link: Esta propiedad permite asociar un link a un control. El link se va a ejecutar únicamente si el control tiene la propiedad Enabled en 0 (o esta marcado como Read only). Imágenes: 2 Ambientes: Diseño. Ejecución Path físico v/s virtual C:\kb\imágenes\img.gif /imágenes/img.gif Cuando se trabaja con Web Objects se pueden distinguir dos ambientes muy diferentes: el de diseño y el de ejecución. Ambiente de diseño: Nos referimos al ambiente en que se desarrollan los Web Objects. Ambiente de ejecución: Se refiere a la ejecución propiamente dicha de los Web Objects. En particular esto es muy importante al trabajar con imágenes, ya que en diseño las mismas se buscan en el camino ingresado (ej: c:\modelo\imagenes\img.gif), pero en ejecución es necesario referenciar el camino virtual donde se encuentran las mismas - normalmente en 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.

Imágenes (Preferente Diseño) Base path for relative images: válida para toda la KB. Al insertar imagen se ingresa path relativo. Ejemplo: C:\kb /imágenes/img.gif

23
Debido a las diferencias entre los ambientes de diseño y ejecución es que se dispone de una preference a nivel de diseño denominada ‘Base path for relativo ¡magos'. Base path for relative images En esta preference del modelo de diseño, se puede ingresar el pathabsoluto que se va a utilizar mientras se trabaja en diseño (siguiendo con el ejemplo anterior: c:\modelo). Luego en el Web Object, para insertar una imagen se debe seleccionar el botón g de la barra de controles disponibles, Y en e dialogo para ingresar el origen de la imagen se debe ingresar el path relativo (eje: /imágenes/¡mg.g¡f) De esta forma la imagen seleccionada se va a visualizar tanto en diseño como en ejecución. Imágenes – propiedades diseño: En Diseño:

Control Frame: Nombre asignado al control Se usará luego para asignarle propiedades al mismo en tiempo de ejecución. Source: Ubicación de la imagen en el servidor. LowResSource: Se pueden referenciar versiones de alta y baja resolución para las imágenes de manera que la imagen de baja resolución se cargue rápidamente y logre mantener el interés del visitante mientras que se actualiza la imagen de alta resolución cuando esté correctamente cargada. Esto no es HTML standard pero los principales browsers lo reconocen. Height: Indica en pixels el alto de la imagen. Width: Esta propiedad permite establecer ancho del control. Borderwidth: Permite indicar al usuario el ancho en pixels que desea como borde del control.

24

Alternate Text: Algunos browsers no soportan imágenes. Otros soportan, pero el navegante puede tener una conexión lenta por lo que prefieran no ver las imágenes o cargarlas 'a pedido'. Este texto es el que aparecerá si la imagen no apareciera en el browser. TooltipText: Texto que se muestra en tiempo de ejecución sobre cualquier parte del control. Horizontal Space: Cantidad de Pixels de espacio en blanco que agrega a ambos costado (izquierdo y derecho) de la imagen. Vertical Space: Cantidad de Pixels de espacio en blanco que agrega a los bordes superior e inferior de la imagen. Align: Permite seleccionar la alineación de la imagen respecto al texto que la rodea. Los valores posibles son: Left, rigth: para poner la imagen a la izquierda o a la derecha de la pantalla, mientras que el texto cambia al lado contrario. Texttop: Alinea la imagen respecto al elemento mas alto de la línea. Top: Alinea la imagen respecto al texto mas alto de la línea. Middie: Alinea el medio de la imagen respecto a la base de la línea. Absmiddie: Alinea el medio de la imagen respecto al medio del ítem mas alto. Bottom: Alinea la base de la imagen respecto a la base del texto. Absottom: Alinea la base de la imagen con la base del ítem mas alto.

Imágenes – propiedades ejecución: En ejecución: Borderwidth ToolTipText AlternateText Bitmap Enabled Link LinkTarget Visible Las siguientes propiedades pueden asignarse en tiempo de ejecución, el funcionamiento de las mismas es análogo a las propiedades de diseño vistas anteriormente:

25

Borderwidth ToolTipText AlternateText Bitmap: La propiedad se ¡nicializa con el valor de la propiedad Source de diseño. Enabled: La propiedad Enabled de Runtime permite habilitar (Enabled = 1)/ deshabilitar (Enabled = 0) la ejecución del evento asociado a la variable bitmap. Link: Permite asignar un link a la imagen. Si se programa el evento Clic de una imagen se ignora la propiedad Link. LinkTarge: Visible: Permite ocultar o visualizar una imagen. Botones Propiedades:

Control Name: Nombre asignado al control. Se usará luego para asignarle propiedades al mismo en tiempo de ejecución. On Click Event: Evento asociado al botón que se ejecutará al momento de presionarlo. Caption: Texto que describe al botón en el form. Puede modificarse en tiempo de ejecución. Primer Ejemplo:

26
El primer ejemplo consiste en diseñar una página donde el usuario pueda ingresar su nombre de usuario y contraseña para validarse dentro de nuestra aplicación. Para realizarlo se definirá un style con las imágenes que se van a mantener en todas las páginas de nuestra aplicación y luego se definirán las variables para aceptar los datos en pantalla. Web Objects – Funcionamiento: Esquema de trabajo Internet No tiene control sobre operaciones de usuario. Eventos en work/web panels: Start, Refresh, Load, Enter y de usuario. Diferencia: Orden de disparo de los eventos. 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 presione 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. 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. Eventos: Los eventos de los web panels son los mismos que los eventos de 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. Se distingue la primera ejecución de las siguientes del mismo Web Panel. Orden de disparo de eventos (GET): Al ejecutar un Web Panel se disparan los siguientes eventos: Start Refresh Load Es importante aclarar la lógica en Web Panels, ya que la misma tiene pequeñas diferencias con la lógica asociada a un Work Panel. Al llamar a un Web Panel desde el browser se ejecutan los siguientes eventos, en el orden presentado a continuación (GET):

27
•Start •Refresh •Load Una vez finalizado el evento Load, también finalizó la ejecución del Web Panel. Esto permite que se puedan definir links o calls explícitos al propio Web Panel dentro del mismo, sin que esto represente una recursividad en ejecución. Una vez ejecutado el Web Panel al hacer click sobre un link o un botón que contenga un call a sí mismo, la llamada se vuelve a realizar como si fuese la "primera vez" que se llama al mismo. Orden de disparo de eventos (POST): Start Lectura de variables en pantalla Eventos Enter y de usuarios (submit) refresh Load Cuando se presiona un botón o se fuerza la ejecución del evento asociado a una imagen (haciendo click sobre la misma), el orden de disparo de los eventos es diferente al orden de ejecución en la primera llamada al mismo. En este caso se realizan las siguientes operaciones: •Evento Start •Lectura de variables en pantalla •Evento Enter o evento de usuario •Evento Refresh •Evento Load El orden de los eventos aclara el concepto de 'someter' los valores ingresados por el usuario. Web panel – Comandos: Comandos: Load Return Refresh: Equivalente a hacer un call al Web Panel. A continuación se van a documentar los comandos existentes dentro de los Web Panels: Load: es análogo a los Work Panels se utiliza cuando se necesita cargar en forma explícita los registros de un subfíle. Return: Se verá a continuación con más detalle. Refresh: Lo que hace es un call al Web Panel. Tiene el mismo efecto que el F5 del browser.

28

Return: Equivalente a un call No puede ser invocado desde el evento Load o desde una subrutina o procedimiento llamada/o desde este evento. Si no hay llamador queda en el directorio de ejecución. Otras alternativas: botón Close o programar el back. El comando Return vuelve a la página anterior. Incluir el comando return en un Web panel es equivalente a hacer un CALL al Web panel 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 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 el caso del primer web panel, el return no tiene efecto. Observaciones: • En caso que se ejecute en las mencionadas situaciones los resultados son impredecibles. • 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. De todas formas hay otras alternativas para permitir que el usuario vuelva atrás que se verán más adelante. Webobjects – Variables: Variables: Adquieren valor luego de sometido evento. Eje: link definido en evento Start con variable que se encuentra en form. Como se dijo anteriormente, las variables adquieren los valores ingresados por el usuario después de presionar algún botón en un Web Object. 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 click 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 esta en el form, la variable no tendrá valor cuando se disparan los otros eventos (esto es por el "orden" en que ocurren los eventos).

29

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 subfile entonces la variable tiene que estar en pantalla después del subfile. Alineación de Controles:

La única forma existente para alinear controles dentro de un Web Object es la utilización de tablas. El concepto de tabla es muy sencillo, una tabla está compuesta por filas, las cuales a su vez están compuestas por celdas como lo indica la figura. Finalmente dentro de las celdas se pueden insertar controles. Grosor y Separación de una celda:

30
Las propiedades Cell Padding y Cell Spacing de una tabla permiten indicar el tamaño del margen entre celdas y del margen entre el contenido de una celda y el borde de la misma como se puede observar en la diapositiva. Cell Padding: Se debe ingresar en pixels, la distancia deseada entre el contenido y el borde de las celdas. Cell Spacing: Indica en pixeis, el grosor del borde de las celdas. Tablas – Propiedades:

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. Tooltip: Texto que se muestra en ejecución junto al control. Align: Indica la alineación de la tabla respecto a la ventana del browser, los valores posibles son: 1. Left: la tabla queda a la izquierda de la pantalla del navegador. 2. Center: la tabla queda centrada en la pantalla del navegador. 3. Right: la tabla queda a la derecha de la pantalla del navegador. Background Pícture: Path relativo a la imagen que se desea desplegar como fondo de la tabla. Background Color: Permite seleccionar el color que se desea como fondo de la tabla (en formato RGB). Border Wídth: Ancho en pixels del borde de la tabla. Height, Width: Indica el alto y el ancho de la tabla, puede ser un porcentaje (ej.: 20%) o un valor (ej.: 20). Si se ingresa únicamente el valor, se asume el tamaño en pixels. Rules: Esta propiedad permite indicar si se desean visualizar las líneas de la tabla. Los valores posibles son:

31
All: se desean visualizar todas las líneas de la tabla. Columns: se desea visualizar únicamente las líneas que separan columnas. Rows: se desea visualizar únicamente las líneas que separan las filas de las tablas. None: Sólo se visualiza el borde de la tabla. Vertical Align: Indica la alineación vertical del contenido de las celdas de toda la fila de la tabla: 1. Baseline: alinea el contenido a la base del control que se encuentra en la celda. 2. Bottom: alinea el contenido al borde inferior de la celda. 3. Middle: alinea el contenido al centro de la celda (valor por defecto) 4. Top: alinea el contenido al borde superior de la celda. Col span: Permite que la celda se expanda para ocupar más de una columna. Row span: Permite que la celda se expanda para ocupar más de una columna. Text Block: Ingreso de texto en pantalla. Propiedades modificables en ejecución. texto v/s Text Block Texto: estático. Text Block: dinámico. El control Text Block permite ingresar texto en pantalla al que luego se puede modificar sus propiedades en ejecución. La diferencia fundamental entre el texto y el Text Block radica en que el Text Block es dinámico, mientras que el texto es estático. En consecuencia el Text Block se utiliza normalmente para enviar mensajes al usuario como se verá más adelante en un ejemplo y para definir links en tiempo de ejecución. Text Blocks – Propiedades: En diseño:

32

En ejecución: Caption Link

Los text blocks sólo tienen 2 propiedades modificables en diseño: ControlName: permite dar un nombre al control para poder modificar sus propiedades en ejecución. Format: los valores posibles son: •HTML •Text Esta propiedad indica si el contenido del Text Block debe interpretarse como texto o como HTML. Ej.: Si el Text Block contiene el string '<B>Bold</B>' y la propiedad Format tiene el valor'HTML', en ejecución se visualizará 'Bold’, si la propiedad tiene el valor ‘Text' se visualizará '<B>Bold</B>'. En ejecución se puede modificar el Caption, así como definir un link al control. Ejemplo con Text Block:

33
Subfile: Permiten desplegar datos repetitivos. En ejecución es una tabla. Por defecto todas las columnas de un subfilo son Read-Only. For each line o evento clic, modifica valor por defecto y permite trabajar con los valores ingresados. Regla noaccept(). Los subfiles permiten desplegar datos repetitivos, en atributos o variables. Las columnas de los subfiles pueden ser atributos, variables (incluyendo las de tipo bitmap). Cómo desplegar datos en un subfile: Por defecto todo atributo y variable que está dentro de un subfile 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 subfilo: Es posible aceptar datos en las variables de un subfile dependiendo de la programación de los eventos existentes en el objeto: si dentro de un evento del Web Panel se está utilizando el comando For each line o se tiene un evento click asociado a algún control del subfile, todas las variables que están dentro del subfile 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 Oniy de la variable dentro del subfile. Cómo asociar eventos a una línea de un subfile: Es posible asociar un evento a una variable de tipo bitmap o a cualquier control que soporte el evento click que pertenezca al subfile. Subfilo - Propiedades:

34
Control Name: Permite indicar el nombre del control. Siempre se le asigna un nombre por defecto. Auto Resize: En esta opción se dispone de dos valores posibles: 1. True: mantiene el tamaño por defecto del subfile. 2. Falso: habilita la modificación del tamaño del subfile. Width: Esta propiedad permite establecer ancho del control. Se habilita únicamente cuando la propiedad AutoResize tiene el valor ‘False'. Debe indicarse el ancho del control. Por defecto se propone el valor del control insertado, pero puede ser modificado para cambiar el tamaño del mismo. El ancho puede ser especificado en pixels (nnn) o como porcentaje del ancho de la ventana (nnn%). El browser tiene una heurística compleja que se aplica a las tablas y sus celdas para procurar presentar una tabla lo mejor posible. Al fijar esta propiedad se reemplaza esta heurística y en lugar de eso, el esfuerzo se usa en poner el ancho deseado según lo especificado. En las tablas cuando se especifican los valores como porcentajes, son porcentajes respecto a la ventana o a la celda en donde está la misma. Es importante saber que al asignarle un valor a estas propiedades, se le está indicando el valor mínimo deseado, o sea que si dentro de la tabla existe un control más grande, se asignará el tamaño necesario para incluirlo, por lo que el tamaño será mayor que el especificado. •Si se quiere que una tabla ocupe todo el ancho de la ventana, se pone width = 100 en la propiedad de la tabla. Lo mismo si se tiene una tabla adentro de otra, y se quiere que la tabla interior ocupe todo el ancho de la celda de la tabla exterior. •Si se quiere que una columna de una tabla ocupe un tamaño mínimo de 200 pixels se pone width = 200 en una de las celdas de la columna. •Si se tiene una tabla de 2 columnas y se quiere que la primera ocupe el y 20% la segunda con respecto a la tabla, se pone la propiedad width = 80% para una celda de la primera columna. Con esto es suficiente ya que el 20% de la segunda se deduce. LinesColor: Permite indicar el color de la letra de las líneas del subfile. LinesFont: Permite indicar el tipo de letra de las líneas del subfiles. Rows: Esta propiedad permite al usuario indicar la cantidad de registros que va a cargar en el subfile. Aplica únicamente a los subfiles que tienen tabla base. Si el valor de esta propiedad es 0, se despliegan tantas líneas como registros resulten de la consulta asociada. El valor por defecto de esta propiedad es 0 para subfiles y 25 para subfiles Freestyle.

35
Es importante destacar que esta propiedad no optimiza la recorrida que se realizará para desplegar los registros; se recorrerá la tabla base según el orden definido en el objeto. TitleColor: Color de letra del título de la columna. TitleFont: Permite indicar el tipo de letra de los títulos de las columnas del subfile. BackcolorStyle: Haciendo clic sobre +, se expanden las opciones que permiten asignar un estilo al subfile. Los estilos disponibles son: 1. None - el subfile tendrá el diseño del form. 2. Header - permite especificar un color para el fondo de los títulos del subfilo y otro para las líneas del mismo. 3. Report - permite especificar un color para el fondo de los títulos y alternar colores para las líneas pares e impares del subfile. 4. Uniform - permite especificar un único color para el fondo del subfile (tanto el título como las líneas). Table: Este grupo de propiedades es análogo a los de las tablas. En ejecución, se pueden modificar las siguientes propiedades del subfile: •Backstyie •Rows •Visible Ejemplo con subfile:

36
Freestyle: Nuevo tipo de subfilo para Web Panels. Permite “formato libre” de los registrosTabla con registros repetitivos. Propiedades de diseño de tablas. Propiedades de subfile. El subfile Freestyle: Permite al usuario definir el formato de los datos a desplegar de una forma menos estructurada que con el subfile tradicional. El subfile Freestyle es básicamente una tabla a la que se le pueden insertar los atributos y/o variables que se van a mostrar posteriormente en la pantalla. Este nuevo tipo de subfile no posee títulos para las columnas y además permite tener más de un atributo/variable en una misma celda, proporcionando de esta forma mayor libertad de diseño. Cabe destacar que el subfile posee las mismas propiedades mencionadas anteriormente para el subfile 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 subfile Freestyle es análogo al que presentan dentro de un subfile, por lo tanto también quedan de ingreso si existe un For each line o For each line in <subfile> dentro de algún evento. Nuevamente este comportamiento puede modificarse, agregando la regla noaccept o cambiando la propiedad Read Oniy. Subfile Freestyle – Propiedades:

A continuación se documentan las propiedades disponibles para el subfile Freestyie: Control Name: Es el nombre del control, siempre tiene un valor por defecto asignado por GeneXus. Cols: Esta propiedad permite al usuario indicar cuántas columnas va a tener el subfile Freestyie en ejecución. Si se ingresa un valor distinto de 1, el subfile Freestyie va a mostrar los registros en tantas columnas como se haya especificado en la propiedad. Si el valor de esta

37
propiedad es 0, se despliegan tantas columnas como registros resulten de la consulta asociada. El valor por defecto de esta propiedad es 1. Rows: Esta propiedad es análoga a la propiedad de los subfiles. Propiedad Backcolor Styie: Es análoga a la propiedad de los subfiles. Ejemplo con subfile Freestyle:

Web Panels v/s Work panels (Carga del subfile): Siempre se hace loadAll. Se puede programar paginación a pedido.

La razón por la cual no existe paginación a pedido es que una vez que se ejecuta el Web Panel, primero se procesa la consulta sobre la base de datos y luego se arma la página Web para ser

38
visualizada por el usuario. Esta es una limitación del código HTML que no posee controles como los que se utilizan en lenguajes visuales para el subfile. Es decir que un subfile es básicamente una tabla, con títulos en la que se despliegan los datos. Para evitar que se carguen todos los datos, se puede programar la paginación a pedido que se va a documentar a continuación. Paginación a pedido: Asignarle el valor a propiedad Rows para indicar cantidad de registros por página. Métodos: •FirstPage •NextPage •previousPage •LastPage •GotoPage Propiedades: •RecordCount •PageCount El paginado de subfiles aplica a subfiles comunes y free-style cuya propiedad 'Rows' tiene un valor diferente de cero. Los subfiles pueden estar anidados. El paginado aplica a subfiles con tabla base, así como a subfiles sin tabla base. Cada subfile y subfile free-style dispone de métodos, que habilitan la navegación entre registros: • FirstPage: lleva al usuario al primer conjunto de registros devueltos. • NextPage: lleva al usuario al siguiente conjunto de registros. • previousPage: lleva al usuario al conjunto anterior de registros. • LastPage: lleva al usuario al último conjunto de registros. • GotoPage(PageNumber): permite acceder en forma directa a un determinado conjunto de registros. Todos los métodos retornan un valor numérico. Si el valor devuelto es cero, indica que la operación resultó exitosa, en caso contrario dicho valor indica un error o warning. Si el paginado no está habilitado se devuelve 1. El método LastPage aplica únicamente a subfiles con atributos. Cada subfile dispone de las siguientes propiedades que son utilizadas en la paginación: • RecordCount

39
• IpageCount: Esta propiedad devuelve la cantidad de páginas del subfile en base a las propiedades Rows y Columns del mismo. Al igual que la propiedad RecorCount, devuelve -1 si el subfile no tiene tabla base. Paginación a pedido - Consideraciones: Eficiencia asociada a navegación del subfile. RecordCount implica que DBMS barre dos veces la tabla del subfile. Lastpage: un solo comando Load por registro. Si hay más de uno pueden haber resultados inesperados. Se aconseja: Buen filtrado de datos. •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 subfile correspondiente. En otras palabras, si el subfile, 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 utiliza la propiedad Rows y la propiedad RecordCount del subfile. El hecho de utilizar la propiedad RecordCount implica que el DBMS (no el código generado) barre dos veces la tabla base del Subfile (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 Subfile.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. 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 N-1 sin mostrarlos. Dada la implementación, se recomienda tener un buen filtrado de datos (de forma que no existan muchas páginas) y evitar, cuando el costo sea alto, el uso de GotoPage(N) con valores altos de N, así como el uso de LastPage. También se recomienda salvar el valor de la propiedad RecordCount es una variable ya que cada invocación de la propiedad implica un COUNT en la base de datos. Ejemplo – Paginado subfilos: Los métodos de paginado de subfiles pueden ser utilizados en los eventos escritos por el usuario. Por ejemplo: Event Start &Count = MySubfile.RecordCount If &Count > MySubfile.Rows

40
Pagina2.Visible = 1 Endif If &Count > MySubfile.Rows * 2 Pagina3.Visible = 1 Endif Endevent Event Siguiente.Click MySubfile.NextPage() Endevent

41

WEB PANELS Soporte de Múltiples Subfiles: Se soportan múltiple subfiles por objetos. Analogía: procedimiento con For each’s paralelos. El objetivo de soportar múltiples subfiles por objeto es tener la posibilidad de diseñar Web Panels con más de una grilla o Subfile para potenciar el desarrollo de estos objetos, entre otras cosas para resolver en el mismo objeto accesos a diferentes tablas. El uso de varios subfiles 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. Soporte de Múltiples Subfiles: Reglas a nivel de Web Panel y de subfile. Hidden se aconseja incluir atributo en el subfile y cambiar la propiedad visible Order: asociado al subfile. Conditions del Web Panel y del subfile. Quedan asociadas al subfile o en el evento load del mismo. Order: Quedan asociadas al subfile. (Se puede editar dando clic con botón derecho sobre el subfile) Hidden: Los atributos nombrados en esta regla son colocados como "hidden” en cada uno de los subfiles. No se recomienda su uso, en contrapartida se recomienda agregar el atributo al subfile y luego ocultarlo usando la propiedad visible. La razón para promover el uso de los atributos 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 subfilos mientras que los otros sólo están para el subfile 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 subfile y este tiene un orden asignado explícitamente este último es el que se toma en cuenta. Las condiciones se pueden indicar por cada subfile o en forma general para el objeto. Si hay condiciones generales y particulares sobre los mismos atributos, se toma en cuenta a todas.

42

Soporte de Múltiples Subfiles: Eventos: Refresh Subfile.Load Subfile.Refresh Comandos: Load For each line in <Subfile> Los eventos del subfile conservan su comportamiento actual. Los eventos Load y Refresh deben referenciar al subfile usando la siguiente nomenclatura: Event <Subfile Control Name>.< Refresh | Load>


EndEvent Se agrega además un evento Refresh independiente de los subfiles. ¿Cuándo se debe usar el evento Refresh? Algunos ejemplos son: •Cuando se quiere llamar a un programa que calcule algo dependiendo de variables que estén en pantalla y no están asociadas a ningún subfile. •Cuando se quiere acceder a la información de una tabla que no esta asociada a ninguna de las tablas bases de los subfiles. Si el objeto solo tiene un subfile, no es necesario usar la nomenclatura nueva. Los comandos que actúan específicamente sobre el subfile cambian de forma de que, en caso de haber más de un subfile, se pueda determinar a cual subfile se aplica, estos comandos son: For each line: Este comando debe venir con una referencia al subfile de la siguiente forma: For each line IN <Subfile Control Name> Load: Dispara la carga del subfile. Carga de Múltiples Subfiles: No se relacionan cargas Refresh independientes de subfiles. refresh subfile 1 Load subfile 1 refresh subfile 2 Load subfile 2

43
La carga se realiza para cada subfile de forma independiente, es decir, aún si los datos que se muestran en ambos subfiles 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 subfiles es: Evento Evento Evento Evento Evento Refresh refresh del subfile 1 Load subfile 1 refresh del subfile 2 Load subfíle 2

Web Panel – Tabla base: Determinación de tabla base: Atributos en subfile. Atributos en regla hidden y order. ¿Atributos fuera del Subfile? ¿Atributos en eventos fuera de For each? Como los web panels permiten tener más de un subfile, es que hay una tabla base por cada subfile. Los atributos que participan en la determinación de la tabla base de cada subfile son los que: •Están en el subfile •Están referenciados en las reglas Hidden y Order aplicadas al subfile Los atributos de la parte fija no participan en la determinación de la tabla base de ninguno de los subfiles, 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 subfiles. Soporte de Subfile Anidados: Varios niveles de anidación. Anidaciones paralelas. Ej: categoría y Productos Electrodomésticos Heladera

44
TV Muebles de escritorio --También se pueden definir subfiles 'anidados'. Los subfiles anidados consisten de un subfile Freestyle al que se puede insertar dentro de una celda otro subfile estándar u otro Freestyle. Se soportan varios niveles de anidación, así como anidaciones paralelas. La restricción existente es que para poder anidar un subfile a otro, el primero debe ser Freestyle, es decir que únicamente el subfile del último nivel de anidación puede ser un subfile estándar. Esta nueva opción es útil cuando se desea tener un Web Panel que despliegue por ejemplo productos indentados por categoría. Por ejemplo: Electrodomésticos Heladera TV Muebles de escritorio Silla ejecutiva Mesa de directorio --Para poder implementar el ejemplo anterior se debe definir un subfile Freestyie con la categoría y dentro de éste insertar otro subfile con los productos. Subfilos Anidados: Determinación de la tabla base Cada subfile tabla base independiente. Hay que relacionar los subfilos anisados. Ej: SF1 CatID CatDsc SF2 CatID PrdID PrdDsc Cada subfile tiene una tabla base independiente a la del resto de los subfilos del árbol de anidación. Para relacionarlas, se deben incluir en los subfiles 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 subfile, pero sí deben participar en la definición. Siguiendo con el ejemplo anterior, el subfile de Productos deberá tener el código de la categoría para que los relacione. Los subfiles deberán tener:

45

Sf1: Sf2:

CatID CatDsc CatID PrdID PrdDsc Carga de subfilos anidados: Refresh del subfile padre Load del primer registro del subfile padre. Refresh del subfile hijo. Load del subfile hijo. Load del segundo registro del subfile padre. ---

El manejo de eventos es análogo al del resto de los subfiles: se tienen los eventos refresh, load. Cada vez que se ejecuta el comando Load en un subfile con anidaciones, se llama al evento Refresh de cada hijo. Cada subfile 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 subfiles sin tabla base. Ejemplo de Subfilos Anidados: Veamos en nuestro ejemplo: Categorías. Películas.

46

WEB TRANSACTIONS Web Transactions: Nuevo form dentro del objeto Transaction. Se crea un form por defecto. Errorviewer: Control que permite visualizar los mensajes de error. Se crea por defecto y se puede modificar su ubicació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 HTML, 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 HTML de una transacción, se debe abrir la transacción y seleccionar la opción Object/HTML Form del menú GeneXus. Otra forma de editar el HTML form, es seleccionando el tab HTML 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. 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.). Web Transactions – Form HTML: Botones: Confirm: ‘Agregar’ o ‘Actualizar’ realiza operación para llave primaria de nivel donde esté. Check: Validación de datos. No actualiza BD. Hace rollback automático. Delete: Elimina instancia con llave primaria del primer nivel. Movimiento: aplican únicamente al primer nivel. Pueden ser sustituidos por imágenes.

47
Confirm: Al presionar este botón es que se realizan los cambios (inserción o modificación) en la base de datos para la instancia de la llave primaria del primer nivel que esté, en el momento de ser presionado el botón. Inicialmente tendrá el "caption" con el valor "Agregar" o "Actualizar”, dependiendo del modo. Check: Al presionar este botón se validan los datos que se ingresaron (se calculan las fórmulas, se obtienen atributos inferidos, etc.) permitiendo al usuario corroborar visualmente los valores antes de confirmarlos. No actualiza la base de datos (salvo que en las reglas se invoque un programa que sí la actualice y además, realice un COMMIT). El código del botón de Check hace un Rollback automático por si llamó a algún programa que actualizó la base de datos. Delete: Elimina la instancia utilizando el valor de llave primaria del primer nivel que esté en el navegador, en el momento de ser presionado el botón. Movimiento: Los botones de movimiento aplican únicamente al primer nivel y están deshabilitados cuando la Transacción Web recibe instanciado el modo. 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.). Como en las transacciones tradicionales el concepto de Siguiente o Anterior esta relacionado con el orden por llave primaria. El botón Primero y Ultimo, buscan el registro que contiene el valor menor o mayor de llave primaria respectivamente. Nota: El botón siguiente puede, al ser presionado, tener tiempos de respuesta altos si la tabla base tiene un número significativo de registros. Web Transactions – Consideraciones generales: Cambio en el diálogo: Diferencias en validación. Disparo de reglas. Diálogo pantalla completa por performance. Diálogo de reglas: No se valida campo a campo. No se disparan reglas del tipo alter(atribute). Atributos de la extendida se cargan al momento de confirmar los datos. La principal diferencia de las Transacciones Web con las transacciones de las aplicaciones tradicionales es el diálogo que emplea, 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 AS/400 en pantallas de texto. La razón de este diseño es facilitar el uso en ambientes de

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

Web Transactions – Integridad Transaccional: Web Transaction “vive ” entre que se llama y se carga el navegador. Web Trn inicia UTL al comenzar y la cierra (por COMMIT o ROLLBACK) antes de finalizar. No puede formar parte de otra UTL. No aplica propiedad “Commit on exit” 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. Web Transactions – Control de Concurrencia: Diálogo pseudo – convencional. Durante visualización no hay locks sobre base de datos. Control de cambios a nivel de tabla. Se comparan valores de envío con los de recepción (menos LongVarChar). 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.

49
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. Web Transactions – Sin Modo instanciado: Modo Insert. Caption ‘Agregar’ del botón Confirm. Si existe registro existe, mensaje en error viewer. Caption ‘Confirmar’. Modo Update. Ingreso de clave y botón ‘Get’. Caption ‘Actualizar’ del botón Confirm Modo Delete. Ingreso de clave y botón ‘Get’. Botón ‘Eliminar’. 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: Una diferencia respecto a las transacciones tradicionales, es que el botón 'Confirmar’ dice 'Agregar’. Si se quiere ingresar un registro nuevo, se digitan los datos en la pantalla y se presiona el botón Verificar para validarlos. Luego de verificarlo, se presiona el botón 'Agregar’. 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 'Ya existe el registro’. Si no se trabaja con confirmación, se insertarán los datos. Si se trabaja con confirmación, se validarán los datos, se traerán las descripciones, y el botón 'Agregar’ cambiará su contenido para 'Confirmar’. Si se presiona 'Confirmar’ se agregará el registro y se despliega el mensaje 'Los datos han sido agregados’. Si se hace cualquier modificación, el botón pasará a decir 'Agregar’ nuevamente, y se volverá el comienzo del ciclo.

50
Modo Update: Para entrar en modo Update, se deberá poner un valor en la clave y presionar el botón 'Get’. Una vez traídos los datos, el título del botón 'Agregar' pasará a ser 'Actualizar’. Al cargar los datos también se traen las descripciones. Se pueden modificar los datos y presionar el botón 'Actualizar’, 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 'Eliminar’. Los datos se eliminan sin pedir confirmación, y se cargan los datos correspondientes al siguiente registro, quedando en modo 'Actualizar’. Si se borran todos los registros, queda en modo 'Insert’. Web transaction – Modo instanciado: Modo Insert Se deshabilitan botones movimiento. Caption ‘Agregar’ del botón ‘Confirm’. Modo Update. Se deshabilitan botones movimiento. Caption ‘Actualizar’ del botón ‘Confirm’. Modo Delete. Se deshabilitan botones menos ‘Eliminar’, ‘Cerrar’, ‘Ayuda’. Caption ‘Eliminar’ Modo Insert: Las Transacciones Web que se invocan seleccionando el modo Insert, deshabilitan los botones de movimiento entre registros y el botón 'Seleccionar’. Además el título del botón 'Confirmar’ es 'Agregar’. Modo Update: Cuando se invoca una Transacción Web seleccionando el modo Update se deshabilitan los botones de movimiento entre registros y el botón 'Seleccionar’. Además el título del botón 'Confirmar’ es 'Actualizar’. Modo Delete: Cuando se invoca una Transacción Web seleccionando el modo Delete se deshabilitan todos los botones excepto los de 'Eliminar’, 'Cerrar’ y 'Ayuda'. Al botón 'Confirmar' se le pone como título 'Eliminar’. No se pide confirmación para la eliminación (se supone que ya presionó 'Eliminar’ en el 'Trabajar Con'). Web Transactions de más de un nivel: Número de niveles de una Web transaction. Ingreso de líneas.

51
Presionar botón ‘Actualizar’ para agregar líneas. Eliminación de líneas. Marcar check box y presionar ‘Actualizar’. Botón ‘Eliminar’ borra toda la transacción. 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 N niveles de anidamiento. El primer nivel tiene que representarse sin subfile y para los niveles subordinados, se tiene que representar el primero necesariamente como un subfile. •Ingreso de líneas: Si se quieren ingresar más líneas a un subfile que ya tiene líneas, se deben ingresar, y luego presionar el botón de "Actualizar", no de "Agregar. El botón "Agregar" intentará agregar una nueva instancia de toda la transacción. •Eliminación de líneas: Cuando se desea eliminar alguna línea del subfile, se debe marcar la misma con el check box que se encuentra a la izquierda, y presionar el botón de "Actualizar", no de "Eliminar". El botón "Eliminar" eliminara 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 esta en un nivel en particular de la misma. Por eso para eliminar líneas se debe utilizar el botón "Actualizar” porque en realidad se esta actualizando el "documento". Lo mismo para agregar líneas, se debe utilizar el botón "Actualizar" porque se está actualizando el "documento". Regla Prompt: Se generan en forma automática prompts. Se puede utilizar regla prompt tanto en Web transactions como en Web Panels. Reglas: Prompt on. 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. Se puede utilizar la regla prompt al igual que en Transacciones. La regla prompt on permite determinar qué control de la Web Transaction determina la invocación al prompt.

52
Web Panels como Prompts: Condiciones: Uno o más parámetros de tipo output. Algún control con propiedad ReturnOnClick en ‘true’. Los valores devueltos se determinan al armar la página. Existe Función ReturnOnClick() 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 imágenes 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 subfile, por ejemplo). Si uno de los atributos variables, text blocks o imágenes 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. Web Panels – trabajar con … : Varias Implementaciones posibles: Botones/ Imágenes fuera subfile. Botones/ Imágenes con evento clic en cada línea. Variables con link. Los Web Panels 'Trabajar con..." se pueden implementar de varias formas: Botones/imágenes fuera subfile: En este caso se procesan todas las lines con un For each line al presionar el botón. Botones/imágenes con evento click en cada línea: En este caso se dispara el código del evento en la línea donde se presionó el botón o se hizo click. Variables con link: En este caso se agregan click's, ya que se llama a un Web Panel intermedio para realizar alguna operación.

53

WEB OBJECTS Web Components: Objetivo: Disminuir costo desarrollo y mantenimiento simplificación). Web Panels con propiedad de Web Component. Ejemplos: menú, login, etc.

(reutilización

y

Normalmente cuando se desarrolla una aplicación hay muchas partes de la misma que pueden ser reutilizadas en varios objetos. El objetivo de los Web Components es permitir un alto grado de reutilización de estas partes (componentes) disminuyendo así el costo de desarrollo y mantenimiento de las aplicaciones. Los 'Web Components’ son Web Panels que tienen una propiedad que indica que son componentes. Es decir, pueden ser ejecutados por sí solos como cualquier otro Web Panel o pueden formar parte de otro objeto Web Panel o Web Transaction y 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 Web Panels o Web Transactions de una aplicación puede ser definida como Web Component. Algunos ejemplos de ello: 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ú. Web Components – definición: Definición: seteado de preferencia ‘Web Component’ en ‘Yes’. Si Web Panel es main puede ser ejecutado adicionalmente en forma independiente. Se generan dentro de HTML del Web Panel “Contenedor” y se envía HTML completo al navegador. Para definir un Web Panel como Web Component se debe configurar la propiedad 'Web Component' del objeto en 'YES’. Se debe notar que un Web Panel definido como Web Component no pierde ninguna de sus demás facilidades, o sea, si por ejemplo es un Web Panel MAIN, puede ser ejecutado en forma autónoma.

54
Los Web Components se generan dentro del mismo HTML del Web Panel que los contiene. Esto es, 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. Web Components – Uso: Agregado de Web Component: Insert/ Web Component en Webobject “contenedor”. Se da un nombre al control Web Component (Propiedad ControlName). En evento Start se asigna Web Panel a carga en el control: WC.Object = Create(nombre_objeto). La asignación puede ser dinámica. Para insertar un Web Component en un Web Panel o Web Transaction se debe elegir la opción Insert / Web Component, con lo cual se creará un objeto de tipo 'Web Component’ en el mismo. El objeto Web Component tiene una propiedad de diseño que se permite configurar en su diálogo de propiedades: ControlName: Nombre del control Web Component – Propiedades: Object: permite indicar el Web Panel que se va a cargar. Visible: Permite ocultar / visualizar Web Component. A continuación se detallan las propiedades que se pueden modificar a los Web Components en tiempo de ejecución: 1. Object: permite determinar en tiempo de ejecución el Web Panel que se va a desplegar en el lugar del control. 2. Visible: si la propiedad Visible tiene el valor 0, el Web Component desaparece del formulario. Web Components – Orden de los eventos (GET): Start del Web object "contenedor" Refresh del Web Panel "contenedor" Load del Web Panel "contenedor" Start Web Component1 Refresh Web Component1 Load Web Component1 •••.

55
El orden de carga de los Web Components se corresponde con la ubicación de los mismos en el Form y va de izquierda a derecha y de arriba hacia abajo. Cuando se ejecuta un 'GET’ (la primer llamada a un Web Object), el orden de los eventos de un Web Object que contiene un Web Component es el siguiente: •Start del Web object "contenedor" •Refresh del Web Panel "contenedor" Los eventos que se disparan a continuación dependen del orden de los controles en el form (de izquierda a derecha y de arriba abajo). Si el Web Object tiene un subfile ANTES de cualquier Web Component, el orden de los eventos que siguen a los anteriores es el siguiente: •Load del Web Panel "contenedor" •Start Web Component 1 •Refresh Web Component 1 •Load Web Component 1 •••. Si el Web Object tiene un subfile al DESPUÉS de los Web Components, el orden pasa a ser: •Start Web Component 1 •Refresh Web Component 1 •Load Web Component 1 •••. •Load del Web Panel "contenedor" Si el subfile está intercalado, se intercala también el disparo del evento Load. Web Components – Orden de los eventos (POST): Start del Web object "contenedor" Start del Web Component cuyo evento se disparó. Evento de usuario del Web Component. Refresh del Web Component. Load del Web Component. Refresh del Web Object “Contenedor”. Start Web Component (menos en aquel que procesó el evento) Refresh Web Component. Load Web Component. Cuando se ejecuta un 'POST’ (el disparo de un evento de usuario en un Web Object), el orden de los eventos de un Web Object que contiene un Web Component es el siguiente: •Start del Web object "contenedor" •Start del Web Component cuyo evento se disparó

56
•Lectura de variables •Evento de usuario del Web Component •Refresh del Web Component •Load del Web Component El orden de los eventos que siguen se corresponde con el orden descrito en el caso anterior. Web Components en subfile: Se pueden tener dentro de un subfile Freestyle. Por cada línea del subfile se disparan los eventos Start, Refresh y Load del Web Component. Si se dispara un evento de usuario del Web Component, al llegar a la línea se dispara el order correspondiente al POST. Web Componets – Observaciones: Sustitución de eventos desde Web Object “Contenedor”. En diseño tamaño fijo, en ejecución se ejecuta a tamaño real. Web Component puede contener Web Component. Parámetro recibido por Web Component no son opcionales. Propiedades, métodos y variables de Web Component no son accesibles desde “Contenedor”. Se heredan propiedades del Form del “Contenedor”. • En diseño, el tamaño del Web Component permanece fijo, pero en ejecución, en caso de tratarse de un Web Component 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. • En el evento START o REFRESH se deberá asignar un objeto al Web Component mediante la función link. Por ejemplo Comp1.component = link(hmenu,1). • Los parámetros de los Web Components, cuando son utilizados como tales, no son opcionales. Notar que esto es una diferencia con los Web Panels 'comunes' cuyos parámetros sí son opcionales. • Las propiedades, los métodos y las variables de los Web Components no son accesibles por los objetos que los contienen. 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 Web Panel que lo contiene. Por ejemplo si el form de un Web Component tiene color verde, pero el

57
form del Web Panel que lo contiene tiene color blanco, entonces este último predominará sobre el primero. No es así con las propiedades de los demás controles. • Se puede usar el evento click de imágenes en Web Components. Embedded Page: Objetivos: Incluir información externa. Dividir carga en varios sectores web. Control al que se puede asociar un Web Object en cualquier servidor o cualquier URL. 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. 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. En particular, la página u objeto web GeneXus asociado a un control de tipo 'Embedded Page' puede estar en otro servidor. Embedded Page – Definición: Agregado de Embedded Page: Insert/ Embedded Page en Webobject “Contenedor”. Embedded Pages se generan como un “inline frame” (<IFRAME>) en el HTML final. El navegador se encarga de realizar el requerimiento e incluirla en el “inline frame”. 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. 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 trame. Embedded Page – Propiedades: En diseño:

58
Propiedades: El control 'Embedded Page’ tiene las siguientes propiedades: •ControlName: Nombre del control. •BorderStyIe •Scrollbars •Source •TooltipText •Height •Width •Align Embedded Page – Propiedades: En ejecución: BorderStyIe TooltipText Source Visible

Propiedades modificables en ejecución: A continuación se detallan las propiedades modificables en tiempo de ejecución: •BorderStyIe •TooltipText •Source •Visible Embedded Page en subfile: Se puede incluir Embedded page en subfile Freestyle. Si es un Web Panel externo, el orden de los eventos se corresponde con el de un Web Component. Consideraciones finales – diseño: Browsers proveen soporte diferente de HTML. Al diseñar se deben tener en cuenta diferencias. Funciones: BrowserID, BrowserVersion. Al diseñar páginas HTML en general se debe tener en cuenta que los browsers presentan soportes diferentes de código HTML. No todos implementan todas las características posibles, de forma que al encontrarlas, normalmente se ignoran, pero en algunos casos se pueden obtener resultados inesperados.

59
Consejo: probar en todos los browsers mientras se va diseñando la aplicación. Además, se dispone de las funciones BrowserID, BrowserVersion, que permite obtener el browser que estás usando el cliente, de forma de poder condicionar algunos detalles de diseño. Modificar HTML: Mayor potencia. Se modifica el código directamente en la sección ‘Source’. Atención: No se puede modificar código entre tags <OBJECT></OBJECT>. La posibilidad de modificar el código HTML agrega potencia a los Web Objects, ya que permite al usuario realizar llamadas a Javascripts, o simplemente agregar funcionalidad al código HTML existente. Para modificar el código HTML se puede directamente editarlo de la sección 'Source' del formulario y agregarlo como se va a mostrar en el ejemplo que sigue a continuación. Hay que tener en cuenta que no se pueden realizar modificaciones al código que se encuentra entre los tags <OBJECT> </OBJECT>, ya que los mismos son utilizados para identificar los controles que se encuentran en pantalla. En caso de modificar los mismos, el código generado no va a ser correcto y los resultados impredecibles. Ejemplo Modificar código HTML:

En el primer ejemplo se va a modificar el código HTML para que al hacer clic en una imagen se vuelva a la página visualizada anteriormente en el navegador. Para esto se inserta una imagen en el formulario obteniendo la pantalla que se observa en la diapositiva. Al seleccionar la sección Source dentro del formulario, se puede observar el código HTML correspondiente a la imagen insertada en la sección Diseño:

60

<IMG alt="" border = 0 src="\\cualquiera\wwwroot\img\chaplin.gif" srcGX = "chaplin.gif"> Para poder agregar el código HTML para volver hacia atrás, se debe modificar el código generado para la imagen, agregando una opción onclick y asignándole history.back(). De esta forma al ejecutar el Web Object, cuando se hace click sobre la imagen se vuelve a la página visualizada antes de llamar al Web Object. Asignar código HTML a variables/ atributos:

Otra forma posible de agregar código HTML es asignándoselo a una variable que tenga la propiedad ‘Read Only'=True o a al caption de un Text Block. Con este método no se puede modificar el código HTML generado, como en el caso presentado anteriormente, por lo que para realizar la misma operación, se tiene que definir todo el código correspondiente a la imagen como se muestra a continuación: En diseño se define una variable o un Text Block como se ve en la diapositiva. En el evento Start de este Web Panel se debería definir el código HTML correspondiente a la imagen, junto con la opción que permite retroceder en el browser. Event Start &pruhtml= '<IMG alt="" border=0 onclick=history.back() src="chaplin.gif">’ txthtml.caption='<IMG alt="" border=0 onclick=history.back() src="chaplin.gif">’ Endevent

61
Pastear HTML: ¿Se puede pastear código HTML de otras páginas? Limitaciones: <HEAD></HEAD>. ¿Se puede pastear código HTML de otras páginas? La respuesta a esta pregunta es afirmativa, p ero se debe tener cuidado al realizar esta operación, ya que en la copia puede incluirse código que se encuentra dentro de tags que pueden provocar un comportamiento impredecible. SSP: Generación inteligente de páginas estáticas. Web Panel intancia datos recibidos por parámetro. Resultado: página.html (Ej: hpelicul_1.html) Conviven con Web Panels dinámicos. 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 los 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. El nombre de las SSP resulta de la concatenación del nombre de! objeto web panel (8 caracteres) con la lista de parámetros que recibe separados por el carácter '_’ y la extensión HTML. Ventajas y uso de SSP: Ventajas: Mejor performance. Mejor sobrecarga del servidor. Uso: Contenido que varía con periodicidad conocida. Información NO on-line. Porque usar SSP? 1. Se comportan con mejor performance que los dinámicos. 2. Recargan menos al servidor en tiempo de ejecución. En que casos es viable la utilización de SSP? 1. Si tenemos páginas cuyo contenido varía en la base de datos con una periodicidad conocida.

62
Si nuestra aplicación puede soportar mostrar alguna información no on-line sino que se actualice hacia el web con cierta periodicidad. Generación SSP: Preference: ‘Generation Mode’. Dynamic Panels Smart Static panels. A nivel de modelo y a nivel de objeto. Se genera desde línea de comandos o desde otro Web Panel. Existe una nueva preference a nivel del modelo, en la sección Web Information denominada 'Generation Mode’. Las opciones son 'Dynamic Panels' (que es el valor por defecto) y 'Smart Static Panels’. El valor Dynamic Panels significa que el web panel se generará con acceso dinámico a la base de datos. El valor Smart Static Panels significa que el web panel se generara en forma estática (SSP). Existe también la propiedad a nivel de objeto. Los valores posibles son 'Dynamic Panels’,'Smart Static Panels’ y 'Use moders preference valué' (que es el valor por defecto). La generación de SSP se logra a partir de la ejecución del web panel dinámico. Esta ejecución puede hacerse desde la línea de comandos o desde otro objeto GeneXus no web. SSP’s – Parámetros adicionales: Static Static Static Static Static Web Directory Web Dynamic URL Web Overwrite pages Web Links Web Copy Directory

La llamada al web panel puede contener parámetros adicionales que cambian el funcionamiento del programa. Los parámetros soportados son: Static Web Directory: Indica el directorio en donde se generarán las SSP. Si no se especifica se generan en el directorio comente. Java/VB: genexus.staticweb.dir=<dir> C/SQL:/sd: <dir> Static Web Dynamic URL:

63
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 botón, al apretarlo 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 apreta un botón 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.

Java/VB: genexus.staticweb.dynurl==<url> C/SQL: /su: <url> Static Web 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'). Java/VB: Genexus.staticweb.overwrite=<true|false> C/SQL; /so: <true|false> 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 ú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). Static Web Links: Indica que se recorran todos los links del web panel principal. Si no se especifica esta propiedad siempre se recorren (se asume 'true'). Java/VB: genexus.staticweb.links=<true|false> C/SQL:/si : < true|false> Static Web 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'.

64
Si no se especifica esta propiedad, no se copian a ningún lugar Java: genexus.staticweb.copydir=<dir> C/SQL/VB: Parámetro no soportado

C/SQL SSP’s – Uso de los parámetros: C/SQL Se pasan parámetros por línea de comandos después del nombre del programa C/SQL. Ej: • Hmainwp / sd=c: /su = html: // server/mydirectory / so: false / sl = true

C/SOL Para el ……… ……

JAVA SSP’s – Uso de los parámetros: JAVA: Se pasan en la línea de comandos antes de llamar al programa JAVA. La sintaxis depende de la máquina virtual. Si la máquina virtual es SUN o IBM y se tienen gran cantidad de Web Panels a estatizar, se recomienda aumentar la memoria máxima disponible para la aplicación. JAVA: Para el generador Java, los 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. Sun/IBM: java-D pará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.

65

VB – Uso de los parámetros: No se pueden ejecutar SSP’s desde la línea de comandos por lo que se debe referenciar los parámetros desde GX. 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. Para poder ejecutar los SPPs y que los mismos generen los HTMLs correspondientes se deben seguir los siguientes pasos: 1. 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). 2. Ejecutar el objeto que va a establecer los parámetros y llamar al SSP.

3. 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. Generación SSP (a partir de objeto): SSP como parte de un Workflow. Funciones: Setenvproperty. Copystaticfiles. Generación de SSP a partir de otro objeto GeneXus: Es posible llamar a un SSP desde cualquier objeto GeneXus. Al llamar al Web panel se generan las páginas. Esto permite, por ejemplo, poner el mecanismo de generación de los SSP dentro de un workflow. Las 'system properties' que se definen en la línea de comandos, también se pueden poner en la línea de comandos de la aplicación Java. Además, se provee una forma de configurar dichas propiedades desde las aplicaciones GeneXus. Hay dos funciones, la 'setenvproperty' que permite cambiar el valor de una de estas propiedades, por ejemplo: &aux = setenvproperty(‘genexus.staticweb.dir', &D¡r)

66
Y la 'copystaticfiles', que permite disparar la copia de los Web panels generados a otro directorio, por ejemplo: &aux = copystaticfiles() SSP’s generación a pedido: Objetivo: Tener mezcla de página y no requerir la estatización previa. Cuando se realiza una llamada se verifica si existe.html Si existe se llama a html. Si no existe se genera html y luego se redirecciona. Aplica únicamente en Web Objects sin botones o al ingresar por primera vez. La idea es que tengo un sitio que es todo dinámico (los links son siempre a webpanels dinámicos (.exe en CGI, etc) y 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. Esto funciona solo en el caso de que los Web Objects no tengan botones (o mas genéricamente, eventos en el servidor asociados a controles en pantalla, como imagen.click, etc), o cuando se ingresa por primera vez (haciendo un 'GET’ y no un 'POST') a un Web Object con botones(la primera vez va al .html, y cuando se ejecuta un evento, se llama al 'dinámico'). El objetivo de esta característica es poder tener una mezcla de páginas dinámicas y estáticas sin que haya la necesidad de correr un proceso que genere todo el sitio. SSP’s generación a pedido: Preferences: On request SSP server directory: directorio en el servidor donde se generan html. On request SSP client URL: URL vista desde el cliente donde están los html. Existen dos nuevas preferences: On request SSP server directory: tiene el directorio del servidor en donde el webpanel genera los .HTML On request SSP client URL: tiene la URL vista desde el cliente en donde están los html (debe corresponder físicamente al mismo directorio que se puso en la otra preference)

67

WEB PANELS WAP: Páginas para Internet móvil. WAP (Wireless Application Protocol): Protocolo que habilita acceso a Internet desde dispositivos móviles. WML: Lenguaje de tags basado en HTML. Menos potente, más estricto en sintaxis.

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). WAP (Wireless ApUcation 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. WAP: Microbrowser: Interpreta WML y lo despliega en pantalla. Existen emuladores para realizar pruebas. Recomendación: UP Browser. Arquitectura: Similar a la vista anteriormente. Cliente: celular con microbrowser. Servidor: Objetos con lógica. MicroBro wser: 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.

68

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. Wap y Genexus: Propiedad ‘Tag Language’ a nivel de Web Panel. Valores posibles: HTML WML. Para generar Web Panels con contenido WML, se implemento 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.

WAP – Consideraciones diseño: Controles soportados: Edit Textblocks Texto libre Tablas simples Subfile freestyle simple 4 a 8 líneas de tamaño. No se recomienda scroll. Soft button (botón superior izq.) se asocia al evento ENTER. 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.

69
•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 TextbIocks o Texto libre o Tablas simples o Subfile freestyles simples •El softbutton del teléfono (botón que se encuentra en la parte superior izquierda), se asocia al Evento Enter. WAP – Consideraciones diseño: No se soportan: Variables dentro de tablas Ninguna anidación de tablas y/o subfile freestyle Subfiles comunes Campos LongVarchar La letra ñ Tag <BR> Botones

70

WEB OBJECTS MenuBars en Web Panels: Aparece en la parte superior de la ventana del browser. Se utiliza javascript para desplegarla (mb.js y tree.js) Para la implementación de los menu bars, se utilizan dos archivos .JS (mb.js y tree.js) que tienen el código JavaScript necesario para desplegar la menubar. Estos archivos deben estar en el directorio de los webpanels. En los generadores que hay 'transfer’ estos archivos deberán ser transferidos junto con los webpanels. Cuando se asocia una menubar, al ejecutar el webpanel, la menubar aparece en la parte superior del mismo. El aspecto aún no se puede modificar. La única forma de cambiar el aspecto es modificando a mano los .JS. Web Wrapper: Nuevo tipo de dato. Permite capturar contenido de Web Panel y enviarlo por mail. La idea del objeto WebWrapper es encapsular en un tipo de objeto a los objetos Web GeneXus. En particular resuelve al problema de poder enviar el contenido de un Web Panel por mail. 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 dicho lenguaje. Web Wrapper: Propiedades: BaseURL: URL base para llamadas. Object: resultado de la función create(). Métodos: GetResponse: Retorna código HTML que devuelve objeto.

71
Propiedades: BaseURL: 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. Source: Objeto a encapsular en la variable de tipo WebWrapper A la propiedad Source debe asignársele siempre el resultado de la función l¡nk(Objeto, Parámetros). Métodos: GetResponse: Retorna el código HTML que devolvería el objeto Web especificado en la propiedad Source con los parámetros allí indicados. Seguridad: ¿Es segura mi aplicación en Internet? ¿Es segura la comunicación en Internet? ¿Quién puede acceder a mi base de datos? ¿Quién puede acceder a mi aplicación? La respuesta a la pregunta: ¿es segura mi aplicación en Internet? No es sencilla y se puede separar en varios puntos que se detallarán a continuación. Se puede decir que al publicar una aplicación en Internet se tienen 3 niveles distintos de seguridad: • Seguridad a nivel del Web Server •Seguridad a nivel de la Base de Datos •Seguridad a nivel de la aplicación Seguridad a nivel de Web Server: Criptografía. Solución: Servidores seguros.

Tal como lo ha demostrado el crecimiento exponencial de Internet, TCP/IP resuelve muchos problemas de una forma excelente. Sin embargo, TCP/IP no fue diseñado para ofrecer servicios de comunicación seguros. Entonces debemos agregar tecnología adicional para resolver problemas de seguridad.

72
Desde siempre, existe una única tecnología que provee los principios para resolver estos problemas: CRIPTOGRAFÍA. A nivel de servidor Web, existen servidores seguros, los cuales encriptan cualquier documento enviado. Los Web Panels generados por GeneXus pueden ser ejecutados en un servidor seguro. La instalación de un certificado digital para un sitio Web y encriptación de datos son simples. Estas son funciones del software que se utilice como servidor Web. Para activar la encriptación, todo lo que el usuario debe hacer es realizar la solicitud del recurso a través del protocolo https: en lugar de http. Seguridad a nivel de DBMS: Como en cualquier aplicación desarrollada con Genexus. La seguridad a nivel de base de datos en Web paneil no tiene ninguna diferencia con el resto de la aplicación desarrollada con GeneXus. Es decir, los usuarios tendrán la posibilidad de consultar o modificar datos de la misma manera que si se hiciera desde una terminal. Seguridad a Nivel de Aplicación:

La seguridad con respecto a la aplicación depende del tipo de aplicación que estemos desarrollando. La aplicación que desarrollamos puede ser pública, es decir permitir el acceso a todos los usuarios, o se puede restringir el mismo. Por ejemplo, si se tiene una aplicación que tiene

73
información del cliente y el mismo puede modificarse sus datos o debe identificarse para realizar una operación. La dificultad con la que nos enfrentamos es que los parámetros que recibe un Web panel es visible en el browser, por lo que sabiendo el nombre del Web Panel, se podría acceder a los datos de un usuario sin pasar por un Web Panel de validación. Es por esta razón que se aconseja el uso de sesiones cuando se tienen aplicaciones en Internet que requieren un acceso restringido. El uso de sesiones se compone de una transacción que almacena el usuario loggeado, 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 SEGURIDAD, 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á loggeado por más de dicha cantidad de tiempo, se muestra la misma pantalla de error. Cookies: Pequeños archivos que se graban en PC cliente. Uso más común: Identificación de usuarios. Limitaciones de tamaño y cantidad aceptadas. Se puede deshabilitar el uso. Las Cookies son archivos pequeños que se graban desde un Web site en las maquinas 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 mas 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 maquina cliente y se mantiene entre conexiones.

74
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 mas de 20 cookies las ultimas 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 limite es truncada. El usuario puede preferir no grabar la cookie permanentemente (por ej. Si esta 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. Ciclo de vida 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 mas 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 de 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.

75
Implementación seguridad con cookies:

Cookies v/s Prog. Seguridad:

A la hora de decidir la forma en la que se va a implementar la seguridad de una aplicación web, se puede optar entre 2 posibles soluciones: utilizar cookies o programar en forma manual la seguridad. SetCookie: SetCookie: permite grabar cookie &var_num = SetCookie(NombreCookie, Valor, [path],[exp-date],[domain-name],[secure]) SetCookie: Permite grabar una cookie. Devuelve 0 ( cero) si el resultado es correcto, otro valor si hubo algún error. La sintaxis es:

76
&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. NombreCookie (Carácter): Nombre de la cookie Valor (Carácter): Valor a almacenar. Path (Carácter): Camino que indica para que 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 esta en 1 la cookie se trasmite solamente si la conexión es segura (HTTPS). Si está en O se trasmite siempre. GetCookie: GetCookie: Permite leer cookie. &var_char = GetCookie(NombreCookie) GetCookie: Permite leer una cookie, devolviendo un string con el valor. Si no encuentra la cookie (o no la puede leer por estas deshabilitada) devuelve el string vacío. La sintaxis es: &var_char = GetCookie(NombreCookie) NombreCookie - carácter &var_char - carácter Encriptación de URL: Ventajas: Usuarios no conozcan parámetros enviados en la URL. Usuarios no puedan modificar el valor de los parámetros. Los objetos Web (Web Panels, Transacciones 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,

77
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. 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. 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 Encriptación URL – Definición: Preference ‘Encrypt URL parameters’ en grupo ‘Web Information’. Valores posibles: No: no se encriptan parámetros. Sessionkey: se usa una clave diferente para cada sesión. No permite compartir URL’s. Sitekey: clave encriptación común a todo el sitio. 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.

78

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. Encriptación URL – Consideraciones: Sesiones navegador. Misma instancia. Diferentes instancias. Modelo v/s Objeto. Como tener encriptación en algunos objetos y en otros no. 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 pertenecen 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 únicamente 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.

79

REQUERIMIENTOS

C/SQL – Requerimientos: Servidor: Windows Unix Software: Desarrollo: •Compilador C • Rutinas de soporte del Generador (gxcsetup) • Software para la ejecución remota (REXEC) • Cliente DBMS • Embedded SQL - Precompilador C/ SQL para el dbms utilizado. • ODBC - Data Source. Los requerimientos para generar Web panels en C/SQL son los mismos que para cualquier otro objeto generado con C/SQL. Compilador C: permite compilar el código C resultante de la precompilación, para luego generar el ejecutable. GeneXus Support Files: es una serie de bibliotecas provistas por GeneXus que se utilizan durante la compilación de los objetos. REXEC: habilita la ejecución de comandos en forma remota. Se utiliza para realizar la compilación en el servidor desde la máquina de desarrollo. Cliente del DBMS: El generador soporta dos formas de acceso: "ODBC" y "Embedded SQL".Los requerimientos varían dependiendo del método de acceso seleccionado. Embedded SQL: Precompilador C/SQL : transforma las sentencias SQL generadas a código C, depende del DBMS que se esté utilizando. ODBC: Drivers ODBC DataSource

80
C/ SQL – Requerimientos: Producción: Web Server Cliente del DBMS Embedded SQL - Precompilador C/ SQL del DBMS utilizado. ODBC - Drivers ODBC - Data Source - Dll’s de acceso ODBC. Para poner en producción una aplicación de Web Objects generada con C/SQL, se requiere lo siguiente: Servidor Web Cliente del DBMS Si se accede con "Embedded SQL": Precompilador C/SQL del DBMS utilizado. Si se accede con ODBC: Drivers ODBC, Data Source y dll's de acceso ODBC.

JAVA: Servidor: Windows Unix As/ 400 Software: Desarrollo: - Compilador Java (Java Development kit). - Drivers JDBC - Java Server Web Development kit. Producción: - Web Server que soporte servlets ó - Motor de servtets - Drivers JDBC Para poder compilar los Web Panels generados con Java es necesario obtener el Java Server Web Development Kit o posterior (ver en Anexo I dónde obtenerlo). Al instalar este producto, en el subdirectorio lib, se encontrará un fichero llamado servlet.jar, que debe incluirse en el CLASSPATH que se especifica en las opciones de ejecución. Para poder ejecutar los Servlets dentro de un servidor Web es necesario un servidor de web que soporte Servlts, o un motor de Servlets en caso de que el servidor de Web no lo soporte. Existen varios motores de servlets (ver en Anexo I dónde obtenerlos), para prototipar en forma stand alone, se recomienda:

81

• Java Server Web Development Kit que provee un servidor de Servlets que se puede utilizar para prototipar los Web Panels. Visual Basic: Servidor: Windows NT Windows 200 Software: Desarrollo (Cliente) • Visual Basic 6.0 sp3 • InterDev • Web Server (Personal Web Server o Peer Services) Producción: • MDB • Web Panels (*.asp) • DLL • Permisos en dir Winnt\ system32 • Permisos en dir Winnt\ temp. 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 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. Para poder compilar o ejecutar en forma interpretada los Web Panels generados como Web Classes se necesita: • Windows 2000 o Windows NT 4.0 (o superior). • Visual Basic 6.0 SP3 • Web Server Instalado: Internet Information Server 4.0 o superior. También puede ser Peer Web Server. NOTAS: • Los usuarios finales (que ejecutarán los web panels compilados) únicamente requieren el Web Browser para poder ejecutarlos. Visual Basic C/ S: Desarrollo/ Producción: Instalar cliente DBMS en servidor Web. Definir datasource del sistema

82
Setear pref. User y Password. Setear pref.’Show connection dialog’ = No. En el caso de Web Panels generados en Visual Basic Cliente/Servidor es necesario: Tener definido en el servidor, el Data Source para conectarse a la base de datos. Tener en cuenta que este Data Source debe estar disponible para el usuario que ejecuta los Web Panels. Este usuario es el que está definido en el Servidor Web. Tener configurado en el cliente de la Base de Datos (SQL Server, Oracle, etc.) el protocolo de red que se va a usar (TCP/IP, IPX/SPX, etc.). Este cliente debe ser instalado en el Servidor Web, para poder acceder a la Base de Datos.

83

CONFIGURACIÓN

Model properties: Execute (VB)

Visual Basic 5.0 o Visual Basic 6.0 Path: Indica el path del ejecutable VB.EXE de la versión Visual Basic según corresponda. Puede indicarse también el modo de ejecución: Compile & Execute o Execute from interpreter. Esta preference es válida para todo el modelo, ya que sin importar el modo de ejecución elegido, los webpanels deben compilarse primero, y luego se ejecutan. CGI-BIN Path: Directorio CGI-BIN del Servidor de WEB donde estarán los web panels de la aplicación. Este directorio debe tener permisos de ejecución. Debe ser accesible desde la work station via map or share, ya que se necesita realizar transferencia directa. Este directorio debe ser creado previamente por el Administrador del Web y configurado para permitir la ejecución de programas CGI-BIN. (Las opciones de configuración son propias del Web Server). Un buen esquema de trabajo es crear un directorio para cada aplicación debajo del directorio cgi-bin. Start URL: Es un CGI-BIN base, generalmente ubicado en http://www.myorg.com/cgi-bin/mydir/. Cuando se presiona el botón Execute, GeneXus levanta el browser configurado por defecto instalado en el cliente y pone la dirección especificada en esta preference junto con el nombre del Web panel seleccionado.

84
Model properties: Execute (C/ SQL)

Host Name: Corresponde al nombre del servidor o su dirección IP. Script Name: Indica el nombre del script utilizado para compilar los Web Panels. Se asume que este archivo se encuentra en el directorio especificado en Support Files. Program Director/: Esta opción es sólo informativa e indica el valor especificado en la opción "Programs directory". 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. 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 servido 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. O le indica que espere en forma indefinida.

85
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. User Name/Password: es el usuario y la password utilizas para la transferencia. Remember password: se selecciona para guardar la contraseña. Model properties: Execute (JAVA)

Platform: se selecciona el ambiente de ejecución de las aplicaciones Java. AppUcation: se selecciona para ejecutar como aplication. No aplica a Web Panels. Applet: se selecciona para ejecutar como applet. No aplica a Web Panels. Use Default Browser: si se selecciona esta opción, al presionar 'Execute', se utiliza el browser por defecto definido en el PC. Viewer Path: permite indicar el path del browser que se desea utilizar para visualizar los Web Panels. Web Server Root: Es la URL base, generalmente ubicado en http://www.myorg.com/mydir/.

86
Cuando se presiona el botón Execute, GeneXus levanta el browser configurado por defecto instalado en el cliente y pone la dirección especificada en esta preference junto con el nombre del Web panel seleccionado. Compiler Path: Se especifica la ubicación del compilador Java a utilizar. Make Path: Para compilar aplicaciones utilizando el compilador de Microsoft es necesario la utilización de un programa de make. Aquí se selecciona cual programa de make se desea usar. Customize: Aquí se pueden especificar parámetros adicionales que se pueden pasar al compilador. Classpath: Ubicación de las clases JAVA necesarias para la ejecución. Para utilizar Web Panels se debe incluir el path al archivo serviet.jar Preferences: Modelo de diseño: Base Path for relative images. Modelos de prototipo/ producción Wen Information: Generation Mode Focus Control Encrypt URL Parameters Protocol Specification On request SSP server directory On request SSP client URL. Generation Mode: se utiliza para la generación de SSP's. Focus control: se puede indicar si se desea que el foco se realice en forma automática en el primer control del Web Object o no. Encrypt URL Parameters: permite indicar si se va a encriptar la URL o no. Protocol Specification: indica si la conexión es segura o no. C/ SQL Preferences: Web Server Module Protocol. Extension for Web Programs. JAVA Preferences: Servlet Directory SSP Base URL. Static Content Base URL.

87
Static Content Directory As seen from client. Auto compress web pages. En los modelos GeneXus JAVA, existen preferences que aplican exclusivamente a los web panels. Estas preferences se definen a nivel del modelo JAVA y se setean mediante la opción File/Edit Model/Preferences teniendo abierto dicho modelo. Las relacionadas con web panels son: Servlet Directory: Cada servidor de Servlets necesita que los servlets compilados se pongan en un directorio específico. Ese directorio debe indicarse en esta preference, el mismo es relativo al cliente. Es necesario especificar este valor antes de generar, dado que se utiliza para la generación del makefile. Luego de compilar cada Web Panel, se copiará el archivo compilado al directorio especificado. Además de los .class se copiarán los ficheros .cfg, que contienen la información de configuración, por lo que si se modifica algún valor de las preferences es necesario volver a generar y compilar algún Web Panel. Cuando se modifica el valor de alguna preference y se genera un nuevo .CFG, para que tenga efecto es necesario reiniciar el servidor de Servlets. SSP Base URL: Permite especificar el directorio donde los webpanels dinámicos (dynamic webpanels) buscan las Smart Static Panels. Para poder utilizar archivos de imágenes en los Web Panels/ es necesario copiarlos a un directorio que sea visible desde el servidor de Web, y se debe especificar la dirección relativa o absoluta de dicho directorio en esta preference. Esta dirección es vista desde el servidor. En este directorio también se copiarán los archivos generados (de extensión *.js) para los menubars de web panels. Por ejemplo, se puede crear un directorio \Imágenes bajo el directorio raíz del servidor Web y copiar todas las imágenes necesarias a dicho directorio. Si no se indica valor a esta preference, se asume la raíz del servidor Web (directorio "/"). Este directorio contiene además javascripts (archivos *.js) que se generan para los menubars de web panels y los web panels generados como estáticos. Comportamiento para las imágenes: - Se concatena el directorio indicado en la preference a las imágenes fijas (insert picture) y a las imágenes variables (load bitmap) si el path de las mismas NO comienza con una barra.

88
- Si el path de la imagen comienza con / se asume que se esta indicando un path absoluto y la preference no aplica. NOTA: Cambiar el contenido de esta preference no implica regenerar la aplicación, basta con modificar el archivo client.cfg. Static Content Directory seen by Client: En esta preference se debe indicar el mismo directorio referenciado en la preference anterior, pero no como es visto desde el servidor sino como es visto desde la estación cliente desde donde se está desarrollando la aplicación. Se utiliza para copiar los archivos generados por los menús bars de los web panels. Auto compress web pages: Los Web Panels 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. Esta opción puede deshabilitarse con la preference 'Auto compress web pages', dado que es posible que algunos navegadores no reporten correctamente su capacidad para descomprimir las páginas, y no puedan desplegar correctamente las páginas. El valor por defecto es "Yes". VB - Preferences: Generate Web Panels As Web Classes. Main Web Project Name. En los modelos GeneXus Visual Basic, existe una preference que aplica exclusivamente a los web panels. Esta preference se define a nivel del modelo Visual Basic y se setea mediante la opción File/Edit Model/Preferences teniendo abierto dicho modelo. Generate Web Panels As Web Classes: Esta preference que está debajo de la sección 'Web Information', indica si los Web Panels generados con VB se generarán como CGI (valor No de la preference) o como WebClasses (valor Yes de la preference). El valor por defecto es Yes.