Utilizar el modo contextual

versión 2003 (Modificado)

El servidor Web de 4D puede funcionar en dos modos diferentes: modo no contextual (modo estándar) y modo contextual. Esta sección describe dos modos y detalla las particularidades del modo contextual.

Advertencia: el modo contextual puede utilizarse con 4D en modo local y 4D Server. El servidor Web de 4D en modo remoto no soporta este modo.

Nota: La sección Su primera vez con el servidor Web da un ejemplo completo de la publicación de una base en modo contextual.

Modo contextual y no contextual ______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

El servidor Web de 4D utiliza por defecto el modo no contextual (modo desconectado). En este modo, la operación del servidor Web 4D es comparable a la de los servidores Web estándar: cuando reciba una solicitud HTTP de un navegador (URL, formulario enviado, etc.), el servidor procesa la petición, luego devuelve una respuesta (por ejemplo, el envío de una página Web). Ninguna conexión específica se mantiene posteriormente entre el servidor y el navegador.

En modo no contextual, el servidor Web puede enviar páginas estáticas o páginas semidinámicas. Las páginas semidinámicas permiten acceder a los datos de la base o a efectuar todo tipo de proceso utilizando las etiquetas 4D especiales, evaluadas en el momento de envío de la página. Las páginas semidinámicas permiten crear, administrar y enviar páginas Web cuyo contenido se origina en su totalidad o parcialmente de un proceso llevado a cabo por 4D. El modo no contextual permite generalmente responder a la mayoría de las necesidades de desarrollo de sitios Web.

En modo contextual, la conexión de un navegador Web provoca la creación de un contexto en el cual se colocarán la selección actual, sus variables, etc. De manera que cada navegador se considera como un cliente 4D conectándose a la base en modo Aplicación. El contexto es administrado por un proceso de conexión Web específico.

Este modo permite la publicación instantánea de una base 4D en la Web, sin que sea necesario crear páginas Web: 4D administra y envía al navegador las páginas dinámicas, originadas de la conversión automática en HTML de las barras de menús y de los formularios de su base. También es posible insertar código HTML o Javascript en los formularios 4D con el fin de añadir funciones a las páginas mostradas en la Web.

Además, en este modo 4D maneja automáticamente los accesos simultáneos a los datos: cuando un navegador o equipo cliente 4D carga un registro, 4D lo bloquea para los otros usuarios de manera transparente, bien sean navegadores u otros equipos 4D Client. Además, 4D le permite efectuar la entrada de datos durante una transacción con un navegador Web, como con 4D. Este sistema permite al servidor Web 4D controlar perfectamente las acciones de los navegadores y garantizar la integridad de los datos.

En contrapartida de esta facilidad de publicación, el modo contextual incluye varias restricciones:

- Los navegadores Web permiten "navegar" de una página a otra, de un sitio a otro, etc. Con una base de datos en cliente/servidor, esta navegación debe ser controlada con el fin de respetar la lógica de las transacciones de la base. Cada entrada efectuada por un usuario en un registro debe ser validada o cancelada para no permanecer en un estado incierto. El motor del servidor Web 4D contiene mecanismos automáticos de gestión de sesiones y contextos de la base. Estos mecanismos evitan el uso de ciertas funciones estándar de los navegadores (Recargar, Retroceder una página, etc., ver el siguiente párrafo).

- El proceso de conexión encargado de mantener el contexto permanece activo hasta que se alcance el periodo de inactividad (timeout) del navegador especificado en las Preferencias de la base. Si por ejemplo, el navegador ha salido del sitio entre tanto, el contexto entonces es "desperdiciado".

Estas restricciones significan que el modo contextual está destinado para uso en Intranet o uso dentro de un marco de aplicaciones de Internet específicas.

El principio de funcionamiento del servidor Web 4D se resume en el siguiente esquema:

La selección del modo de funcionamiento del servidor Web de 4D se efectúa de esta forma:

