Formularios web

¿Qué es un formulario?

Un formulario es el momento exacto en que la persona entrega los datos. Todo lo anterior era preparación: la base diseñada, la tabla creada, la pantalla mostrada. Acá el usuario escribe, y lo que escriba es lo que va a quedar guardado.

El equivalente en papel es la planilla de la mesa de entradas: tiene casilleros, cada casillero tiene un rótulo y hay uno que dice firma al final. El formulario web hace lo mismo, con tres diferencias que lo vuelven mucho mejor:

• Puede impedir el error. En papel, si alguien escribe la fecha como «el martes», no hay nada que hacer. En un formulario web se pone un calendario y el problema desaparece.
• Avisa en el momento. El error se corrige ahí mismo, con el usuario todavía enfrente, en lugar de descubrirse tres días después.
• No se pierde ni se traspapela. Y no hay que pasarlo a la computadora después: lo que se escribe es el dato.

La etiqueta form

Todo formulario arranca con <form>, que es el envoltorio. Los controles que están adentro pertenecen a ese formulario; los que están afuera, no. Es la frontera que define qué se manda junto cuando alguien aprieta el botón.

Y tiene dos atributos que hay que definir siempre:

<form action="/socios/guardar" method="post">
    ... los controles ...
</form>

Si se omite action, el formulario se manda a la misma página donde está escrito. Es cómodo para formularios que se validan a sí mismos, pero cuando el dato va a una tabla conviene escribirlo siempre: dejar que el navegador decida la dirección es una forma silenciosa de mandar datos al lugar equivocado.

Anatomía de un campo

Un campo no es solo el casillero donde se escribe. Son tres piezas que trabajan juntas, y cada una cumple una función que ninguna otra puede cumplir:

• El rótulo (<label>): el texto que explica qué hay que escribir.
• El casillero (<input> y sus parientes): dónde se escribe.
• El nombre (name): la clave con la que ese dato va a viajar hasta la tabla.

Los dos primeros se ven; el tercero no. Y el tercero es el más importante de los tres: sin name, el dato no viaja. El usuario lo escribe, aprieta el botón, el servidor recibe todo lo demás y ese campo no está. No hay error, no hay aviso: simplemente falta.

Como el name es un identificador técnico y no un texto para leer, se escribe en minúscula, sin espacios, sin acentos y sin eñes: nombre, correo, fecha_nacimiento. Y no se repite: si dos campos comparten el name, el segundo pisa al primero y uno de los dos datos se pierde en silencio.

Los controles

HTML trae un control distinto para cada tipo de dato. Elegir el correcto es la mitad del trabajo de un buen formulario:

La regla general es simple: si la respuesta posible se conoce de antemano, no se deja escribir libremente. Cada vez que se reemplaza un casillero de texto por una lista desplegable o por un par de botones de opción, se elimina de cuajo toda una familia de errores de tipeo. Cada control se ve en detalle en Tipos de ingreso.

Un formulario completo

Estos son los mismos campos de la figura anterior, ya escritos como corresponde. Es un formulario mínimo de alta de socio:

<form action="/socios/guardar" method="post">

    <label for="nombre">Nombre y apellido</label>
    <input type="text" id="nombre" name="nombre" required>

    <label for="correo">Correo electrónico</label>
    <input type="email" id="correo" name="correo" required>

    <label for="nacimiento">Fecha de nacimiento</label>
    <input type="date" id="nacimiento" name="nacimiento">

    <button type="submit">Guardar socio</button>

</form>

Vale la pena leerlo por partes, porque cada línea tiene una razón:

• El action apunta al programa que guarda, y method="post" porque se están creando datos, no consultándolos.
• Los campos de texto y correo llevan required: sin ellos el formulario no se envía. Son los que no pueden quedar vacíos.
• La fecha no lleva required, porque es opcional. Marcarlo o no es una decisión sobre el dato, no sobre el diseño.
• El tipo email no valida que el correo exista —eso es imposible— pero sí que tenga la forma correcta: algo, una arroba, algo, un punto.
• Cada name es distinto. Si dos lo compartieran, uno de los dos datos no llegaría.

Y el button es de tipo submit. Parece un detalle, pero un botón sin type declarado también envía: si más adelante alguien agrega un segundo botón para «cancelar» y se olvida de ponerle type="button", ese botón va a enviar el formulario en lugar de cancelarlo.

Qué llega al servidor

Conviene tener claro qué es exactamente lo que viaja, porque de eso depende todo lo que se puede hacer después. Lo que llega al servidor es una lista de pares: el name de un lado y lo que el usuario escribió del otro.

No llega nada más. No llega el rótulo, no llegan los colores, no llega el orden en que se ven los campos, no llega el archivo CSS. El servidor recibe:

nombre = Ana
correo = [email protected]

De ahí salen tres consecuencias que explican casi todos los problemas reales de carga de datos:

• Al servidor le importa el name, no el rótulo. Se puede cambiar el texto «Nombre y apellido» por «Apellido y nombre» sin tocar nada del servidor; pero si se cambia el name, el programa deja de encontrar el dato.
• Nada viaja solo. Cada dato que se quiera guardar necesita su campo con su name. Lo que no se pide, no llega.
• Todo lo que llega es texto, y todo lo que llega puede venir mal. El servidor recibe exactamente lo que se le mandó, incluido lo que un usuario malintencionado armó a mano. Que el campo se haya visto bien en pantalla no garantiza nada.

Esa última idea es la que sostiene toda la unidad: el formulario colabora, pero el que decide es el servidor. Y el que tiene la última palabra, siempre, es la base de datos con sus tipos y sus reglas.

Resumen

• El formulario es el momento en que el usuario entrega los datos.
• Un formulario no guarda nada: junta y manda. El que guarda es el servidor.
• <form> es el envoltorio, y define qué se manda junto.
• action dice a dónde se mandan los datos y method, cómo viajan.
• Un campo tiene rótulo (label), casillero (input) y nombre (name).
• Sin name el dato no viaja, y si dos campos lo comparten, uno pisa al otro.
• El label se une al control por for y id, que es lo que permite tocar el rótulo y que el lector de pantalla lo anuncie.
• A cada tipo de dato le corresponde un control distinto: cuanto menos texto libre, menos errores.
• Al servidor llega una lista de pares name = valor, y nada más.
• El formulario colabora; el servidor y la base de datos deciden.

Ver el lenguaje HTML