[semptrion]

Estuve revisando los comentarios acerca de tu consulta y encuentro muy acertada la respuesta que te dio dec cuatro días atrás.

Lo que sucede es que en el lado del cliente, no se puede hablar de validación. Lo que quiero decir es que nosotros, al momento de programar no sabemos cual será el cliente. Puede ser un navegador (que es lo más frecuente) pero tambi;en pueden ser programas de exploración o de hacking.

Como debes bien saber, cuando un cliente te hace una petición de grabación, ignoras por completo su identidad (porque puede ser un programa enmascarado) y que, si confiaste la validación a ese lado, pues ya te enchufaron alguna barbaridad.

Un ejemplo de como enmascarar a un cliente publiqué en noviembre de 2003 en http://us2.php.net/manual/es/function.fsockopen.php [This is a very fast program for test a form or link (many times).] que es un programa que utiliza sockets para enmascararse en una solicitud sea POST o GET y que, cuando no se realiza validación del lado del servidor, permite hacer algo. (Cabe aclarar que el programa fue diseñado para testear sitios, aunque su uso a salido de ese contexto y ha sido utilizado por ejemplo, para votar en encuestas, deformando resultados de algunos sitios primitivos y en algunos casos, para pruebas de passwords, llenado "automático de formularios", etc.)

Entonces, cuando el desarrollador se apoya en el cliente, se está apoyando en bruma: nada de nada. Todo es (o puede ser) ficticio del lado del cliente. Al fin de cuentas, lo único que conocemos es lo que el cliente nos informa que es.

Y puede ser muchas cosas: puede ser un IE 5.0 o un mozilla; puede ser una cámara de video o puede ser un dispositivo para braile; puede ser un robot o puede ser un navegador de texto.

Si es un browser (si tenemos la fortuna que no nos engañe y sea un browser de verdad) puede o no soportar el código javascript que hemos preparado cuidadosamente para "ayudar" al usuario y para que "no tenga que esperar tanto".

Así, AJAX y otras "ideas" no dejan de ser buenas al momento de recibir información. Aunque incompletas por el tema de la diferencia entre los clientes, llegan a ser muy malas en tiempo de validación.

Usen AJAX, AXE o lo que gusten. Sólo confíen en la validación del lado del servidor. Si no la tienen, prepárense a recibir basura o peor aún, a ver como destruyen la data del sitio.

Y es que hay otra premisa (la primera fue: no confíes en el cliente) y es que no existen usuarios tontos o inexpertos en la internet. Tarde o temprano algún desesperado con suerte encontrará la forma de violar la validación del lado del cliente.

Conclusión: validar del lado del servidor es la única opción.

Validar del lado del cliente, es... tanto trabajo para nada, que quizá no valga la pena intentarlo.

Ahora, la inteligencia del desarrollador radica en que debe hacer tan pocas consultas al servidor como le sea posible. Es decir, si es un formulario, deberá enviarlo una sola vez, y no partirlo en pequeños trocitos incrementales como si fuera un programación stand alone, es decir, donde tenemos toda la lógica de la aplicación residente en memoria.

Así, quizá sea necesario que empecemos a pensar que hay algunas cosas que podemos "asumir" como por ejemplo el tema de los espacios en blanco o de si un texto debía ser introducido en mayúsculas haya sido introducido en minúsculas, o que le puso letras en vez de números, etc.

Es decir, que hay algunas cosas que pasan con demasiada frecuencia como para saber cual es la acción que debemos tomas.

Por ejemplo, si colocaron espacios antes del texto o después del texto, le aplicamos la función trim y asunto arreglado. Si el usuario puso minúsculas en vez de mayúsculas, pues convertimos el texto en mayúsculas. Y así así.

Por esas macanas no fastidiamos al usuario ni utilizamos su canal para "avisarle" que "metió la pata" y que sus datos no se han grabado por ello.

Es más, existen por lo menos dos niveles de error: alertas y errores. Los errores son los que impedirían que continúe el proceso de grabación, porque, por ejemplo se quiere colocar un texto en vez de una fecha; en cambio las alertas son las que permiten grabar, pero no terminar la tarea.

Con lo que quedamos en que:

- Se debe enviar el formulario una sola vez y con toda la información.
- En caso de error en la validación:
* Si existen acciones que se puedan tomar, se las toma (p.e. quitar espacios)
* Si existe la posibilidad que el valor del campo perjudique la operación del sistema, se considera que es un error (no se graba y se informa)
* Si no existe la posibilidad que el valor del campo perjudique la operación del sistema, se determinará alerta, que permitirá grabar los datos, pero no continuar con el siguiente paso (por ejemplo, terminar).

- Un error se informa (y se informa que no han sido grabados los datos)
- Una alerta se informa (y se informa que han sido grabados los datos, pero que no podrá continuar con la siguiente operación, si no corrige)
- Una acción se informa (y se informa lo que se ha modificado)

Esta mecánica de trabajo la utilizo cuando se trata de aplicaciones sobre la web. Es decir, en el caso de formularios oportunistas (por ejemplo los de suscripción que sólo se presentan una vez), la distinción entre error y alerta es prácticamente inexistente.

Bueno. Y me alargué nomás. Espero que te sirva de algo lo indicado.
Y todo esto, del lado del servidor.