Un formulario permite

• Crear, en un cliente web, componentes gráficos como cuadros de texto, listas desplegables, listas desplazables, áreas de texto, botones, etc.

• Enviar información a programas que se almacenan y ejecutan en un servidor web para:

• Obtener información del usuario

• Generar una respuesta, habitualmente HTML, en base a los datos obtenidos del formulario.

En Java, estos programas, típicamente son los servlets y las páginas JSP. Otros programas similares no basados en Java son: programas CGI, páginas ASP, páginas PHP, páginas Javascript, etc. De aquí en adelante, se supondrá que el programa hospedado en el servidor es un servlet, aunque todo lo dicho valdrá para cualquiera de los enumerados previamente.

Cada componente gráfico está asociado a una serie de etiquetas o tags html y sus correspondientes atributos. Su contenido varía en función de las características deseadas para cada componente.

La información introducida en un formulario se envía en forma de pares name/value, tras pulsar un botón de envío que forma parte del propio formulario. El contenido de cada par name/value está muy relacionado con los atributos de las etiquetas de los componentes (se explicarán con más detalle a medida que se avance en la lección).

Las etiquetas necesarias para definir un formulario en un código html son <form> y su cierre </form>. Todas las etiquetas de sus componentes deben estar encerradas entre este par de etiquetas.

Ver ejemplo

En las siguientes secciones del tema se van a estudiar los atributos principales de esta etiqueta, y las etiquetas y atributos más frecuentes de los componentes más utilizados en un formulario típico.

Atributos habituales: action, method y enctype

• action (obligatorio): especifica el url del programa hospedado en el servidor. En nuestro caso, un servlet, que será el encargado de capturar y procesar los datos enviados desde el formulario, y de generar, habitualmente, una respuesta html que suele varíar en función de los datos enviados.

NOTA: recordar que, aunque es lo más habitual, un url no tiene por qué asociarse con un servidor web que admite peticiones de clientes del tipo http://host:puerto/ruta_recurso Puede ser también un servidor de correo cuyo tipo de peticiones admitidas es mailto:trilcejf@trilcejf.com  o la de un servidor de ficheros con peticiones del tipo ftp://ftp.mycgiserver.com. Lo habitual es que sea un url asociado un servidor web, pero no es obligatorio que sea así.

• method: indica el tipo de petición realizada desde el cliente. Fundamentalmente dos tipos: GET y POST. Se explican más adelante en este apartado.

Es un indicador del modo en que se envía información al servidor y de cómo se refleja ese envío en el cliente.

Independientemente del valor que tenga este atributo, el cliente, aparte de los datos del formulario, envía más información al servlet a la escucha en el servidor. Se estructura del siguiente modo:

• Línea principal de encabezamiento de petición: se compone de tres secciones:

• Encabezados de petición (se estudiarán más adelante).

• Cuerpo de petición

Ejemplo:

----- (Línea principal de encabezamiento de petición) -----

GET//ServletPrueba.class//1.1

----- (Encabezados de petición) -----

Host: localhost:8080

Cookie: JSESSION=A12D3E3AB

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://localhost:8080/servlets-examples/Formulario1Informacion.html

Content-Type: application/x-www-form-urlencoded

Content-Length: 38

----- (Cuerpo de la petición) -----

Los datos rellenados en el formulario en forma de pares name/value

 

Los dos valores de method más frecuentemente utilizados son:

• GET: implica que la petición no tiene cuerpo y que los datos enviados en forma de pares name/value se adjuntan en la barra de direcciones del cliente, al final del url correspondiente y después de un signo de interrogación de cierre (?) 

Cuando el cliente envía varios datos asociados a diferentes componentes del formulario, se muestran separados por el símbolo del ampersand (&).

Es el modo de envío por defecto y, por tanto, el empleado si no se especifica atributo method en la etiqueta <form>

Ejemplo:

http://...........?nombre1=valor1&nombre2=valor2

NOTA: si sólo se envía información asociada a cuadros de texto, no es necesario crear los componentes en el formulario, basta con introducirlos al final del url. Ocurre que la mayoría de clientes tiene limitado el número de caracteres que pueden escribirse en la barra de direcciones. No obstante, cuando se envía poca información o para depurar, puede ser útil.

• POST: los datos enviados no se adjuntan en la barra de direcciones del cliente sino formando parte del cuerpo de la petición

Ventajas e inconvenientes de GET frente a POST:

GET suele emplearse para depurar o probar el servlet. Como se verá en el ejemplo, no es necesario crear un formulario si se envía información no muy extensa, puesto que se puede ubicar al final del url en la barra de direcciones del cliente.

Cuando esa información supera los 255 caracteres, conviene utilizar POST. No es una limitación del protocolo HTTP, sino de algunos clientes y/o servidores que no permiten gestionar cadenas de texto de ese número de caracteres.

Ejemplo:

http://www.myjavaserver.com/~trilcejf/FormuGet.htm

Este url invoca a un formulario con las siguientes características:

• action=un servlet hospedado en el servidor de www.myjavaserver.com de nombre trilcejf.ServletGet

• method=get

Después de rellenar la información solicitada se pulsa Enviar y se observará en la barra de direcciones del cliente:

http://www.myjavaserver.com/servlet/trilcejf.ServletGet?nombre=Jesus&telefono=12345