• Al iniciar el servidor, utilizando la opción Modo de inicio de las Preferencias de la base,

• Durante la utilización del servidor Web, en función de los URLs enviados o los comandos ejecutados.

De hecho, ciertos URLs y ciertos comandos 4D pueden cambiar el modo. El principio es que el modo actual permanece en uso siempre que ningún URL o comando 4D provoque un cambio de modo.

Por defecto, el servidor Web inicia en modo no contextual. Puede iniciar el servidor Web directamente en modo contextual. Esto significa que cuando un usuario se conecta a la base, se genera automáticamente un contexto.

Para definir el modo contextual al iniciar, seleccione la opción Modo contextual (contexto permanente) en la página Configuración en el tema Web de las Preferencias de la base:

Durante la operación de la base, usted puede cambiar el modo llamando los siguientes elementos:

• Pasar a modo no contextual:

- SEND HTML BLOB pasando True en el parámetro opcional noContext

- SEND HTML TEXT pasando True en el parámetro opcional noContext

- SEND HTTP REDIRECT

- URL que comience por /4DACTION

• Pasar a modo contextual:

- URL que comience por /4DMETHOD/MiMetodo.

Cuando el URL /4DMETHOD/MiMetodo se envía, el servidor Web 4D crea un nuevo contexto y efectúa las siguientes operaciones:

- El Método de base On Web Authentication se ejecuta (si existe),

- El Método de base On Web Connection se ejecuta (si existe) — en este caso particular, $1 es igual a /4DMETHOD/MiMetodo en lugar de / (barra oblicua),

- Finalmente, el método solicitado se ejecuta en el nuevo contexto creado.

Dependiendo de las acciones que efectúen, algunos procesos Web utilizan contextos Web, otros no.

Puede conocer el número de contextos generados utilizando el comando PROCESS PROPERTIES: para todo proceso Web, este comando indica, en el parámetro origen, si utiliza un contexto (-11, Proceso Web con contexto) o no (-3, Proceso Web sin contexto).

El número de proceso de la conexión Web se llama número de contexto, el cual se genera aleatoriamente e identifica cada conexión Web. El número de contexto es administrado por 4D y por el navegador durante toda la conexión Web. En este ejemplo, el número de contexto es 1066993139. En la ventana del navegador Web, puede ver este número en el URL mostrado en el área de destino del navegador:

Los URLs son administrados automáticamente por 4D durante toda la sesión Web en modo contextual. Cada vez que se recibe una petición HTTP vía TCP/IP, 4D extrae el número de contexto del URL, y en consecuencia puede redireccionar la petición al proceso de conexión Web apropiado.

Los números de contexto le permiten a 4D:

• Administrar las sesiones Web y las de la bases de datos.

• Administrar de manera transparente varias conexiones Web simultáneas.

• Evitar futuras conexiones indeseables cuando se utilizan marcadores de favoritos, porque se genera un número de contexto diferente para cada conexión.

En la ventana anterior, puede ver que el número de contexto está seguido por un punto y un segundo número, llamado número de subcontexto. 4D incrementa automáticamente este número cada vez que se envía una nueva página HTML al navegador en modo contextual. El número de subcontexto es esencial para la gestión de la sesión de la base.

Generalmente, un navegador Web dispone de controles de navegación como los botones de tipo "Retroceder una página" y "Avanzar una página", las ventanas de historial, etc. Estos controles son útiles cuando navega por documentos, noticias, listas, etc. Son menos eficaces cuando efectúa una transacción a partir de una base.

Por ejemplo, si un usuario añade un registro a una tabla, usted debe saber si la entrada de datos ha sido validada, es decir, si el usuario Web ha hecho clic en el botón Aceptar o Cancelar del formulario 4D. Si, en este punto, el usuario Web llama otras páginas, la entrada de datos queda en un estado incierto. Para evitar esto, 4D utiliza el número de subcontexto con el fin de sincronizar la sesión Web del lado del navegador con la sesión de la base del lado 4D.

