Creación de formularios HTML

Cuando un diseño de formulario contiene subformularios ampliables, es difícil saber con exactitud cuántas páginas se representarán en el formulario resultante en tiempo de ejecución. La configuración del tamaño de página se utiliza para paginar formularios PDF, pero se ignora al representar un formulario HTML porque las páginas HTML no tienen límite de longitud.

Para implementar el concepto de un formulario HTML de varias páginas, puede incluir un subformulario de nivel de página en el diseño de formulario. Necesitará uno de estos subformularios en cada página que desee procesar del formulario. En el caso de los formularios que contengan elementos flexibles, todos los subformularios de posición variable se deben anidar en uno de los subformularios de nivel de página. Después, una vez representado el formulario, todo el contenido del mismo subformulario de nivel de página se mostrará en la misma página HTML.

Por ejemplo, considere el diseño del formulario de la siguiente ilustración. El diseño de formulario incluye tres subformularios de nivel de página: Subform_Page0, Subform_Page1 y Subform_LastPage. Si Forms tuviera que representar un formulario HTML basado en este diseño de formulario, automáticamente se crearía una página HTML con cada subformulario de nivel de página.

A.

Subformulario_Página0 define una posición fija para el contenido y está configurado para mostrar los objetos una vez en la primera página del formulario usando la presentación de la página de formato Página1.

B.

Subformulario_Página1 contiene un subformulario con posición variable. Subformulario_ampliable puede repetir la representación de los objetos tantas veces como sea necesario de acuerdo con los datos combinados. El contenido de Subformulario_Página1 se puede mostrar en una o varias páginas usando la presentación de la página de formato Página2_etc.

C.

Subformulario_ÚltimaPágina tiene una posición fija y está configurado para mostrar los objetos en la última página representada con la presentación de la página de formato Página3.

Cuando Forms represente el formulario HTML en tiempo de ejecución, el primer subformulario de nivel de página se mostrará en la primera página de trabajo. En este ejemplo, la primera página sería más o menos como se muestra aquí. Aparece el botón Página siguiente, que se debe incluir para que los usuarios puedan pasar a la siguiente página del formulario.

Ver gráfico a tamaño completo

Suponiendo que habrá al menos un registro que se pueda combinar con Subformulario_ampliable en tiempo de ejecución, la segunda página podría tener este aspecto. De nuevo, se necesita un botón Página siguiente para que los usuarios puedan pasar a la siguiente página del formulario. Asimismo, si lo desea, puede incluir un botón Página anterior en su formulario.

Ver gráfico a tamaño completo

El tercer subformulario de nivel de página, Subformulario_ÚltimaPágina, se muestra en la última página del formulario representado. En este ejemplo, la última página agradece a los usuarios que hayan cumplimentado el formulario e incluye un botón Enviar para poder mandar los datos introducidos por el usuario a Forms.

Ver gráfico a tamaño completo

Para obtener información sobre cómo escribir una secuencia de comandos que permita a los usuarios desplazarse entre páginas HTML, consulte Redacción de secuencias de comandos para tratar páginas HTML.

La siguiente información le ayudará a diseñar formularios HTML visualmente agradables y fáciles de leer:

• No utilice las propiedades de borde de un objeto para dibujar líneas, cuadros o cuadrículas en el formulario. Algunos exploradores no alinean los bordes tal como se muestran en la vista previa de Designer. Los objetos pueden aparecer en capas diferentes o desplazar otros objetos de la posición prevista.

• Si los usuarios van a utilizar Microsoft Internet Explorer, puede diseñar el formulario con líneas, rectángulos y círculos para definir el fondo. El resto de exploradores solo admiten líneas verticales y horizontales, por lo que los rectángulos y los círculos del diseño de formulario no se mostrarán en tiempo de ejecución.

• Si los usuarios van a utilizar exploradores Opera, diseñe los campos un poco más grandes de lo que lo haría normalmente. Los campos siempre aparecen con un borde interior con relieve en Opera. Todos los estilos de borde que aplique se situarán alrededor del exterior de ese borde. Dado que el borde con relieve ocupa un espacio del campo, el área donde se pueden introducir datos será menor.

