Also, this isn't mine at all. Just found it on Reddit's web_design and thought somebody here would find it interesting. I was just rewriting a web form where I did my own inline validation.
You can't trust anything that is done on the user's end regardless of what they have enabled. Something like this is just a bonus from a usability prospective because the user won't have to wait until they hit submit to find out they made a mistake.
100% right, and what I'm curious about how the validation requirements are specified. Surely you wouldn't want to do it twice, once for the server and again for the client.
A lot of people have "looked into this" (Jakob Nielsen among them), and the only reasonable conclusion is that yes, you want to do it twice.
What happens in the browser cannot be called "real" validation, but if a user has to wait thirty seconds to be told that they've forgotten a field or entered invalid data, you can usually count on one fewer user. In the wild, that can mean a lost customer; in captivity, it means that user communities will skirt the corporate tools in favour of tools tha work for them.
On the other hand, there are ways around in-browser validation, some innocent (such as having JS disabled, which also implies that a jQuery-based app probably wouldn't work well at all), and some a little more sinister and deliberate, so omitting server-side, "true" validation is not an option.
Yes, validation always needs to be done on the server side. What I'm wondering is if tools exist for automatically generating the client-side validation from the same rules that have been specified on the server side. If one were to use the JQuery-based tool that the article submitter created, you'd have double the work, and making changes would risk introducing inconsistancies.
I think most of us just accept "double the work" because it's better for the user. Instant error/success messages skyrocket the usability of an app, and as mentioned here before, yslow tells us that app speed is frequently relative to front-end perception rather than actual server-side bottlenecks. I.E. a website that instantly responds to your input is "faster" than one than doesn't, even if its doing twice the work.
Most validation is just a bunch of regex, so you can minimize inconsistencies by making sure the expressions are equivalent.
Yes, there is at least one tool that does this. There is a Ruby on Rails plugin called Client-Side Validation. It generates client-side Javascript validation based on the existing validation in the model, which the server already checks against. You can find it here: http://agilewebdevelopment.com/plugins/client_side_validatio.... I haven't tried it myself, so I can't vouch for how well it works. There also may be other, newer libraries for doing this out there.
I certainly agree that elimination of this repetition would be very helpful when developing websites. If the code can be generated automatically for you, there are very few situations where you wouldn't want client-side as well as server-side validation. (Some of those few situations might include expecting the user to have a computer too slow for Javascript or being unable to expose the validation method to the user for security reasons.)
Regular ASP.Net gives you this trough server-side validation controls, which is up to you to embed in your forms. This generates client-side Javascript with visual feedback for the user, where you are to some extent in control how the results will look.
If you tune up your ASP.Net to go include Enterprise Library you can use simple "proxy validation controls" which infers validation rules from attributes/annotations added to your base entity-classes. This again bleeds to the client-side allowing you to set validation rules once and only once. Even programmatic violation of these rules will result in errors. While rather enterprisey to work with, it is rather neat on a technical level.
I'd be surprised if you can't do the same with Java. If you are however stuck with some ghetto PHP framework chances are yes, you will have to double or tripple your validation-logic because the language is simply too lacking to allow for complex runtime reflection based auto-generated sub-classes based on class metadata.
Generating JavaScript isn't hard, so if you're using a lot of forms that require validation, it should be pretty straightforward to generate JavaScript and back-end validators from the same description. Still, you have to use some ruleset and hope it covers all your cases, etc.
If you only have 1 or 2 forms, it's probably just easier to do it manually...
The email address validation is overly restrictive. Valid email addresses can contain + and other characters.
So if I wanna use an email adress like myname+keyword@gmail.com it gets flagged as invalid by the script.
(I use it to do filtering based on the +keyword in gmail)
18 comments
[ 3.0 ms ] story [ 27.8 ms ] threadSeeing as you've already written a write up on your blog, why not point to that instead?.
http://www.position-absolute.com/articles/jquery-form-valida...
Also, this isn't mine at all. Just found it on Reddit's web_design and thought somebody here would find it interesting. I was just rewriting a web form where I did my own inline validation.
Shouldn't a complete solution automatically fall back to server-side validation?
Has anyone looked into this?
What happens in the browser cannot be called "real" validation, but if a user has to wait thirty seconds to be told that they've forgotten a field or entered invalid data, you can usually count on one fewer user. In the wild, that can mean a lost customer; in captivity, it means that user communities will skirt the corporate tools in favour of tools tha work for them.
On the other hand, there are ways around in-browser validation, some innocent (such as having JS disabled, which also implies that a jQuery-based app probably wouldn't work well at all), and some a little more sinister and deliberate, so omitting server-side, "true" validation is not an option.
Yes, validation always needs to be done on the server side. What I'm wondering is if tools exist for automatically generating the client-side validation from the same rules that have been specified on the server side. If one were to use the JQuery-based tool that the article submitter created, you'd have double the work, and making changes would risk introducing inconsistancies.
Most validation is just a bunch of regex, so you can minimize inconsistencies by making sure the expressions are equivalent.
I certainly agree that elimination of this repetition would be very helpful when developing websites. If the code can be generated automatically for you, there are very few situations where you wouldn't want client-side as well as server-side validation. (Some of those few situations might include expecting the user to have a computer too slow for Javascript or being unable to expose the validation method to the user for security reasons.)
If you tune up your ASP.Net to go include Enterprise Library you can use simple "proxy validation controls" which infers validation rules from attributes/annotations added to your base entity-classes. This again bleeds to the client-side allowing you to set validation rules once and only once. Even programmatic violation of these rules will result in errors. While rather enterprisey to work with, it is rather neat on a technical level.
I'd be surprised if you can't do the same with Java. If you are however stuck with some ghetto PHP framework chances are yes, you will have to double or tripple your validation-logic because the language is simply too lacking to allow for complex runtime reflection based auto-generated sub-classes based on class metadata.
If you only have 1 or 2 forms, it's probably just easier to do it manually...