validacion de cliente y de servidor

cuando validas algo, no necesariamente consideras que es un dato "critico" o

depende lo que entiendas por "critico". puedes perfectamente validar un
campo "nombre" donde lo unico que vas a validar es si hay algo o no. es
decir: verificar que hay datos en un campo "obligatorio". ¿de que lado
validas este campo?¿cliente? ¿servidor? ¿ambos? Otra cosa: eso de crear un
formulario que "ataque" al servidor es algo que tengo medianamente claro
por
lo que ¿seria posible que me des un ejemplo simple que me permita entender
este concepto?

Bueno, depende directamente de la implicancia que tenga en tu codigo. O sea,
supongamos que un campo debe ser obligatorio, como el nombre. Podrias
validarlo en el cliente, pero cuando lo metes a tu DB, el campo en cuestion,
por ejemplo, no acepta nulos, o campos vacios, o peor aun, puede que acepte
todo eso, pero en un futuro necesitas del nombre para hacer alguna otra
cosa.

Un campo critico es aquel que en el lapso del tiempo, te invalide algo de tu
codigo. Otro ejemplo, supongamos que haces una simple validacion para que el
formato de correo electronico sea el adecuado, pero lo haces en el cliente,
y este, se lo salta, por algun motivo rompe tu script y manda la informacion
sin ese campo, o con el campo fallado. Podrias necesitar dicho correo para
enviar algun mail de contacto, y si no es correcto, pues no podras hacerlo.

Personalmente, prefiero siempre, hacer una verificacion por parte del
servidor.

Con respecto al formulario, es facil. Supon que tienes tu form con un script
de validacion:

<script>
function Validar()
{



}
</script>

<form name... action="OtraPagina.asp" onSubmit="Validar()">

Hasta el momento tu pagina funcionaria normalmente.

Ahora yo hago un pagina HTML en mi maquina, y hago esto:

...
...
...
<form name... action="OtraPagina.asp">

Fijate que el ACTION es lo unico importante, o sea, la pagina que tomará la
informacion que le envias desde tu formulario. He creado otra pagina web,
sin la validacion, y te estoy saltando todos tus controles. Si tu aplicacion
no esta preparada, o sea, no valida en el servidor, puede que arroje un
error.

si se ha validado por el cliente, no existe ninguna razon que no lo valide
el servidor, salvo que el usuario cambie los valores. ¿no es asi?

Siempre es bueno hacer la verificación en el ambiente que interactuará con
tus datos.

si la validacion cliente solo vale para dar "color" y "dinamismo" a la
aplicacion y debemos sea lo que sea usar una "validacion servidor". ¿no se
podria evitar la validacion cliente? es decir: si valido del lado servidor
y
me vale, ¿porque debo validar del lado cliente? quiza vayas a pensar que
te
hago una pregunta a partir de una respuesta que me acabas de dar,
entonces,
¿me puedes explicar eso de "dinamismo" y "color"?

El dar dinamismo y color me refiero a que, como el WEB en si, o sea, todo
lenguaje de servidor, nace cuando la pagina esta siendo cargada, y muere
cuando se termina de cargar, no hay forma, por ejemplo, de interactuar con
el usuario directamente. En el caso de las validaciones del lado del
cliente, son solo para que el usuario tenga la oportunidad actualizar la
informacion sin necesidad de esperar un refresh de la pagina. O sea, para
que no pierda el tiempo. Se hace mas facil de usar, pero no le quita al
programador, peso de ensima.

el que tu me hables de reutilidad de codigo entre lenguajes distintos en
cliente y servidor, significa que supones que se van a desarrollar de cada
lado funciones equivalentes en esos distintos lenguajes, ¿es asi?
ademas, pienso que es perfectamente factible que un programador desarrolle
todo en JavaScript, tanto del lado cliente como servidor por lo que en
este
caso la reutilidad seria total, ¿que crees?

Cuando desarrolles en ASP es preferible que uses del lado del servidor,
VBScript, ya que es el lenguaje por excelencia para esta tecnologia. Por lo
que, si de un lado tienes JS y del otro VBs, por sintaxis no podras usar lo
mismo.

En el caso de que hagas todo con JS, pues la reutilidad no seria 100%,
posiblemente un 99% :), pero igual tendrias que modificar algunas cositas.

supongo y corrigeme si me confundo que la funcion "validar" debera llamar

cada funcion que valide cada campo (son validaciones distintas) para
devolver un resultado booleano global. si al menos 1 de los 2 textbox
devuelven el valor false, sera el valor devuelto en e submit por la funcion
de validacion global ¿es asi?
<<<<

Puede que lo hagas de esa forma, o podrias tener en la misma funcion la
validacion de todos los campos. No es necesario que tengas un funcion por
control.

de todas formas, te voy a hacer la pregunta directamente aplicada a mi

problema que seguramente encontraras muy simple: tengo un formulario de
registro de clientes que contiene 3 tipos de informacion: contacto, datos de
entrega, datos de facturacion. ¿como harias tu la validacion?<<<

Pues, haria de las dos, un poco de JS para que el usuario no tenga que
perder tiempo, e indudablemente, una vez se hace el submit, validar
nuevamente.
La unica diferencia es que utilizaria OnBlur en cada campo, para validar al
momento que el campo pierde el foco, y no cuando se apreta el boton del
submit. De esta manera, podrias darle informacion al usuario de que, lo que
acaba de hacer esta mal, pero de una manera mas rapida.

Saludos.

Matías Iacono
Microsoft MVP ASP/ASP.net - DCE3
"Enrique" escribió en el mensaje
news:%23IH3$

aun asi tengo dudas, te hago las preguntas.

En realidad no, siempre es preferible la validacion por parte del

servidor.

Por lo general, cuando alguien va a validar algo, es porque concidera que
ese dato es critico, por ende, y como dices mas adelante, alguien con
algo
de conocimientos podria hacer que todo vuele por los aires.

cuando validas algo, no necesariamente consideras que es un dato "critico"
o
depende lo que entiendas por "critico". puedes perfectamente validar un
campo "nombre" donde lo unico que vas a validar es si hay algo o no. es
decir: verificar que hay datos en un campo "obligatorio". ¿de que lado
validas este campo?¿cliente? ¿servidor? ¿ambos? Otra cosa: eso de crear un
formulario que "ataque" al servidor es algo que tengo medianamente claro
por
lo que ¿seria posible que me des un ejemplo simple que me permita entender
este concepto?

Ademas, si no lo validas en el servidor, puedes probocar una entrada
incorrecta, generando un error en la aplicacion.

si se ha validado por el cliente, no existe ninguna razon que no lo valide
el servidor, salvo que el usuario cambie los valores. ¿no es asi?

Normalmente se usa la validacion del lado del servidor. La del cliente,
es
solo para darle "color" a tu aplicacion. Es para darle dinamismo, pero

esto

no te asegura que te salves de los problemas.

si la validacion cliente solo vale para dar "color" y "dinamismo" a la
aplicacion y debemos sea lo que sea usar una "validacion servidor". ¿no se
podria evitar la validacion cliente? es decir: si valido del lado servidor
y
me vale, ¿porque debo validar del lado cliente? quiza vayas a pensar que
te
hago una pregunta a partir de una respuesta que me acabas de dar,
entonces,
¿me puedes explicar eso de "dinamismo" y "color"?

Cuando validas en el cliente, lo haces con un lenguaje, cuando lo haces
en
el server lo haces en otro. Asi que posiblemente la sintaxis no sea la
misma, pero la logica puede que si. De cualquier manera, si haces

referencia

a la reutilidad del codigo, pues creo que no habia casi ninguna, en el

caso

de que uses distintos lenguajes.

el que tu me hables de reutilidad de codigo entre lenguajes distintos en
cliente y servidor, significa que supones que se van a desarrollar de cada
lado funciones equivalentes en esos distintos lenguajes, ¿es asi?
ademas, pienso que es perfectamente factible que un programador desarrolle
todo en JavaScript, tanto del lado cliente como servidor por lo que en
este
caso la reutilidad seria total, ¿que crees?