La información enviada puede verla cualquiera que esté cerca de tu máquina. Cuando los datos no sean importantes, no importará, pero si lo son, no conviene que aparezcan en la barra de direcciones del cliente. Además, el url con los pares name/value quedará registrado en el historial.

NOTA: se podría invocar al servlet, pasándole la información de nombre y teléfono, tecleando en la barra de direcciones del cliente http://www.myjavaserver.com/servlet/trilcejf.ServletGet?nombre=Jesus&telefono=12345 No es necesario el formulario Problema: muchos clientes limitan el número de caracteres (máximo de 255) que pueden escribirse en su barra de direcciones. Cuando se necesite enviar más información de la que admite la barra de direcciones, se usará post.

Si se quiere enviar información que no supera el número máximo de 255 caracteres, qué es preferible: ¿GET o POST?

Si la información es confidencial o sensible, conviene emplear POST; si no, daría lo mismo.

Habitualmente se emplea POST.

http://www.myjavaserver.com/~trilcejf/FormuPost.htm

• enctype: establece el tipo MIME (Multipurpose Internet Mail Extension o Extensión para el envío de contenido múltiple a través de Internet) y el código de caracteres empleado para la transferencia de información entre un cliente y un servidor.

El tipo MIME especifica el tipo de dato (texto plano, texto html, imagen, sonido, etc,) que contiene la información que se transfieren un cliente y un servidor. Adjunta a la información un encabezado donde se indica el tipo y el subtipo de su contenido. Gracias a esta información, tanto el servidor como el navegador pueden manejar y presentar los ficheros correctamente. Además, especifica la herramienta software que se necesita para acceder a dicha información.

Los navegadores tienen configurados, por defecto, una serie de tipos MIME, de modo que saben cómo interpretar y ejecutar la información definida mediante estos tipos

Los servidores tienen que tener también configurados los tipos MIME adecuados, ya que si no, serían incapaces de interpretar el tipo de datos que un cliente le solicita y no podrían enviarlos adecuadamente. Generalmente, los servidores definen los tipos MIME que soportan en algún fichero de configuración interna. En el caso de Tomcat, en tomcat_home\conf\web.xml. No tiene sentido ubicar un recurso en un servidor si no soporta su tipo MIME correspondiente ya que no será capaz de interpretar las peticiones

Así, cuando un cliente invoca a un servlet está realizando una petición de un programa Java a un servidor. El MIME asociado a una aplicación Java es "application-java". Si este MIME es soportado por el servidor, no habrá problemas en resolver la petición

NOTA: no siempre ocurre lo anterior. Si un cliente realiza una petición a un fichero jnlp (representa una aplicación Java Web Start), el servidor será capaz de procesar la petición y enviárselo al cliente si soporta el MIME (application/x-java-jnlp-file) Además, el MIME le indicará al cliente, el programa en que debe delegar el procesamiento del fichero jnlp. En este caso, Java Web Start. Si está instalado, OK; si no, la petición no podrá satisfacerse y se mostrará un mensaje de error.

Cuando se trabaja con formularios, el MIME es "application/x-www-form-urlencoded" (se incluye por defecto, así que no es necesario escribirlo). Esto significa que la información enviada desde un formulario a un programa hospedado en un servidor se "envuelven" del siguiente modo:

Los espacios en blanco se convierten en signos + y los caracteres no alfanuméricos en enteros hexadecimales precedidos del símbolo del tanto por ciento. Todos los servidores web soportan este tipo MIME.

La respuesta generada suele ser html. Su MIME es "text/html". Cuando el servidor envía la respuesta al cliente, éste, en base al tipo MIME en que se ha envuelto, conoce el programa adecuado para interpretarla. En este caso, el propio cliente.

Ejemplos de tipos MIME: la estructura de los tipos registrados es "tipo base/subtipo"; la de los no registrados "tipo base/x-subtipo":

text/plain                                                       Envío de información  mediante texto plano

text/html                                                        Envío de información mediante código HTML

image/gif                                                        Envío de información mediante el formato .gif para imágenes

image/jpeg                                                      Ídem mediante el formato .jpeg para imágenes

application/x-www-form-urlencoded                     Envío de información mediante formularios HTML

application/x-java-archive                                  Ídem mediante ficheros .jar

application/msword                                           Ídem mediante un documento de Word

application/vnd.ms-excel                                    Ídem mediante un libro de trabajo de Excel

application/pdf                                                 Ídem mediante un documento de Acrobat

application/zip                                                  Ídem mediante un fichero comprimido .zip

application/octet-stream                                    Ídem mediante un fichero binario o no reconocido

NOTA 1: el tipo MIME y el código de caracteres por defecto, de la información generada por un servlet para definir la respuesta, es text/html y ISO-8859-1 respectivamente.

 

NOTA 2: no confundir el tipo MIME con el código de caracteres empleado para envían información textual. No es lo mismo escribir el contenido de un formulario en Japón o en paises árabes que en Europa puesto que se utilizan diferentes caracteres. El usado en los paises occidentales y con el que se generan, a menos que se especifique otro, las respuestas en los servlets es ISO-8859-1

Ejemplos de formularios:

http://www.planetalia.com/informacion_esp.jsp

Ir a Menú Ver/Código fuente y realizar una búsqueda mediante usando <form

<form method=post action="SolicitarInformacion">

http://www.myjavaserver.com/~trilcejf/EncuestaPrivada.html