• Cree el texto estático algo más grande de lo que parece ser necesario para albergar el texto. Designer y Acrobat pueden utilizar distinto interletraje que el resto de exploradores, y es posible que cierto texto no se visualice correctamente.

Tenga en cuenta las siguientes guías cuando agregue imágenes a diseños de formulario procesados como HTML.

Archivos de imagen admitidos

Puede incluir cualquier archivo de imagen (salvo GIF animados), pero siempre con las limitaciones de los exploradores Web que vayan a emplear los usuarios para ver los formularios HTML.

Nota: recuerde que Internet Explorer procesa la combinación de objetos de botón e imagen de un modo diferente al de otros exploradores Web. Por ejemplo, si se crea un objeto de botón con un aspecto transparente personalizado y se coloca sobre un objeto de imagen, Internet Explorer puede representar el HTML resultante de un modo incorrecto y los usuarios no podrán hacer clic en el botón con un ratón. Consulte Elusión de las limitaciones de los exploradores Web.

No incruste imágenes en el formulario

Forms no admite imágenes incrustadas. En su lugar, utilice nombres de ruta relativos para insertar los archivos de imágenes. Por ejemplo, la ruta puede ser relativa al directorio raíz de Forms que, de forma predeterminada, es la carpeta designada como repositorio de formularios. La carpeta de imágenes de la ruta siguiente está al mismo nivel que la carpeta de formularios:

../images/graphic.jpg

Si se espera que algunos usuarios empleen exploradores con funciones limitadas, se deberán estudiar las limitaciones del denominador común más bajo y diseñar los formularios con esa idea. Si su empresa utiliza exploradores que admitan XHTML, habrá más opciones para presentar el diseño de formulario.

Al diseñar formularios que se vayan a ver en diferentes exploradores, se deberán tener presentes las siguientes consideraciones:

• Especifique un tamaño de página para asegurar que la transformación de HTML4 (para Netscape Navigator 4.7.x) muestra todos los objetos estáticos correctamente. En caso contrario, solo se reservará un espacio suficiente para los campos cuando se represente el formulario.

• Introduzca un margen de al menos 1/4 de pulgada (0,63 cm) en la parte superior y lado izquierdo del formulario. No se mostrará todo lo que quede encima o a la izquierda de esos márgenes.

• Los objetos o partes de objetos dibujados en coordenadas negativas de la cuadrícula tampoco quedarán visibles. Por ejemplo, si se dibuja un objeto que empieza en la coordenada vertical de cuadrícula -0,50, no se mostrará la parte del objeto que queda entre -0,50 y el borde interior del margen de 1/4 de pulgada (0,63 cm).

• Deje espacio suficiente alrededor de los campos para compensar la degradación visual que se pueda producir en un explorador de poca calidad. Por ejemplo, en algunos exploradores las casillas de verificación y los botones de radio aparecen más grandes de lo que se pensó en el diseño.

• Es posible que la alineación a la izquierda de los datos se pierda al ver el formulario en un explorador de escasa calidad, especialmente si los usuarios modifican las fuentes predeterminadas asociadas a sus exploradores.

• Internet Explorer procesa la combinación de objetos de botón e imagen de un modo diferente al de otros exploradores Web. Por ejemplo, si se crea un objeto de botón con un aspecto transparente personalizado y se coloca sobre un objeto de imagen, Internet Explorer puede representar el HTML resultante de un modo incorrecto y los usuarios no podrán hacer clic en el botón con un ratón. Sin embargo, los usuarios pueden desplazarse hasta el botón con el tabulador y pulsarlo con la tecla Intro o la barra espaciadora. Este error de procesamiento se produce porque el tamaño del objeto de botón depende de la longitud de su rótulo. La cantidad de espacio vacío en el área del rótulo debe ser lo bastante grande para que el tamaño del botón supere al de la imagen. Para resolver este problema, sustituya el texto del rótulo con suficientes espacios vacíos para permitir a los usuarios hacer clic en el botón con un ratón.

