Why validation on server side

hi,

i have noticed that the validations in RoR happen at server side

mostly what sites do is using javascript they validate user information
there…

whats the point of doing it at the server side

is it that loading of javascript file in a browser makes a response to
client slow
and validation at server side offsets that…???

any sugeestions???

is it that i am missing something as mostly till now i have developed in
development mode???

its not long i am coding in RoR a few months old…

warm regards
gaurav v bagga

gaurav bagga wrote:

hi,

i have noticed that the validations in RoR happen at server side

mostly what sites do is using javascript they validate user information
there…

whats the point of doing it at the server side

is it that loading of javascript file in a browser makes a response to
client slow
and validation at server side offsets that…???

any sugeestions???

is it that i am missing something as mostly till now i have developed in
development mode???

its not long i am coding in RoR a few months old…

warm regards
gaurav v bagga

One big reason you would want to do server side validations is because
the validations may require lookups in a database. Another reason is
that the user can always disable javascript and submit bad data if you
do all your validations via javascript, whereas there is no way to get
around server side validations.

-Tom

Tom wrote:

Another reason is
that the user can always disable javascript and submit bad data if you
do all your validations via javascript, whereas there is no way to get
around server side validations.

You should always validate on the server. Client-side validation is a
progressive enhancement that saves the user a server roundtrip and a
page load. But it never replaces server-ide validation.


Austin

Server side validation is essential. A combination of client-side and
server-side validation is not DRY.

Peter

thank u all for ur replies

they certainly cleared my doubts

gaurav bagga wrote:

thank u all for ur replies

they certainly cleared my doubts

No no no. Now you go and write a plugin to take the validates_* methods
and generates useful javascript into the views to automatically add
client-side validation.

Be a champ.

I totally agree. Server-side validation is the minimum and should be the
standard requirement for validation. Any client-side validation should
only
be considered to enhance the user experience, and shouldn’t be trusted
for
“real” validation. For example, what if the client has javascript turned
off?

-Mike

On 7/21/06, Peter M. [email protected] wrote:

Server side validation is essential. A combination of client-side and
server-side validation is not DRY.

But client-side validation is still very useful. In the Java world
Struts will automatically generate the JavaScript that you need for
the built-in validations. You define how you want to validate once in
an XML file and then it’s handled automatically in your server-side
code as well as on the client.

It’s certainly not without its problems, but it’s a pretty cool system
that maybe could be learned from.

http://struts.apache.org/1.2.4/userGuide/dev_validator.html

– James

On 21 Jul 2006 15:03:43 -0000, Kevin O.
[email protected] wrote:

code as well as on the client.

It’s certainly not without its problems, but it’s a pretty cool system
that maybe could be learned from.

http://struts.apache.org/1.2.4/userGuide/dev_validator.html

This approach will fail when you need to do custom validations. That
would require you to write a client side and server side validation and
then make sure they both work the same. Certainly not very DRY.

Ajax could be used to ‘enhance’ the user experience by flagging
validation problems before the form is submitted.

Yes and no. If you write a custom “validation” then you will have to
be un-DRY, like you said. However, if you write a custom “validator”
that knows how to generate the JavaScript just like the built-in
validators then it’s nearly DRY. You could argue that creating a
generator for the JavaScript and implementing the Java for the
server-side piece is duplicating work.

Usually, however, the way it works out is that the kinds of
validations where you would be writing custom code need something else
from the server (like a database hit), so you simply skip the
client-side code.

Please don’t take this as me thinking that Struts is a panacea. I’ve
seen some horrifying Struts abuses involving validations and custom
JavaScript. But the potential is still there for someone to use it
correctly.

– James

On Friday, July 21, 2006, at 10:20 AM, James L. wrote:

the built-in validations. You define how you want to validate once in
would require you to write a client side and server side validation and
server-side piece is duplicating work.

– James


Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

I can see how it could be useful, so long as people are aware of it’s
limitations. One would have to ensure that the validations worked on
both the client and the server for each database type, otherwise you may
get wierd conditions where the client may pass an entry and the database
will complain. That would get confusing for the user.

_Kevin
www.sciwerks.com

On Friday, July 21, 2006, at 9:20 AM, James L. wrote:

It’s certainly not without its problems, but it’s a pretty cool system
that maybe could be learned from.

http://struts.apache.org/1.2.4/userGuide/dev_validator.html

– James


Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

This approach will fail when you need to do custom validations. That
would require you to write a client side and server side validation and
then make sure they both work the same. Certainly not very DRY.

Ajax could be used to ‘enhance’ the user experience by flagging
validation problems before the form is submitted.

_Kevin
www.sciwerks.com