Cada vez que un formulario se envía al navegador o que una petición HTTP es enviada a 4D por el navegador, si se detecta una desincronización de las sesiones de la Web y de la base, 4D envía el mensaje "Al utilizar los controles de navegación del navegador, no validó los datos de un formulario. 4D volverá al formulario de manera que pueda validarlo o cancelarlo." 4D regresa entonces a la página Web de entrada de datos utilizando el número de subcontexto.

Esta sincronización también es esencial para el proceso de conexión Web. La ejecución de un comando como por ejemplo, ADD RECORD ([...]) debe acabarse correctamente para que pueda continuar la ejecución de su código 4D.

La sincronización es selectiva. Si la página Web mostrada en el navegador es un formulario 4D (ADD RECORD, DISPLAY SELECTION, DIALOG, etc.), la sincronización ocurrirá eventualmente.

Si la página Web actual es una página HTML estática accedida por un enlace en otra página Web (se envía utilizando el comando SEND HTML FILE), puede navegar libremente entre las páginas.

Consideremos las siguientes líneas de código 4D:

   ADD RECORD ([Clientes])
   SEND HTML FILE ("Page.HTM")
   DISPLAY SELECTION ([Productos])

El siguiente esquema describe que pasa en 4D y en el navegador Web durante la ejecución del código.

• Las líneas rojas señalan las diferentes trasmisiones del formulario 4D.

• Las líneas azules señalan la transferencia entre las páginas HTML basadas en 4D y las que no.

• Las líneas verdes indican las páginas HTML que nos están basadas en 4D.

Descripción de los pasos

(1) Se llama el comando ADD RECORD. 4D traduce el formulario de entrada actual de la tabla en una págian HTML y lo envía al navegador Web. Si el formulario contiene varias páginas, los botones de navegación estándar de 4D le permitirán navegar entre las páginas del formulario. La navegación es implementada y realizada por 4D de manera transparente (vía el envío del formulario Web).

(2) Durante la entrada de datos (por lo tanto dentro de la llamada a ADD RECORD), el usuario Web hace clic en un botón y el método de objeto del botón llama a SEND HTML FILE.

(3) Dentro de la llamada a SEND HTML FILE, si la página HTML contiene enlaces, el usuario puede navegar entre las diferentes páginas. Finalmente, cuando se ejecuta la instrucción SEND HTML FILE(""), se sale del modo HTML.

(4) La ejecución del método de objeto del botón en el que el usuario hace clic y la entrada de datos iniciada por ADD RECORD continúan. Note que los pasos (2) y (3) pueden repetirse varias veces dentro de la entrada de datos.

(5) Finalmente, la entrada de datos se valida o se cancela, y el proceso de conexión Web se ejecuta.

(6) La siguiente llamada es a SEND HTML FILE.

(7) Este paso es análogo al paso 3. Si la página HTML incluye enlaces, es posible navegar entre las páginas. Cuando finalmente se llama al comando SEND HTML FILE(""), el modo HTML termina.

(8) El proceso de conexión Web se ejecuta.

(9) Se llama al comando DISPLAY SELECTION. 4D traduce el formulario de salida actual de la tabla en una página HTML y la envía al navegador Web. Durante DISPLAY SELECTION, 4D permite navegar de manera transparente entre la página de selección y la visualización de registros individuales. 4D también utiliza MODIFY SELECTION para administrar la entrada de datos y el bloqueo de los registros, por intermedio de los formularios Web.

(10) Durante la navegación por la selección, el usuario hace clic en un botón en el área de pie de página del formulario. El método de objeto del botó llama al comando SEND HTML FILE.

(11) Este paso es análogo a los pasos 7 y 3. Si la página HTML incluye enlaces, es posible navegar por varias páginas. Finalmente, cuando se llama al comando SEND HTML FILE(""), el modo HTML termina.

