Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Allow input on validation fail with warning or fuzzy validation. #16

Closed
konung opened this Issue Mar 25, 2011 · 2 comments

Comments

Projects
None yet
2 participants

konung commented Mar 25, 2011

Hi, Brian.

Been playing with the new releases and everything seems to be kosher . (By the way - no issues under FF 4 so far) however I'm back with a new idea :-)

I guess this is a feature request. Sometimes there are situations where user input doesn't necessarily pass part of your validation but can still be legitimate input. You want to be able to let the form be able to be submitted but let a user know that it is potentially invalid or mistyped input, so they check it twice.

This is from a real life app I worked on a while back, and it can serve as a great example. There was a vehicle parts order table, where users were required to provide a VIN number of the vehicle. Unfortunately the VIN db that we used to verify the VIN numbers would only hold 3 years worth of VIN numbers. We had to verify against that external service (customer requirement), however if the vehicle was older than 3 years it was mostly like not in the DB, while still having a legitimate VIN number. So in that case we would verify requirements like "17 alphanumeric characters long" but since we couldn't verify the actual existence of a VIN, we would use some javascript voodoo to pop a warning for them on field blur to make sure they verify the number (actually a little yellow div that asked them politely to verify the number was typed in correctly since it wasn't in our records)

Another example is if you want users to provide full legal names, but most people tend to submit things like Mike vs Michael, and you want to emphasize it to them that it's valid input but you want them to verify that it's their legal name. Sort of a fuzzy validation (tm) :-)

I'm sure there are other situations where it would be useful to let through a form that passes some validation but fails some more obscure ones with a warning. Or allow validations that would be "nice to pass". What do you think about it?

One more thing - what if your validation depends on external service that happens to be down. You may still want to be able to process the form even if it fails validating against that service.

Once again thanks for a great gem.
Nick

Contributor

bcardarella commented Mar 25, 2011

Hey Nick,

So this feels like something you can accomplish with the callbacks https://github.com/bcardarella/client_side_validations/wiki/Callbacks

For example, you could override the clientSideValidations.elementValidatePass callback to detect if the current element is this VIN element, then display the necessary pop up. This won't prevent form submission but you could attach a flag to the element then add another submit event to the form that detects this flag. It prevents submission the first time it detects the flag then allows the 2nd.

In short, this type of behavior won't be abstracted for ClientSideValidations. The goal is to model the server-side validations as best possible, in the case it doesn't make sense to do so it allows submission to let the server do problem validation.

I hope that helps! :)

konung commented Mar 25, 2011

I see. You are right, it can be accomplished with callbacks it seems.

Not something I need right now - just something I was thinking about.

Thanks

On Fri, Mar 25, 2011 at 2:31 PM, bcardarella <
reply@reply.github.com>wrote:

Hey Nick,

So this feels like something you can accomplish with the callbacks
https://github.com/bcardarella/client_side_validations/wiki/Callbacks

For example, you could override the
clientSideValidations.elementValidatePass callback to detect if the current
element is this VIN element, then display the necessary pop up. This won't
prevent form submission but you could attach a flag to the element then add
another submit event to the form that detects this flag. It prevents
submission the first time it detects the flag then allows the 2nd.

In short, this type of behavior won't be abstracted for
ClientSideValidations. The goal is to model the server-side validations as
best possible, in the case it doesn't make sense to do so it allows
submission to let the server do problem validation.

I hope that helps! :)

Reply to this email directly or view it on GitHub:

bcardarella#16 (comment)


Nick Gorbikoff
nick.gorbikoff@gmail.com

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