Si lo haces en el cliente:

<script>
function Validar()
{
if .
{
//Si cumple
return true;
}
else
{
return false;
}
}
</script>

<form onSubmit="return Validar()">

aqui se llama a la funcion "validar". el submit por lo que veo solo
permite
llamar a una funcion y no a varias sucesivas. en este caso, parece ser que
solo se trata de validar a un textbox, digamos el A, ¿que pasa con el 2º
textbox?
supongo y corrigeme si me confundo que la funcion "validar" debera llamar
cada funcion que valide cada campo (son validaciones distintas) para
devolver un resultado booleano global. si al menos 1 de los 2 textbox
devuelven el valor false, sera el valor devuelto en e submit por la
funcion
de validacion global ¿es asi?

Si, al tener que procesar los datos en el servidor, deberias escribir
HTML
desde el servidor al lado de cada control o donde quieras.
Aunque, como te comentaba antes, el ir de una pagina a otra hara que

tengas

que trabajar mas con el manejo de los errores. Es mejor que toda esa

logica

la pongas en una unica pagina.

eso si. ninguna pega con eso. es mejor que una pagina se llame a si misma
que llamar una pagina transparente, es decir sin codigo HTML y compuesta
unicamente de codigo ASP y VBScript.


de todas formas, te voy a hacer la pregunta directamente aplicada a mi
problema que seguramente encontraras muy simple: tengo un formulario de
registro de clientes que contiene 3 tipos de informacion: contacto, datos
de
entrega, datos de facturacion. ¿como harias tu la validacion?

muchas gracias por tu ayuda

gracias, matías, todo ha quedado claro esta vez :-)


"Matías Iacono" escribió en el mensaje
news:

cuando validas algo, no necesariamente consideras que es un dato "critico"

o

> depende lo que entiendas por "critico". puedes perfectamente validar un
> campo "nombre" donde lo unico que vas a validar es si hay algo o no. es
> decir: verificar que hay datos en un campo "obligatorio". ¿de que lado
> validas este campo?¿cliente? ¿servidor? ¿ambos? Otra cosa: eso de crear

un

> formulario que "ataque" al servidor es algo que tengo medianamente claro
> por
> lo que ¿seria posible que me des un ejemplo simple que me permita

entender

> este concepto?

Bueno, depende directamente de la implicancia que tenga en tu codigo. O

sea,

supongamos que un campo debe ser obligatorio, como el nombre. Podrias
validarlo en el cliente, pero cuando lo metes a tu DB, el campo en

cuestion,

por ejemplo, no acepta nulos, o campos vacios, o peor aun, puede que

acepte

todo eso, pero en un futuro necesitas del nombre para hacer alguna otra
cosa.

Un campo critico es aquel que en el lapso del tiempo, te invalide algo de

tu

codigo. Otro ejemplo, supongamos que haces una simple validacion para que

el

formato de correo electronico sea el adecuado, pero lo haces en el

cliente,

y este, se lo salta, por algun motivo rompe tu script y manda la

informacion

sin ese campo, o con el campo fallado. Podrias necesitar dicho correo para
enviar algun mail de contacto, y si no es correcto, pues no podras

hacerlo.

Personalmente, prefiero siempre, hacer una verificacion por parte del
servidor.

Con respecto al formulario, es facil. Supon que tienes tu form con un

script

de validacion:

<script>
function Validar()
{



}
</script>

<form name... action="OtraPagina.asp" onSubmit="Validar()">

Hasta el momento tu pagina funcionaria normalmente.

Ahora yo hago un pagina HTML en mi maquina, y hago esto:

...
...
...
<form name... action="OtraPagina.asp">

Fijate que el ACTION es lo unico importante, o sea, la pagina que tomará

la

informacion que le envias desde tu formulario. He creado otra pagina web,
sin la validacion, y te estoy saltando todos tus controles. Si tu

aplicacion

no esta preparada, o sea, no valida en el servidor, puede que arroje un
error.