(12) La ejecución del método de objeto del botón en el cual el usuario hace clic y la visualización de la selección iniciada por DISPLAY SELECTION continúan. Note que los pasos (10) y (11) pueden repetirse varias veces durante la navegación en la selección.

(13) Finalmente, la visualización de la selección termina y el proceso de conexión Web se ejecuta.

Y así sucesivamente...

La navegación Web libre (cuando por ejemplo hace clic en los botones Anterior o Siguiente) es posible dentro de toda llamada a SEND HTML FILE (las áreas verdes en el esquema anterior). Por otra parte, toda página HTML basada en 4D (entrada de datos, visualización de la selección... incluyendo las cajas de diálogo estándar tales como las mostradas por los comandos CONFIRM o Request) escapa de todos los controles estándar del navegador, 4D sincronizará las sesiones Web y las sesiones de la base volviendo a la página Web cuyo número de subcontexto corresponde al del comando 4D que está siendo ejecutado en el proceso de conexión Web.

Desde el punto de vista del usuario, el usuario maneja la sesión Web por medio de sus acciones en el navegador.

Desde el punto de vista de la programación, el proceso de conexión Web maneja la sesión Web, y no al contrario. El navegador Web muestra las páginas enviadas por el proceso de conexión Web que:

• ejecuta el código 4D o

• espera el envío de la página Web actual por parte del navegador.

Desde el punto de vista del Diseño, el proceso de conexión Web debe considerarse como un proceso 4D cuyo dominio de ejecución es 4D o 4D Server, pero cuya interfaz de usuario está situada en el navegador Web remoto.

En consecuencia, siempre tenga en cuanta la dualidad del proceso de conexión Web cuando desarrolla aplicaciones para WEb en modo contextual. Por ejemplo:

• Durante la entrada de todo tipo de datos, la barra de menús principal es la del navegador, no la de 4D. En un formulario, no cuente con la barra de menús de 4D; está en el equipo servidor Web, no en el equipo navegador Web,

• Cuando diseña formularios para utilizar en el navegador Web, recuerde que las funcionalidades del formulario 4D están limitadas a las del HTML (algunas veces con posibilidades adicionales asociadas a 4D). No es posible emplear todas las funcionalidades de los formularios de 4D (por ejemplo, todos los tipos de objetos o todos los eventos de formularios). Para mayor información sobre este punto, consulte el párrafo "Conversión HTML automática".

• En cuando a la comunicación interproceso, el comando CALL PROCESS no tiene efecto cuando se aplica a un proceso de conexión Web, porque el formulario activo es mostrado en el navegador Web. En cambio, un proceso de conexión Web puede ejecutar CALL PROCESS con destino a otro proceso 4D.

Además, la comunicación interproceso puede establecerse indiferentemente en ambos sentidos, a través de los comandos GET PROCESS VARIABLE y SET PROCESS VARIABLE, que no requieren una interfaz de usuario para el proceso.

Como se explicó anteriormente, un proceso de conexión Web en modo contextual ejecuta código 4D o espera la respuesta de la página Web mostrada actualmente en el navegador. En el último caso, el proceso de conexión Web esperará el Tiempo límite para los procesos Web inactivos, definido en la página Avanzado (tema Web) de la ventana de Preferencias o definido por programación utilizando el comando SET WEB TIMEOUT.

El alcance de este parámetro es la sesión de la base. Todos los procesos de conexión Web contextuales están sujetos a ese valor; son afectado inmediatamente si se cambia el parámetro. El valor por defecto es de 5 minutos.

Nota: El comando SET WEB TIMEOUT permite especificar un valor de timeout por proceso Web.

Puede aumentar o reducir este valor según le convenga. Por ejemplo, puede aumentar el timeout si su aplicación permite a los usuarios Web navegar en otros sitios vía los enlaces HTML en las páginas de su base. Al aumentar el timeout, permite a los usuarios navegar por mayor tiempo en otros sitios Web sin cerrar las conexiones a su base.

