Is there a summary anywhere of data entry form validation techniques for
Rails apps? I''ve come across lots of snippets of advice but they are
all
so far-flung that it''s hard to sit down and organize an approach. The
kind of thing I''m looking for would be a simple list with entries like:
validates_presence_of
1. simplest: Make sure your table model contains a line like
validates_presence_of :LoanID, :message => "is missing"
This will catch the error after the form is submitted by the user.
2. Use JavaScript to check for null in this field (onchange ?)
3. Use DrySQL... (when does this catch the error?)
4. Others?
In other words, I''d like to see a summary of techniques for each type
of
validation that can be applied to a data entry field. Then I (or the
rest of you!) will be able to pick and choose among the techniques which
are best for the particular situations at hand.
Maybe a full discussion of this calls for an article or even a whole
book, but all I''m looking for is a summary to help me decide among
techniques. The list would serve as a starting point for further
research into the techniques that seem best.
Can anyone help with this?
Shauna
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
Hello Shauna,> Is there a summary anywhere of data entry form validation > techniques for Rails apps? I've come across lots of snippets of > advice but they are all so far-flung that it's hard to sit down and > organize an approach. The kind of thing I'm looking for would > be a simple list with entries like: > > validates_presence_of > 1. simplest: Make sure your table model contains a line like > validates_presence_of :LoanID, :message => "is missing" > This will catch the error after the form is submitted by the user. > 2. Use JavaScript to check for null in this field (onchange ?) > 3. Use DrySQL... (when does this catch the error?) > 4. Others?I don't know much about DrySQL, but I'm sorry to say your approach doesn't make sense. Validation rules must be part of your model, so use Rails validations or customized validations. Keep in mind that your datas can be used through web clients or other means : WebServices, REST api... So imagine that you decide to do only JavaScript checks on the client side (let's keep away the JS disactivation pb), without using rails validations, what will happen if you corrupt your datas, say during a migration ? So use Rails validations, then decide if you want client-side validation with JS to improve the client experience.> In other words, I'd like to see a summary of techniques for > each type of validation that can be applied to a data entry field. > Then I (or the rest of you!) will be able to pick and choose > among the techniques which are best for the particular > situations at hand.I don't think such a summary exist. You can't trust client side validation. Do your server-side validations, add if needy client-side (JS) validation/checking. Just my 2 cents, -- Jean-François. -- À la renverse. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks, Jean-François, the client-side vs. server-side issue was on my mind and your reply helps. (I haven''t tried DrySQL yet - just got that info from the author''s blog but he claims that DrySQL "automatically generates validations for ActiveRecord data classes that enforce the constraints declared on your DB"). http://allyourdatabase.blogspot.com/search/label/ruby-smalltalk>So use Rails validations, then decide if you want client-side >validation with JS to improve the client experience.Yes, thanks for the reminder. In addition to Rails validations, I need to make up on-line forms that are as robust as our desktop version. Waiting until the whole form is submitted to check all the fields is unacceptable, and running back to the server for every field entered seems extreme. So I''d like to do some combination of client-side (for the simpler things like "is it blank when it shouldn''t be?") and server-side (like "does this Loan name already exist?). I can divide up some forms so that crucial identifying fields are collected separately first, then if all that passes muster the rest of the fields are presented. But what I really want to have is some awareness and comparison of what techniques are out there, and if there are different techniques available for different types of validation or types of input fields (like radio buttons or drop-down lists). I''ve googled around but such info is really scattered and it''s hard to get a handle on what the choices are, let alone how to compare them! I''ve read that DHTML is unreliable, but unreliable in what way? What are the consequences of using it? Is it just that it doesn''t work the same way on all browsers, or that even on one browser it doesn''t always catch the error, or what? Is there any more summary info on validations? Thanks, Shauna -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Teehee. She said DHTML. Where're my bell-bottoms? Seriously though, relying on JavaScript methods without providing alternate methods of getting things done [for those who have JS disabled, etc] is the biggest concern. You've got to make a call on exactly how important that is to you. Not to call anybody out but I noticed that even Backpack disables some functionality when you turn off JS. Most of their users _probably_ wouldn't do something that strange but they might for your app. That [plus the differences between DOM structures and JS functions between browsers] would be the main worry I'd have. As far as simple validation goes. Sure, use JS to validate it on the client-side. If they're not using it then make sure the model validates it as well. I wouldn't assume the user is JS-enabled. Not when there's so safe and sure a client-side solution. RSL On 2/15/07, Shauna <rails-mailing-list@andreas-s.net> wrote:> > > Thanks, Jean-François, the client-side vs. server-side issue was on my > mind and your reply helps. (I haven't tried DrySQL yet - just got that > info from the author's blog but he claims that DrySQL "automatically > generates validations for ActiveRecord data classes that enforce the > constraints declared on your DB"). > http://allyourdatabase.blogspot.com/search/label/ruby-smalltalk > > >So use Rails validations, then decide if you want client-side > >validation with JS to improve the client experience. > > Yes, thanks for the reminder. In addition to Rails validations, I need > to make up on-line forms that are as robust as our desktop version. > Waiting until the whole form is submitted to check all the fields is > unacceptable, and running back to the server for every field entered > seems extreme. So I'd like to do some combination of client-side (for > the simpler things like "is it blank when it shouldn't be?") and > server-side (like "does this Loan name already exist?). I can divide up > some forms so that crucial identifying fields are collected separately > first, then if all that passes muster the rest of the fields are > presented. > > But what I really want to have is some awareness and comparison of what > techniques are out there, and if there are different techniques > available for different types of validation or types of input fields > (like radio buttons or drop-down lists). I've googled around but such > info is really scattered and it's hard to get a handle on what the > choices are, let alone how to compare them! > > I've read that DHTML is unreliable, but unreliable in what way? What are > the consequences of using it? Is it just that it doesn't work the same > way on all browsers, or that even on one browser it doesn't always catch > the error, or what? > > Is there any more summary info on validations? > > Thanks, > Shauna > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---