Retocando Formularios, Episodio III (“El Retorno”)

Después de tanto tiempo, quizás alguno de los tres (incluyendote a ti) lectores de niquelao pensaba que no volverí­amos a escribir sobre los formularios… evidentemente no nos conoce lo suficiente.

El episodio de hoy gira en torno a la idea de conseguir la validación del formato en el que han sido introducidos los datos en los campos de un formulario (o más de uno en el mismo documento, evidentemente).

Planteamiento

Conseguir un script de cliente con las siguientes caracterí­sticas:

• Reconocer el formato (tipo de dato y/o longitud) con el que hemos introducido los datos en el formulario
• Reutilizable para más de un formulario por documento
• No intrusivo
• Sin modificar (o con una mí­nima modificación) el código de la página
• Accesible para las ayudas técnicas tales como los lectores de pantalla

En episodios anteriores de “Retocando formularos”…

A las funcionalidades desarrolladas previamente en los episodios anteriores (Episodio I y Episodio II)…

• Limpiar de caracteres introducidos por defecto y restaurarlos en su caso
• Comprobar si se han rellenado los campos obligatorios y devolver el error correspondiente si es necesario
• El script aplica su proceso de reconocimiento de la misma manera que lo harí­a un usuario (leyendo la información de cumplimentación del formulario (aportada por ejemplo en el propio label del campo)
• Modificación mí­nima o nula del marcado

…se han añadido:

• Comprobación de que se ha introducido un correo electrónico válido
• Comprobación de que se ha introducido un mí­nimo de caracteres
• Comprobación de que se ha introducido un número si es este el único formato posible

El script

Podéis probar el funcionamiento del script directamente en la página de ejemplo. En esta se han incluido tres formularios para demostrar que es reutilizable y no se interfieren entre ellos.

Si tras probarlo, os gusta tanto como para querer utilizarlo, o sois de los que quieren comprobar lo bien (o mal) que los demás hacen las cosas para sacarle pegas y criticar… (tras esto último, deberí­a haber unos segundos de silencio) …podéis descargarlo directamente.

¿Cómo se utiliza?

nota I: Antes de decir cómo se utiliza, es súmamente importante recordar que dado que esta validación se hace en el lado del cliente, siempre va a ser necesario hacer una validación en el servidor (no hacerlo os puede restar puntos… ¿verdad Andrés?). La validación del lado de cliente nunca deberí­a sustituir a la del servidor. Lo que aporta es una mejor experiencia de usuario al no implicar las demoras que el enví­o, comprobación y devolución de información llevan asociados.

nota II: Recordaros también que siempre se debe informar al usuario acerca de cómo ha de rellenar el formulario, y esto incluye la información de campos obligatorios y de los formatos de datos a introducir. Esta información debe presentarse antes del propio formulario y no se debe dar por sentado que el usuario la va a entender tan bien como la entenderí­a un experto.

Retomando el tema introducido por el último encabezado… al comienzo del script estan declaradas unas variables. Estas son las que incluyen el texto que posteriormente se va a buscar en los label o en los controles de formulario y que servirá para identificar el formato

var for_req = '*'; // identifica el campo obligatorio
var for_mail = 'mail'; // identifica un campo como correo electrónico
var for_num = 'numero'; // identifica un campo como numérico

Los valores son los que se emplearán en el propio formulario y podrán incluirse en el contenido o la clase del elemento label o en la clase del control al que esta se asocie. Ej.:

<label for="nombre">
    Nombre *
    <input type="text" name="nombre" id="nombre" />
</label>
<label for="cp" class="numero">
    Código Postal
    <input type="text" name="cp" id="cp" />
</label>
<label for="correo">
    E-mail *
    <input type="text" name="correo" id="correo" />
</label>

También se ha añadido una variable con el texto que determinará si un dato a introducir en el formulario debe tener una longitud mí­nima:

var for_min = 'minimo';

Este texto se deberá incluir en la clase del label o del campo, indicando inmediatamente detrás de él, y mediante el/los dí­gitos correspondiente/s, su valor. Ej.:

<label for="tel">
    Teléfono
    <input type="text" class="minimo9 numero" name="tel" id="tel" />
</label>

Como se muestra en este último ejemplo, el sistema permite combinar más de una validación (a excepción de determinadas combinaciones ilógicas tales como el correo electrónico y el formato numérico).

A continuación, en el script están presentes dos variables que servirán para aplicar un estilo a los label y campos cuando estos no respeten las condiciones adecuadas de formato y obligatoriedad para su enví­o:

var labelerror = 'error';
var fielderror = 'error';

Estos valores son los nombres de las clases sobre las que declararemos estilos en la CSS. En este punto es necesario recordar que con la ejecución del script no se ven alteradas ni la cascada ni la especificidad, con lo que deberemos tenerlo presente al establecer nuestras reglas en la hoja de estilos.

Es importante también tener en cuenta que deberemos aplicar un identificador al elemento form.

Rizando el rizo

Al igual que en el episodio anterior, cuando se crea el contenido que indica el/los error/es cometidos, el foco se traslada al comienzo de este. Esto se pensó teniendo en cuenta que tras pulsar el botón de enví­o, si ocurre un error, la información de este deberí­a ser lo primero que se mostrase. Un usuario de navegador gráfico no tendrí­a mucho problema en ello (generalmente), pero el usuario que utilizase un lector de pantalla, sin ese cambio del foco, continuarí­a leyendo el contenido que hay después del botón (¿lo cogéis?).

Además, el script trata de adaptar el lenguaje empleado para la información del error de tal manera que diferencie el singular del plural en función del número de errores encontrados, e incluso si lo que se introducen son caracteres generales o dí­gitos (en el caso de que el formato sea numérico). También se trataron de agrupar los errores sobre el mismo campo agrupando así­ la información y facilitando su comprensión y lectura. Puede parecer una forma de rizar el rizo un poco exagerada, pero… ¿por qué no utilizar correctamente el lenguaje?

Optimizando

Personalmente me gusta optimizar los códigos y eliminar lo que no sea necesario. En el script se incluyen determinados fragmentos que podrí­an ser eliminados, tales como la búsqueda dentro del contenido del label, de su clase y de la clase del campo al que este se asocia, del texto para comprobar si lo introducido sigue un formato adecuado. Si siempre introducimos el mentado texto en la clase del label, las demás búsquedas podrí­an eliminarse.

Un cambio de última hora (24 de diciembre de 2006)

Haciendo pruebas me di cuenta de que no habí­a tenido en consideración que dentro del label pudiera haber un elemento de lí­nea (tipo strong, span,…) o incluso que pudiera haber asociación implí­cita con el control de formulario al que se asocia. Esto originarí­a problemas, pues al crearse la lista de errores, se mostrarí­an las etiquetas correspondientes o el propio contenido del campo. Para evitarlo acabo de incluir en el script una función que extrae el contenido de las etiquetas a la par que las elimina, y además he añadido lo necesario para no mostrar el contenido del control de formulario.

Bueno, lo dejaré ya porque son las 14:19 del dí­a de NocheBuena. Supongo que no es el momento de estar pensando en formularios y si en los seres querí­dos… así­ que Feliz Navidad a todos.