>>si se ha validado por el cliente, no existe ninguna razon que no lo

valide

>>el servidor, salvo que el usuario cambie los valores. ¿no es asi?

Siempre es bueno hacer la verificación en el ambiente que interactuará con
tus datos.

>>si la validacion cliente solo vale para dar "color" y "dinamismo" a la
>>aplicacion y debemos sea lo que sea usar una "validacion servidor". ¿no

se

>>podria evitar la validacion cliente? es decir: si valido del lado

servidor

>>y
>>me vale, ¿porque debo validar del lado cliente? quiza vayas a pensar que
>>te
>>hago una pregunta a partir de una respuesta que me acabas de dar,
>>entonces,
>>¿me puedes explicar eso de "dinamismo" y "color"?

El dar dinamismo y color me refiero a que, como el WEB en si, o sea, todo
lenguaje de servidor, nace cuando la pagina esta siendo cargada, y muere
cuando se termina de cargar, no hay forma, por ejemplo, de interactuar con
el usuario directamente. En el caso de las validaciones del lado del
cliente, son solo para que el usuario tenga la oportunidad actualizar la
informacion sin necesidad de esperar un refresh de la pagina. O sea, para
que no pierda el tiempo. Se hace mas facil de usar, pero no le quita al
programador, peso de ensima.

>>el que tu me hables de reutilidad de codigo entre lenguajes distintos en
>>cliente y servidor, significa que supones que se van a desarrollar de

cada

>>lado funciones equivalentes en esos distintos lenguajes, ¿es asi?
>>ademas, pienso que es perfectamente factible que un programador

desarrolle

>>todo en JavaScript, tanto del lado cliente como servidor por lo que en
>>este
>>caso la reutilidad seria total, ¿que crees?

Cuando desarrolles en ASP es preferible que uses del lado del servidor,
VBScript, ya que es el lenguaje por excelencia para esta tecnologia. Por

lo

que, si de un lado tienes JS y del otro VBs, por sintaxis no podras usar

lo

mismo.

En el caso de que hagas todo con JS, pues la reutilidad no seria 100%,
posiblemente un 99% :), pero igual tendrias que modificar algunas cositas.

>>>supongo y corrigeme si me confundo que la funcion "validar" debera

llamar

cada funcion que valide cada campo (son validaciones distintas) para
devolver un resultado booleano global. si al menos 1 de los 2 textbox
devuelven el valor false, sera el valor devuelto en e submit por la

funcion

de validacion global ¿es asi?
<<<<

Puede que lo hagas de esa forma, o podrias tener en la misma funcion la
validacion de todos los campos. No es necesario que tengas un funcion por
control.

>>>de todas formas, te voy a hacer la pregunta directamente aplicada a mi
problema que seguramente encontraras muy simple: tengo un formulario de
registro de clientes que contiene 3 tipos de informacion: contacto, datos

de

entrega, datos de facturacion. ¿como harias tu la validacion?<<<

Pues, haria de las dos, un poco de JS para que el usuario no tenga que
perder tiempo, e indudablemente, una vez se hace el submit, validar
nuevamente.
La unica diferencia es que utilizaria OnBlur en cada campo, para validar

al

momento que el campo pierde el foco, y no cuando se apreta el boton del
submit. De esta manera, podrias darle informacion al usuario de que, lo

que

acaba de hacer esta mal, pero de una manera mas rapida.

Saludos.

Matías Iacono
Microsoft MVP ASP/ASP.net - DCE3
"Enrique" escribió en el mensaje
news:%23IH3$
> aun asi tengo dudas, te hago las preguntas.
>
>> En realidad no, siempre es preferible la validacion por parte del
> servidor.
>> Por lo general, cuando alguien va a validar algo, es porque concidera

que

>> ese dato es critico, por ende, y como dices mas adelante, alguien con
>> algo
>> de conocimientos podria hacer que todo vuele por los aires.
>
> cuando validas algo, no necesariamente consideras que es un dato

"critico"