Para·comprobar·el·funcionamiento·del·diseño·de·formulario·con·Forms·y·configurar·los·botones·de·comando·adecuadamente·en·el·diseño·de·formulario,·es necesario conocer·la·URL·que·se·va·a·asociar·a·las·solicitudes·de· Forms. El desarrollador de la aplicación personalizada debe conocer la URL.

Para obtener una vista previa de un formulario HTML, el diseño de formulario debe estar disponible para Forms para que pueda guardarlo. Después, puede solicitar el formulario a través de la URL asociada a Forms. Utilice un explorador Web o una de las aplicaciones cliente de destino (como un lector de pantalla) para abrir el formulario.

Es posible incrustar cálculos y secuencias de comandos en un diseño de formulario para ejecutar cálculos, métodos u operaciones cuando alguno de los sucesos de un objeto se produzca en tiempo de ejecución. Por ejemplo, un suceso se produce en tiempo de ejecución cuando el usuario realiza la acción que indica dicho suceso. Es posible invocar cualquiera de los métodos que admita el objeto, y examinar o establecer las propiedades definiendo una secuencia de comandos.

En Designer, las secuencias de comandos y los cálculos están designados, de forma predeterminada, para ejecutarse en el dispositivo cliente. La ubicación de procesamiento predeterminada se define en la ficha Vista previa del cuadro de diálogo Propiedades del formulario (seleccione Archivo > Propiedades del formulario). Para anular la ubicación de procesamiento predeterminada, se puede especificar de forma explícita una ubicación de procesamiento diferente con la opción Ejecutar en, del Editor de secuencias de comandos, cuando se adjunte una secuencia de comandos o cálculo a un objeto.

Cuando se disponga de Forms, el procesamiento se puede realizar en el cliente, el servidor o ambos. Cuando especifique que una secuencia de comandos o cálculo se debe ejecutar en el cliente y el servidor, es posible que ambos intenten ejecutarlo. Forms siempre intenta procesar la secuencia de comandos o el cálculo cuando el cliente no pueda hacerlo. Si se configuran las secuencias de comandos o cálculos para que se ejecuten en el servidor, Forms ejecuta las secuencias de comandos y/o cálculos, combina los resultados en el formulario y los envía al cliente.

Las secuencias de comandos y cálculos del lado del cliente se ejecutan en el dispositivo cliente. Cuando se crean formularios PDF para Acrobat o Adobe Reader, todo el procesamiento se debe realizar en el cliente. Sin embargo, si el cliente no puede ejecutar la secuencia de comandos o el cálculo, Forms intentará procesarlos.

Para ejecutar satisfactoriamente una secuencia de comandos de lado del cliente en un formulario HTML, se deben cumplir ciertas condiciones:

• La aplicación cliente debe ser Microsoft Internet Explorer 5.x, Netscape 6.0 o posterior, o bien Opera 5 o posterior.

• JavaScript solo se puede utilizar para escribir secuencias de comandos (no es posible incluir cálculos FormCalc en el diseño de formulario).

• JavaScript debe estar activado en la aplicación cliente.

El procesamiento se puede ejecutar en el cliente, el servidor o en ambos. Las secuencias de comandos y cálculos se comportan de forma diferente según se ejecuten en el cliente o el servidor.

Si se va a utilizar un único diseño de formulario para crear formularios PDF y HTML, es posible que las secuencias de comandos describan un subconjunto de las propiedades, métodos y sucesos admitidos.

En las tablas siguientes se resumen las aplicaciones de cliente que reconocen las diversas propiedades, métodos y sucesos que se pueden describir en secuencias de comandos del lado del cliente o el servidor.

Nota 1: en el caso de cuadros de lista, formattedValue no devuelve el texto de muestra.

Nota 2: el suceso click no se admite para los botones Enviar en los formularios PDF o HTML. Utilice preSubmit en su lugar.

Nota 3: el objeto ScriptObject se puede crear y utilizar con cualquier otra secuencia de comandos. Consulte Creación de un objeto de secuencia de comandos.

Nota 1: en el caso de cuadros de lista, formattedValue no devuelve el texto de muestra.

