41 ms·

I run into this all the time. The most common case is form validation. If you want to do some validation on the client side, why are you forced to repeat yourse

I run into this all the time. The most common case is form validation. If you want to do some validation on the client side, why are you forced to repeat yourself by writing it once in Java/Ruby/Python/Perl/PHP on the server and then write it again on the client using Javascript/Underscore/JQuery/whatever? http://github.com/raganwald/homoiconic/blob/master/2010/02/difficult_distraction.md http://github.com/raganwald/homoiconic/blob/master/2010/02/d...

planettrash 17y ago
A concern might be that you expose your server side code. Though many os projects do this by design.
- Hexstream 17y ago
  Not necessarily, you can make a really high-level DSL to express validation rules, that encompasses both client-side and server-side logic, and then you generate the client-side-only validations from this model while not including the server-side, "secret" validation code.
daveungerer 17y ago
Could it be that your form validation example is merely a symptom of not working at a high enough level of abstraction? In the rails world, for example, if you've done your validates_* declarations on an ActiveRecord model, it shouldn't be too difficult to generate the javascript required for client-side validation. Actually found a project that goes a long way towards achieving just that: http://github.com/grimen/validatious-on-rails http://github.com/grimen/validatious-on-rails But I guess you're referring to complex validations, expressed as code instead of validates_* declarations. It seems like you would prefer either an all-JS approach or an automated translation to JS, as per the blog post you linked. To me, it boils down to whether such a complicated validation is really appropriate for client-side validation and whether it blurs the lines between form validation and business logic to such an extent that it's better off just living on the server. But I'd love to hear your further thoughts on the matter.

planettrash 17y ago

A concern might be that you expose your server side code. Though many os projects do this by design.

Hexstream 17y ago
Not necessarily, you can make a really high-level DSL to express validation rules, that encompasses both client-side and server-side logic, and then you generate the client-side-only validations from this model while not including the server-side, "secret" validation code.

daveungerer 17y ago

Could it be that your form validation example is merely a symptom of not working at a high enough level of abstraction? In the rails world, for example, if you've done your validates_* declarations on an ActiveRecord model, it shouldn't be too difficult to generate the javascript required for client-side validation. Actually found a project that goes a long way towards achieving just that: http://github.com/grimen/validatious-on-rails http://github.com/grimen/validatious-on-rails But I guess you're referring to complex validations, expressed as code instead of validates_* declarations. It seems like you would prefer either an all-JS approach or an automated translation to JS, as per the blog post you linked. To me, it boils down to whether such a complicated validation is really appropriate for client-side validation and whether it blurs the lines between form validation and business logic to such an extent that it's better off just living on the server. But I'd love to hear your further thoughts on the matter.