Advertencia: No es posible detener por programación el proceso de conexión Web. Si especifica un timeout largo, el proceso esperará, incluso si el usuario Web se desconecta de la base después de un cierto tiempo. Si especifica Ninguno, los procesos de conexión Web sólo se detendrán cuando salga de la base. Sin embargo, un proceso de conexión Web se aborda automáticamente tan pronto como el servidor Web pasa a modo no contextual.

Tip: A diferencia de los procesos del servidor Web, los procesos de conexión Web pueden abortarse utilizando el comando Abort (disponible en el Explorador de ejecución de 4D cuando se muestra la página Proceso).

Este párrafo especifica los elementos, objetos y mecanismos manejados automáticamente durante la conversión de la base en HTML por 4D en modo contextual.

• Cada barra de menús se traduce en una página HTML. Cada menú aparece como texto únicamente y los comandos de menú asociados a los métodos 4D aparecen como enlaces a estos métodos 4D. Los comandos de menú que está asociados únicamente a las acciones automáticas aparecen como de texto únicamente.

• Hacer clic en un comando de menú en el navegador inicia la ejecución del método 4D asociado en el proceso de conexión Web.

Nota: Cuando la propiedad "Iniciar un nuevo proceso" está asociada a un comando de menú, el método asociado es ejecutado por el servidor Web 4D en un nuevo proceso de conexión Web utilizando el URL 4DMETHOD. En este caso, el método del menú debe disponer del atributo Disponible vía 4DACTION, 4DMETHOD y 4DSCRIPT (no seleccionado por defecto para las bases nuevas). PAra mayor información, consulte la sección Connection Security.

• La imagen asociada a una barra de menús se ubica debajo de los menús en el navegador.

• 4D conserva al máximo la posición inicial de cada objeto del formulario. Note sin embargo que el HTML es una aplicación orientada al procesamiento de texto; el posicionamiento relativo de los objetos puede ser ligeramente diferente sobre el navegador.

• Los formularios multipáginas son soportados de manera transparente, incluyendo la página cero y los formularios heredados.

• Las acciones automáticas, cuando es apropiado, son soportadas de manera transparente.

• Los eventos de formulario (On Load, On Unload, On Clicked y On Timer) son soportados. Los otros eventos no son soportados.

• Las etiquetas de encabezado, cuerpo, ruptura y pie de página se tiene en cuenta durante las llamadas a DISPLAY SELECTION y MODIFY SELECTION. El encabezado del formulario se muestra una vez al inicio de la página HTML, el área de detalle se repite tantas veces como sea necesario, y las variables (tales como los botones) ubicadas en el área de pie de página al final de la página HTML, justo bajo los enlaces automáticos de navegación en la selección.

• Los mensajes asociados a los botones mostrados como imágenes en el editor de formularios aparecen en el navegador — si el navegador lo permite.

• Una imagen replicada (visualización "Mosaico") insertada en las coordenadas (0,0,x,x) en el editor de formularios de 4D se envía como imagen de fondo al navegador. Por favor tenga en cuenta que se deben evitar las imágenes oscuras.

Nota: el servidor Web 4D utiliza los CSS1 para producir páginas HTML con una apariencia muy similar a la de los formularios 4D. CSS1 (Cascading Style Sheet 1) especificaciones definidas por el consorcio W3C (World Wide Web Consortium). Estas hojas de estilo definen algunas características relacionadas con la apariencia del documento: fuente, tamaño, color, título, cuerpo, espacio, etc. Los documentos CSS se envían con el tipo MIME "text/css". En modo contextual y en modo no contextual, estos documentos no son procesados por 4D.

Por razones de compatibilidad, puede elegir, con la ayuda del comando SET DATABASE PARAMETER el modo de conversión Web a utilizar para los formularios.

Cuando un formulario 4D se convierte en página HTML, los campos se traducen de esta forma:

(*) o texto únicamente si no editable

(**) si el valor de tipo texto está compuesto por varias líneas