Nota 2: el suceso click no se admite para los botones Enviar en los formularios PDF. Utilice preSubmit en su lugar.

Nota 3: el objeto ScriptObject se puede crear y utilizar con cualquier otra secuencia de comandos. Consulte Creación de un objeto de secuencia de comandos.

Los clientes HTML admiten un subconjunto simplificado de expresiones de sintaxis de referencia:

• Los cálculos de FormCalc no son válidos en exploradores HTML y se eliminan antes de que se procese el formulario en HTML.

• La sintaxis de elipsis (...) no está admitida.

• Cuando se escriba una secuencia de comandos de lado de cliente para formularios HTML, se debe utilizar la expresión de JavaScript resolveNode para ubicar los nodos en la jerarquía. La secuencia de comandos no puede recorrer la jerarquía con la notación de objetos. Por ejemplo, no se admite la siguiente expresión:

      xfa.form.subform1.TextEdit1

La siguiente expresión sí está admitida:

xfa.form.resolveNode("subform1.TextEdit1")

Se pueden utilizar las referencias de campos no cualificadas para ubicar campos secundarios en la jerarquía.

Cuando se utiliza el mismo diseño de formulario para representar formularios PDF y HTML, la configuración del tamaño de página se usa para paginar los formularios PDF, pero no se tiene en cuenta al representar los formularios HTML. Para tratar las diferencias entre las páginas PDF y HTML, los autores de los formularios pueden utilizar también subformularios de nivel de página, para configurar unas páginas HTML artificiales. Si se configuran las páginas HTML de este modo, se necesita JavaScript para que los usuarios puedan pasar de una página HTML a la siguiente en tiempo de ejecución.

Puede utilizar los métodos pageUp() y pageDown() para que los usuarios puedan desplazarse entre las páginas HTML con un botón de comando normal, que desencadene el procedimiento cuando se produzca el suceso click del botón. Los formularios PDF y HTML se deben ejecutar en el cliente y en el servidor.

Los métodos pageUp() y pageDown() funcionan en subformularios de nivel de página. Por ejemplo, supongamos que el autor del formulario ha configurado la estructura siguiente en el diseño de formulario:

A.

Este subformulario de nivel de página corresponde a la primera página.

B.

Este subformulario de nivel de página corresponde a la segunda página.

C.

Este subformulario de nivel de página corresponde a la tercera página.

Si el usuario está viendo la página HTML que corresponde a Subformulario_Página0, invocar xfa.host.pageDown() hará que se muestre Subformulario_Página1 en el explorador. Del mismo modo, invocar xfa.host.pageUp() mientras aparece Subformulario_Página1 en la pantalla, hará que se muestre Subformulario_Página0 en el explorador. Los números de página se asignarán a las siguientes propiedades para manipular estas páginas HTML:

xfa.host.currentPage = 0     //moves to the first page 
xfa.host.currentPage = 1     //moves to the second page 
xfa.host.currentPage = 2     //moves to the third page 
xfa.host.currentPage = xfa.host.numPages -1     //moves to the last page

A medida que los usuarios pasan por las páginas HTML, el estado de los datos se conserva, pero el estado de presentación de los objetos (por ejemplo, el color de fondo de un campo) puede variar de una página a la siguiente. Es posible mantener los valores de presentación entre las páginas mediante campos ocultos que contengan los valores de estado de las diversas configuraciones y botones de comando que permitan que los usuarios avancen y retrocedan por las páginas del formulario. La secuencia de comandos actualizará los estados de presentación de los campos, basándose en los valores de los campos ocultos. Cuando un usuario hace clic en alguno de los botones de comando, el suceso calculate del botón se puede usar para ejecutar la secuencia de comandos.

Por ejemplo, el siguiente JavaScript mantiene el color de relleno de un campo basándose en el valor de un campo denominado hiddenField. La secuencia de comandos se desencadena cuando se produce el suceso calculate.

If (hiddenField.rawValue == 1) 
this.fillColor = "255,0,0" 
else 
this.fillColor = "0,255,0"