> o
> depende lo que entiendas por "critico". puedes perfectamente validar un
> campo "nombre" donde lo unico que vas a validar es si hay algo o no. es
> decir: verificar que hay datos en un campo "obligatorio". ¿de que lado
> validas este campo?¿cliente? ¿servidor? ¿ambos? Otra cosa: eso de crear

un

> formulario que "ataque" al servidor es algo que tengo medianamente claro
> por
> lo que ¿seria posible que me des un ejemplo simple que me permita

entender

> este concepto?
>
>> Ademas, si no lo validas en el servidor, puedes probocar una entrada
>> incorrecta, generando un error en la aplicacion.
> si se ha validado por el cliente, no existe ninguna razon que no lo

valide

> el servidor, salvo que el usuario cambie los valores. ¿no es asi?
>
>> Normalmente se usa la validacion del lado del servidor. La del cliente,
>> es
>> solo para darle "color" a tu aplicacion. Es para darle dinamismo, pero
> esto
>> no te asegura que te salves de los problemas.
> si la validacion cliente solo vale para dar "color" y "dinamismo" a la
> aplicacion y debemos sea lo que sea usar una "validacion servidor". ¿no

se

> podria evitar la validacion cliente? es decir: si valido del lado

servidor

> y
> me vale, ¿porque debo validar del lado cliente? quiza vayas a pensar que
> te
> hago una pregunta a partir de una respuesta que me acabas de dar,
> entonces,
> ¿me puedes explicar eso de "dinamismo" y "color"?
>
>> Cuando validas en el cliente, lo haces con un lenguaje, cuando lo haces
>> en
>> el server lo haces en otro. Asi que posiblemente la sintaxis no sea la
>> misma, pero la logica puede que si. De cualquier manera, si haces
> referencia
>> a la reutilidad del codigo, pues creo que no habia casi ninguna, en el
> caso
>> de que uses distintos lenguajes.
> el que tu me hables de reutilidad de codigo entre lenguajes distintos en
> cliente y servidor, significa que supones que se van a desarrollar de

cada

> lado funciones equivalentes en esos distintos lenguajes, ¿es asi?
> ademas, pienso que es perfectamente factible que un programador

desarrolle

> todo en JavaScript, tanto del lado cliente como servidor por lo que en
> este
> caso la reutilidad seria total, ¿que crees?
>
>> Si lo haces en el cliente:
>>
>> <script>
>> function Validar()
>> {
>> if .
>> {
>> //Si cumple
>> return true;
>> }
>> else
>> {
>> return false;
>> }
>> }
>> </script>
>>
>> <form onSubmit="return Validar()">
> aqui se llama a la funcion "validar". el submit por lo que veo solo
> permite
> llamar a una funcion y no a varias sucesivas. en este caso, parece ser

que

> solo se trata de validar a un textbox, digamos el A, ¿que pasa con el 2º
> textbox?
> supongo y corrigeme si me confundo que la funcion "validar" debera

llamar

> cada funcion que valide cada campo (son validaciones distintas) para
> devolver un resultado booleano global. si al menos 1 de los 2 textbox
> devuelven el valor false, sera el valor devuelto en e submit por la
> funcion
> de validacion global ¿es asi?
>
>> Si, al tener que procesar los datos en el servidor, deberias escribir
>> HTML
>> desde el servidor al lado de cada control o donde quieras.
>> Aunque, como te comentaba antes, el ir de una pagina a otra hara que
> tengas
>> que trabajar mas con el manejo de los errores. Es mejor que toda esa
> logica
>> la pongas en una unica pagina.
> eso si. ninguna pega con eso. es mejor que una pagina se llame a si

misma

> que llamar una pagina transparente, es decir sin codigo HTML y compuesta
> unicamente de codigo ASP y VBScript.
>
>
> de todas formas, te voy a hacer la pregunta directamente aplicada a mi
> problema que seguramente encontraras muy simple: tengo un formulario de
> registro de clientes que contiene 3 tipos de informacion: contacto,

datos

> de
> entrega, datos de facturacion. ¿como harias tu la validacion?
>
> muchas gracias por tu ayuda
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>