(***) Si el valor de tipo texto no está compuesto de sólo una línea o está vacío

Nota: Las variables editables se comportan como campos del mismo tipo.

Cuando un formulario 4D se convierte en página HTML, los objetos de formulario se traducen de esta manera:

Los siguientes objetos no son soportados por HTML y por lo tanto se ignoran:

Lista jerárquica, Menú desplegable jerárquico, Subformulario, Botón de opción de imagen, Termómetro, Regla, Dial, Menú imagen, Casilla de selección 3D, Botón de opción 3D, Separador.

Notas

1. Las líneas no horizontales no son soportadas en HTML; por lo tanto se ignoran.

2. Los botones no visibles son objetos del tipo Botón invisible, Botón inverso, Botón 3D, y Botón rejilla. Si una imagen estática no está traslapada por un botón invisible, la imagen se traduce como una imagen estática. Si está traslapada por al menos por un botón invisible, se traduce como una imagen interactiva administrada por el servidor (Server-Side Image Map).

En el navegador Web, la imagen se trata como un Server-Side Image Map. Del lado de 4D, cuando se recibe el formulario, 4D recalcula la posición del clic para generar un evento On Clicked para el botón correspondiente, como si el usuario hiciera clic realmente en el botón. La administración de botones invisibles es por lo tanto bastante simple, siempre que traslapen con imágenes estáticas. Usted controla estos botones en el método de formulario o en sus métodos de objeto, como lo haría para la interfaz 4D estándar. Esta también es una manera simple de administrar la interactividad de las imágenes (Web Image Mapping). Si un botón invisible no traspasa ninguna imagen estática, se ignora en el momento de la conversión.

3. La agrupación de los botones de opción se mantiene durante la conversión.

4. Las áreas de desplazamiento agrupadas no son soportadas en HTML. 4D las traduce como áreas de desplazamiento independientes ubicadas en la misma línea.

5. Las pestañas (de tipo array o creadas utilizando los valores por defecto definidos en las Propiedades del objeto) se convierten en listas de URL.

Si los elementos del array son cadenas vacías, 4D muestra 1, 2, 3... en el navegador.

6. Las áreas de plug-in son publicables en la Web, convirtiéndolas previamente en HTML, en Imagen o en Image Map. Esta última solución permite administrar los clics dentro del área del plug-in (por ejemplo, el plug-in integrado 4D Chart es publicado en un Image Map y el área 4D_Pack _AP External clock se publica como una Imagen). La manera en que un área de plug-in, incluida en un formulario 4D, se publique en la Web depende de las especificaciones del editor del plug-in.

• El mecanismo UserSet no está soportado

• Un mecanismo de selección automática de páginas es suministrado por 4D. Para mayor información, consulte la descripción del comando SET WEB DISPLAY LIMITS.

Durante el desarrollo de una base 4D para la Web, usted podría preguntarse que pasa cuando se llama un comando. ¿El comando tomará efecto en el equipo del servidor Web o en el del navegador Web? El proceso de conexión Web se ejecuta en el equipo del servidor Web, pero la interfaz de usuario se muestra a distancia en el navegador Web conectado. Por lo tanto, para el desarrollo de una base Web, los comandos 4D pueden ser clasificados de la siguiente manera:

Los comandos que no están afectados por la ejecución de un proceso de conexión Web

Un comando tal como CREATE RECORD funciona dentro del proceso actual; en este caso, crea un registro desde el proceso de conexión Web. El mismo principio aplica a los comandos tales como Screen width, que devuelve el ancho de la pantalla en el equipo servidor Web (el equipo en el cual se ejecuta el proceso).

Los comandos que incluyen las funcionalidades integradas adicionales para el soporte transparente de la Web

Los comandos a utilizar con precaución

Los siguientes comandos se ejecutan localmente en el equipo del Servidor Web.

Por ejemplo, puede invocar la impresión de una selección desde del navegador Web. Sin embargo, la impresión será efectuada en el equipo servidor Web.

Adicionalmente, cuando se llama un componente de interfaz, aparece en el equipo del servidor Web, por ejemplo Open document("") vs Open Document("Este documento"). Debe evitar este tipo de llamadas, porque el navegador Web esperará una respuesta hasta que la caja se cierre en el equipo del servidor Web. Por otra parte, está bien llamar estar rutinas cuando ninguna caja de diálogo está involucrada.

Los comandos no soportados por los procesos de conexión Web

Encapsulación de HTML

Puede personalizar el contenido de los formularios 4D convertidos en HTML encapsulando el código HTML (o Javascript) en el formulario. El formulario resultante, del lado del navegador Web, es una combinación de HTML y objetos 4D.

Un objeto de texto estático de formulario 4D contiene, por ejemplo, la cadena "{page.HTM}", inserta el documento HTML "page.HTM" en el formulario 4D donde está ubicado el objeto de texto.

Usted inserta un documento en su totalidad (de hecho, todo lo que está entre las etiquetas <BODY> y </BODY>). Puede utilizar un documento HTML existente, o utilizar el lenguaje para crear un documento que guarde en el disco y al cual referirse posteriormente.

Nota: En algunos casos, la conversión HTML de formularios 4D creados en versión 6.0.x contiene una referencia a un documento HTML ({mipage.htm}) no siempre da el resultado esperado con 4D versión 6.7 y superiores. En este caso, es posible modificar el modo de conversión de los formularios con la ayuda del comando SET DATABASE PARAMETER.

Toda variable de texto 4D puede encapsular código HTML en un formulario 4D, si su primer carácter tiene el código 1 (por ejemplo, vtHTML:=Character(1)+"...HTML code..."). Puede construir el código HTML en memoria.

En modo contextual, para asegurar el mantenimiento del contexto de la base y el número de identificación del subcontexto, 4D recalcula automáticamente las referencias de archivos y de los URLs. Por ejemplo, todas las referencias IMG y HREF de los archivos locales son recalculadas.

Si inserta su propio código HTML en un formulario 4D utilizando una variable de texto, debe utilizar la sintaxis descrita a continuación.

Los archivos locales GIF son recalculados en "/4DBin/_/GIF_file_pathname", donde GIF_file_pathname es el nombre completo de la ruta completa en HTML a un archivo GIF relativa a la raíz del volumen donde está el archivo.

El siguiente método 4D devuelve las referencias recalculadas para el nombre de la ruta de acceso recibida como parámetro:

      ` Método de proyecto WWW Local GIF URL
      ` WWW Local GIF URL ( Texto )
      ` WWW Local GIF URL ( Ruta de acceso nativa) -> URL al archivo GIF local
   C_TEXT($0;$1)
   $0:="/4Bin/_/"+HTML Pathname ($1)

Nota: Para conocer detalles sobre el método HTML Pathname, consulte los ejemplos del comando Mac to ISO.

Luego, cuando inserte el código HTML en un formulario 4D utilizando una variable de texto, puede escribir:

   vtHTML:=Char(1)+"<P><IMG SRC="+Char(34)+WWW Local GIF URL("F:\ThisImage.HTM")+Char(34)
                                                +" ALIGN=MIDDLE></P>"+Char(13)

Este método insertará el documento GIF en el formulario 4D en la ubicación de la variable 4D

vtHTML.

Importante: Debe escribir este tipo de código únicamente si quiere insertar el código HTML en un formulario 4D. Si envía simplemente una página HTML utilizando SEND HTML FILE o ADD RECORD, recuerde que 4D efectúa automáticamente la traducción y el recalcula el HTML.

El recalculo no cambia los enlaces que tienen los siguientes protocolos:

• http:

• ftp:

• mailto:

• news:

• gopher:

• javascript:

• nntp:

• wais:

• prospero:

• telnet:

Método de base On Web Authentication, Método de base On Web Connection, Seguridad de las conexiones, SET DATABASE PARAMETER.