3 ms·

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 fo

by akamaka 17y ago

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. Has anyone looked into this?

stan_rogers 17y ago
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.
- akamaka 17y ago
  I should have been more clear, sorry. 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.
  - apsurd 17y ago
    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.
  - roryokane 17y ago
    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_validation 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.)
    - akamaka 17y ago
      Thanks for pointing me to this plugin.
  - trezor 17y ago
    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.
    - akamaka 17y ago
      Thanks for the helpful response, I haven't worked with ASP.net, and wasn't aware of this!
pmjordan 17y ago
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...
arebop 17y ago
Many people have thought about it, but I haven't heard of any solid implementations other than possibly the RoR client-side validation plugin mentioned by roryokane [http://news.ycombinator.com/item?id=635997 http://news.ycombinator.com/item?id=635997]. A recent article in CACM describes a promising approach with less promising syntax: http://portal.acm.org/citation.cfm?doid=1461928.1461949 http://portal.acm.org/citation.cfm?doid=1461928.1461949
- akamaka 17y ago
  Neat, thanks for the link.

by akamaka 17y ago

stan_rogers 17y ago

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.

akamaka 17y ago
I should have been more clear, sorry. 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.
- apsurd 17y ago
  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.
- roryokane 17y ago
  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_validation 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.)
  - akamaka 17y ago
    Thanks for pointing me to this plugin.
- trezor 17y ago
  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.
  - akamaka 17y ago
    Thanks for the helpful response, I haven't worked with ASP.net, and wasn't aware of this!

pmjordan 17y ago

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...

arebop 17y ago

Many people have thought about it, but I haven't heard of any solid implementations other than possibly the RoR client-side validation plugin mentioned by roryokane [http://news.ycombinator.com/item?id=635997 http://news.ycombinator.com/item?id=635997]. A recent article in CACM describes a promising approach with less promising syntax: http://portal.acm.org/citation.cfm?doid=1461928.1461949 http://portal.acm.org/citation.cfm?doid=1461928.1461949

akamaka 17y ago
Neat, thanks for the link.