Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
client side only validations #428
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.
Anyway, is this an approach that makes sense?
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.
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.
Well, yes. But mainly conditionals designed to ensure the validation only
I guess that's only one of the cases. The case of the method validators is
On Nov 5, 2012, at 10:26 PM, Brian Cardarella firstname.lastname@example.org
I'm am pretty sure all of your use cases could be worked around with
This comment has been minimized.
This comment has been minimized.Show comment Hide comment
Hello, I am in the same situation, I have a form with fields that generate data
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...