client side only validations #428

Closed
ansel1 opened this Issue Nov 6, 2012 · 6 comments

Comments

Projects
None yet
3 participants
@ansel1

ansel1 commented Nov 6, 2012

I keep hitting cases where I want to add client-only validations. I was banging my head against this for a bit, but it occurred to me, I could just override client_side_validation_hash, merging additional values into the hash produced by super. Is that kosher?

To clarify, a couple cases I have are validations I only want to exercise when a user is going through the web site, vs native clients going through the json api. Another are validation methods (i.e. validates :some_field_matches_another). I could turn them into EachValidators, but that's a lot of overhead, especially when many are one-offs for a particular class.

Anyway, is this an approach that makes sense?

@bcardarella

This comment has been minimized.

Show comment Hide comment
@bcardarella

bcardarella Nov 6, 2012

Contributor

I generally tell people not to do client-only validations. Client validations give a false sense of security with the data being entered in. If you cannot model the validation properly on the server it shouldn't be modeled on the client.

That being said, I'd like to hear more about your use-cases.

Contributor

bcardarella commented Nov 6, 2012

I generally tell people not to do client-only validations. Client validations give a false sense of security with the data being entered in. If you cannot model the validation properly on the server it shouldn't be modeled on the client.

That being said, I'd like to hear more about your use-cases.

@ansel1

This comment has been minimized.

Show comment Hide comment
@ansel1

ansel1 Nov 6, 2012

Use case 1: password change form. fields: current, new, confirm new. First, I feel like confirmation of passwords is really a validation only needed when dealing with humans, and so only really needed in the client tier. confirming a password is not a matter keeping the model uncorrupted, which is the primary value of model tier validations...but I get that's a personal opinion :). Anyway, in my case, we do the password confirmation on the client side, then do hashing in javascript, and send results back in hidden fields. We clear out the actual password and confirmation fields on the client to ensure the server never sees the real password. Having more control over what validations happen client side vs server side would have made this a bit easier.

Use case 2: Same form. Need to confirm the current password. On the server, we use a simple validates :check_current_password method. It would be more lines of code to turn that into an EachValidator instance, which appears to be what is needed to create a custom client side validation. For a one off like this, it seems like it would be acceptable to skirt the requirement for the separate validator class.

Use case 3: less of an issue for me right now, but it would be nice to reuse the client side validation code for fields in forms which are based on models. Our login form, for example, is not backed by a model (primarily because, as with the password change form, we mostly manipulate the values on the client side, then send the results of the processing back in hidden fields. Anyway, for DRY reasons, seems like I should be able to apply your perfectly good client validation code instead of rolling my own.

ansel1 commented Nov 6, 2012

Use case 1: password change form. fields: current, new, confirm new. First, I feel like confirmation of passwords is really a validation only needed when dealing with humans, and so only really needed in the client tier. confirming a password is not a matter keeping the model uncorrupted, which is the primary value of model tier validations...but I get that's a personal opinion :). Anyway, in my case, we do the password confirmation on the client side, then do hashing in javascript, and send results back in hidden fields. We clear out the actual password and confirmation fields on the client to ensure the server never sees the real password. Having more control over what validations happen client side vs server side would have made this a bit easier.

Use case 2: Same form. Need to confirm the current password. On the server, we use a simple validates :check_current_password method. It would be more lines of code to turn that into an EachValidator instance, which appears to be what is needed to create a custom client side validation. For a one off like this, it seems like it would be acceptable to skirt the requirement for the separate validator class.

Use case 3: less of an issue for me right now, but it would be nice to reuse the client side validation code for fields in forms which are based on models. Our login form, for example, is not backed by a model (primarily because, as with the password change form, we mostly manipulate the values on the client side, then send the results of the processing back in hidden fields. Anyway, for DRY reasons, seems like I should be able to apply your perfectly good client validation code instead of rolling my own.

@bcardarella

This comment has been minimized.

Show comment Hide comment
@bcardarella

bcardarella Nov 6, 2012

Contributor

I'm am pretty sure all of your use cases could be worked around with conditional validators

Contributor

bcardarella commented Nov 6, 2012

I'm am pretty sure all of your use cases could be worked around with conditional validators

@ansel1

This comment has been minimized.

Show comment Hide comment
@ansel1

ansel1 Nov 6, 2012

Well, yes. But mainly conditionals designed to ensure the validation only
runs client side. It's a roundabout way to get what I want, vs just
explicitly expressing "only run this client side".

I guess that's only one of the cases. The case of the method validators is
I guess just wanting a way to do client side validators for validators
types other than EachValidators. Not a big deal to go with the flow on
those and convert them.

On Nov 5, 2012, at 10:26 PM, Brian Cardarella notifications@github.com
wrote:

I'm am pretty sure all of your use cases could be worked around with
conditional validators


Reply to this email directly or view it on
GitHubhttps://github.com/bcardarella/client_side_validations/issues/428#issuecomment-10097987.

ansel1 commented Nov 6, 2012

Well, yes. But mainly conditionals designed to ensure the validation only
runs client side. It's a roundabout way to get what I want, vs just
explicitly expressing "only run this client side".

I guess that's only one of the cases. The case of the method validators is
I guess just wanting a way to do client side validators for validators
types other than EachValidators. Not a big deal to go with the flow on
those and convert them.

On Nov 5, 2012, at 10:26 PM, Brian Cardarella notifications@github.com
wrote:

I'm am pretty sure all of your use cases could be worked around with
conditional validators


Reply to this email directly or view it on
GitHubhttps://github.com/bcardarella/client_side_validations/issues/428#issuecomment-10097987.

@bcardarella

This comment has been minimized.

Show comment Hide comment
@bcardarella

bcardarella Nov 6, 2012

Contributor

Cool, sounds like you have a good handle on this. I'm going to close out

Contributor

bcardarella commented Nov 6, 2012

Cool, sounds like you have a good handle on this. I'm going to close out

@bcardarella bcardarella closed this Nov 6, 2012

@dinatih

This comment has been minimized.

Show comment Hide comment
@dinatih

dinatih Mar 8, 2013

Hello, I am in the same situation, I have a form with fields that generate data
(they permit to fill in the next fields automatically, ex: field3 = (fields1 + field2) / 0.8; with field1 and field2 not needed for business, but only for facilitate the user)
for the model but this fields need to existe only on the generator page,
the generator is all in js on client side
and I really would like to use your error management system for Rails Model attributes and pure JS fields that generate data for Model without the need to had a boolean on rails Model for checking in conditional validation on Model.

I think that with the emergence of multiple device size, a lot of work could be done on client side only with virtual attributes that generate the data for model (for example in hidden field or in my case normal fields that can be modified if the suggestion made by the generator is not good).

Ps: Sorry for my approximative english...

dinatih commented Mar 8, 2013

Hello, I am in the same situation, I have a form with fields that generate data
(they permit to fill in the next fields automatically, ex: field3 = (fields1 + field2) / 0.8; with field1 and field2 not needed for business, but only for facilitate the user)
for the model but this fields need to existe only on the generator page,
the generator is all in js on client side
and I really would like to use your error management system for Rails Model attributes and pure JS fields that generate data for Model without the need to had a boolean on rails Model for checking in conditional validation on Model.

I think that with the emergence of multiple device size, a lot of work could be done on client side only with virtual attributes that generate the data for model (for example in hidden field or in my case normal fields that can be modified if the suggestion made by the generator is not good).

Ps: Sorry for my approximative english...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment