I''m not fond of Rails'' style of validation where one rule is followed by many fields. Trying to determine the rules of any one field is rather tedious with this setup. I''d rather have one field, followed by many rules. Anyone know if someone has already written something to do it that way? If not, I think I''ll take a crack at it. It would likely look something like this: validates_field ''field_name'', :isRequired, :isAlphaNumeric, :hasMaxLength => 10 Which would ultimately just translate and inject definitions into Rails'' existing internal structure, but at least I can read it field by field (and with a number of explicit easier-to-read keywords I''ll borrow from my past work). -- gw (www.railsdev.ws) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Greg Willits wrote:> I''m not fond of Rails'' style of validation where one rule is followed > by many fields. > > Trying to determine the rules of any one field is rather tedious with > this setup. > > I''d rather have one field, followed by many rules. > > Anyone know if someone has already written something to do it that > way? If not, I think I''ll take a crack at it. It would likely look > something like this: > > validates_field > ''field_name'', :isRequired, :isAlphaNumeric, :hasMaxLength => 10 > > Which would ultimately just translate and inject definitions into > Rails'' existing internal structure, but at least I can read it field > by field (and with a number of explicit easier-to-read keywords I''ll > borrow from my past work).If all you want is greater readability, just arrange your validations by field. Here''s an example: validates_presence_of :email validates_length_of :email, :in => (6..255) validates_format_of :email, :with => VALID_EMAIL_REGEXP validates_uniqueness_of :email # used for unique login identifier validates_length_of :handle, :allow_nil => true, :minimum => 3 validates_format_of :handle, :allow_nil => true, :with => /\w+/ validates_uniqueness_of :handle, :allow_nil => true validates_confirmation_of :password (Seeing it that way, I really get the idea that :allow_nil should be the default.) -- Josh Susser http://blog.hasmanythrough.com -- 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 -~----------~----~----~----~------~----~------~--~---
On Nov 25, 2007, at 12:13 PM, Josh Susser wrote:> Greg Willits wrote: >> I''m not fond of Rails'' style of validation where one rule is followed >> by many fields. >> >> Trying to determine the rules of any one field is rather tedious with >> this setup. >> >> I''d rather have one field, followed by many rules. >> >> Anyone know if someone has already written something to do it that >> way? If not, I think I''ll take a crack at it. It would likely look >> something like this: >> >> validates_field >> ''field_name'', :isRequired, :isAlphaNumeric, :hasMaxLength => 10 >> >> Which would ultimately just translate and inject definitions into >> Rails'' existing internal structure, but at least I can read it field >> by field (and with a number of explicit easier-to-read keywords I''ll >> borrow from my past work). > > If all you want is greater readability, just arrange your > validations by > field. > > Here''s an example: > > validates_presence_of :email > validates_length_of :email, :in => (6..255) > validates_format_of :email, :with => VALID_EMAIL_REGEXP > validates_uniqueness_of :email # used for unique login > identifier > > validates_length_of :handle, :allow_nil => true, :minimum > => 3 > validates_format_of :handle, :allow_nil => true, :with => > /\w+/ > validates_uniqueness_of :handle, :allow_nil => true > > validates_confirmation_of :password > > (Seeing it that way, I really get the idea that :allow_nil should > be the > default.)Yeaaah, but it''s not the same. Not as compact. validates_field ''email'', :isRequired, :hasLength=> (6..255), :isEmail, :isUnique validates_field ''handle'', :hasMinLength=>3, :isUnique, :isAlphaUnderscore validates_field ''password'', :isPassword This is how I did validations in my own framework. I have a bunch of common isX & hasX and then of course the type of regex options that Rails depends on as well. It looks more cramped in email than in code, but I find it fairly quick to read and write (and with predefined formats, there''s far less regex to trip over). This is probably going to be my first crack at a plugin, but I''m going to have to figure out how to translates to and inject into Rails'' native storage for validations. -- gw (www.railsdev.ws) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Nov 25, 12:38 pm, Greg Willits <li...-0Bv1hcaDFPRk211Z5VL+QA@public.gmane.org> wrote:> I''m not fond of Rails'' style of validation where one rule is followed > by many fields. > > Trying to determine the rules of any one field is rather tedious with > this setup. > > I''d rather have one field, followed by many rules. > ...Well, once ou use :format, there isn''t much need for any of the others, but... This took about ten minutes to write and test: #===Example # validates_field :some_field, :presence, :format => { :with => /w +/ }, :length => { :minimum => 3 } # # is equivalent to: # validates_presence_of :some_field # validates_format_of :some_field, :with => /w+/ # validates_length_of :some_field, :minimum => 3 # class ActiveRecord::Base def self.validates_field(field_name, *args) args.each do |arg| case arg when Hash arg.each do |key, value| self.send("validates_#{key}_of", field_name, value) end else self.send("validates_#{arg}_of", field_name) end end end --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Nov 25, 12:38 pm, Greg Willits <li...-0Bv1hcaDFPRk211Z5VL+QA@public.gmane.org> wrote:> I''m not fond of Rails'' style of validation where one rule is followed > by many fields. > > Trying to determine the rules of any one field is rather tedious with > this setup. > > I''d rather have one field, followed by many rules. > > Anyone know if someone has already written something to do it that > way? If not, I think I''ll take a crack at it. It would likely look > something like this: > > validates_field > ''field_name'', :isRequired, :isAlphaNumeric, :hasMaxLength => 10 > > Which would ultimately just translate and inject definitions into > Rails'' existing internal structure, but at least I can read it field > by field (and with a number of explicit easier-to-read keywords I''ll > borrow from my past work).Making up new keywords from your past work is fine if you are the only one who will have to read this code. But you will slow understanding for all the developers who read AWDWR and are familiar with the standard names. Also, your use of camelCase is non-standard and will make other Ruby programmers think you are just an unreformed Java hacker.> > -- gw (www.railsdev.ws)--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
@Greg: You can pretty much do whatever you want in Ruby, as countless plugins can prove. However, a major beneift to developing with Rails is that you have a standard domain-specific language provided already. I can look at three separate apps, made by three separate developers, and I can be up to speed with what they are doing really quickly provided they all followed the Rails conventions. I can''t do that with "Jim''s Custom PHP Framework." Don''t think of it as opinionated software - I hate that term. Consistancy, conformity, etc free me up to solve my clients'' problems. I could focus on writing a plugin or extention to make my code more pleasing to my eyes, but instead I choose to implement a new bit of functionality. The choice is yours, but if you do develop this new method of validation, I''d love to see it. Good luck! On Nov 26, 2007 12:37 AM, Greg Willits <lists-0Bv1hcaDFPRk211Z5VL+QA@public.gmane.org> wrote:> > On Nov 25, 2007, at 12:13 PM, Josh Susser wrote: > > Greg Willits wrote: > >> I''m not fond of Rails'' style of validation where one rule is followed > >> by many fields. > >> > >> Trying to determine the rules of any one field is rather tedious with > >> this setup. > >> > >> I''d rather have one field, followed by many rules. > >> > >> Anyone know if someone has already written something to do it that > >> way? If not, I think I''ll take a crack at it. It would likely look > >> something like this: > >> > >> validates_field > >> ''field_name'', :isRequired, :isAlphaNumeric, :hasMaxLength => 10 > >> > >> Which would ultimately just translate and inject definitions into > >> Rails'' existing internal structure, but at least I can read it field > >> by field (and with a number of explicit easier-to-read keywords I''ll > >> borrow from my past work). > > > > If all you want is greater readability, just arrange your > > validations by > > field. > > > > Here''s an example: > > > > validates_presence_of :email > > validates_length_of :email, :in => (6..255) > > validates_format_of :email, :with => VALID_EMAIL_REGEXP > > validates_uniqueness_of :email # used for unique login > > identifier > > > > validates_length_of :handle, :allow_nil => true, :minimum > > => 3 > > validates_format_of :handle, :allow_nil => true, :with => > > /\w+/ > > validates_uniqueness_of :handle, :allow_nil => true > > > > validates_confirmation_of :password > > > > (Seeing it that way, I really get the idea that :allow_nil should > > be the > > default.) > > > Yeaaah, but it''s not the same. Not as compact. > > validates_field ''email'', :isRequired, :hasLength=> > (6..255), :isEmail, :isUnique > validates_field > ''handle'', :hasMinLength=>3, :isUnique, :isAlphaUnderscore > validates_field ''password'', :isPassword > > This is how I did validations in my own framework. I have a bunch of > common isX & hasX and then of course the type of regex options that > Rails depends on as well. It looks more cramped in email than in > code, but I find it fairly quick to read and write (and with > predefined formats, there''s far less regex to trip over). > > This is probably going to be my first crack at a plugin, but I''m > going to have to figure out how to translates to and inject into > Rails'' native storage for validations. > > -- gw (www.railsdev.ws) > > > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Nov 26, 2007, at 1:33 PM, kevin cline wrote:> On Nov 25, 12:38 pm, Greg Willits <li...-0Bv1hcaDFPRk211Z5VL+QA@public.gmane.org> wrote: >> I''m not fond of Rails'' style of validation where one rule is followed >> by many fields. >> >> Trying to determine the rules of any one field is rather tedious with >> this setup. >> >> I''d rather have one field, followed by many rules. >> >> Anyone know if someone has already written something to do it that >> way? If not, I think I''ll take a crack at it. It would likely look >> something like this: >> >> validates_field >> ''field_name'', :isRequired, :isAlphaNumeric, :hasMaxLength => 10 >> >> Which would ultimately just translate and inject definitions into >> Rails'' existing internal structure, but at least I can read it field >> by field (and with a number of explicit easier-to-read keywords I''ll >> borrow from my past work).> This took about ten minutes to write and test:Cool. I started someting similar, but the send idea was a good one that should help finish the exepriment. Thanks for exploring it for me.> Making up new keywords from your past work is fine if you are the only > one who will have to read this code. But you will slow > understanding for all > the developers who read AWDWR and are familiar with the standard > names.But once they use my way, I''ll speed them up because they won''t spend five minutes mentally compiling what all the rules are for a given field by hunting through all those inverted rules, and they won''t spend time deciphering, remembering, and making typos in their regexs for the common stuff. Regex is handy, but it''s a speed bump every time you have to read it or write it. Rails has lot sof neat stuff. Rails isn''t perfect. So, I''m working my way through it and trying to decide where I need to spend time filling in holes and providing alternatives that I think are better from my past work. Some is just different, but a few I believe I had better. I understand the advantages sticking to what''s provided, but I think this is an area worth improving. The current method is quite cumbersome to read, write, and maintain IMO.> Also, your use of camelCase is non-standard and will make other Ruby > programmers think you are just an unreformed Java hacker.I''ve never liked underscore words. A line of rails code feels like someone took a shot gun to it and filled it full of holes. Can''t tell where phrases stop and start because it''s so full of empty spaces. Not to mention how awkward it is to type. Conforming is fine (I understand the advantages), but I hate that I have to conform to something so ugly. Right now I''m focused on just learning how Rails and Ruby do their thing. Trying to do that and switch all my styles isn''t working -- functionality first, style second once I get used to thinking in Ruby. I''ll conform by the time I publish something. -- gw (www.railsdev.ws) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> I''ve never liked underscore words. A line of rails code feels like > someone took a shot gun to it and filled it full of holes. Can''t tell > where phrases stop and start because it''s so full of empty spaces.Like a line of text in english ? :-) ImGladCamelCaseNeverCaughtOnForEmail> Not to mention how awkward it is to type. Conforming is fine (I > understand the advantages), but I hate that I have to conform to > something so ugly. >pure opinion - I personally can''t abide camelcase once you get past about 2 words, I find the lack of spaces makes it hard to read. Fred> Right now I''m focused on just learning how Rails and Ruby do their > thing. Trying to do that and switch all my styles isn''t working -- > functionality first, style second once I get used to thinking in Ruby. > > I''ll conform by the time I publish something. > > -- gw (www.railsdev.ws) > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Nov 26, 4:35 pm, Greg Willits <li...-0Bv1hcaDFPRk211Z5VL+QA@public.gmane.org> wrote:> On Nov 26, 2007, at 1:33 PM, kevin cline wrote: > > > > > On Nov 25, 12:38 pm, Greg Willits <li...-0Bv1hcaDFPRk211Z5VL+QA@public.gmane.org> wrote: > >> I''m not fond of Rails'' style of validation where one rule is followed > >> by many fields. > > >> Trying to determine the rules of any one field is rather tedious with > >> this setup. > > >> I''d rather have one field, followed by many rules. > > >> Anyone know if someone has already written something to do it that > >> way? If not, I think I''ll take a crack at it. It would likely look > >> something like this: > > >> validates_field > >> ''field_name'', :isRequired, :isAlphaNumeric, :hasMaxLength => 10 > > >> Which would ultimately just translate and inject definitions into > >> Rails'' existing internal structure, but at least I can read it field > >> by field (and with a number of explicit easier-to-read keywords I''ll > >> borrow from my past work). > > This took about ten minutes to write and test: > > Cool. I started someting similar, but the send idea was a good one > that should help finish the exepriment. Thanks for exploring it for me. > > > Making up new keywords from your past work is fine if you are the only > > one who will have to read this code. But you will slow > > understanding for all > > the developers who read AWDWR and are familiar with the standard > > names. > > But once they use my way, I''ll speed them up because they won''t spend > five minutes mentally compiling what all the rules are for a given > field by hunting through all those inverted rules, and they won''t > spend time deciphering, remembering, and making typos in their regexs > for the common stuff. Regex is handy, but it''s a speed bump every > time you have to read it or write it. > > Rails has lot sof neat stuff. Rails isn''t perfect. So, I''m working my > way through it and trying to decide where I need to spend time > filling in holes and providing alternatives that I think are better > from my past work. Some is just different, but a few I believe I had > better. I understand the advantages sticking to what''s provided, but > I think this is an area worth improving. The current method is quite > cumbersome to read, write, and maintain IMO. > > > Also, your use of camelCase is non-standard and will make other Ruby > > programmers think you are just an unreformed Java hacker. > > I''ve never liked underscore words. A line of rails code feels like > someone took a shot gun to it and filled it full of holes. Can''t tell > where phrases stop and start because it''s so full of empty spaces. > Not to mention how awkward it is to type.That''s your editor''s fault. Get a better editor, or customize the one you are using. Since ruby does not use the semicolon, I customized mine to map semicolon to underscore. Now it''s easier for me to type an underscore than a capital letter.> Conforming is fine (I understand the advantages), but I hate that I have to conform to > something so ugly.After a while, you will get used to it, and it won''t seem so ugly. And if you go against standard practices, the inconsistency between your code and the library code will be even uglier. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Nov 26, 4:35 pm, Greg Willits <li...-0Bv1hcaDFPRk211Z5VL+QA@public.gmane.org> wrote:> But once they use my way ... they won''t > spend time deciphering, remembering, and making typos in their regexs > for the common stuff.You should definitely factor out common validations. Here is one way: class ActiveRecord::Base def self.validate_as_phone_number field_name validate_format_of field_name, :with => /\d{10}/ end end> Regex is handy, but it''s a speed bump every > time you have to read it or write it.After a bit of practice that bump gets a lot smaller.> > Rails has lot sof neat stuff. Rails isn''t perfect. So, I''m working my > way through it and trying to decide where I need to spend time > filling in holes and providing alternatives that I think are better > from my past work.RAILS has been around for a while and most of the typical uses are well-supported. Before you spend time "filling in holes" you should probably ask more experienced RAILS developers how they would solve your problem. It may well be that your need is met by a feature you have overlooked, or by an available plugin. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Nov 26, 2007, at 8:25 PM, kevin cline wrote:> On Nov 26, 4:35 pm, Greg Willits <li...-0Bv1hcaDFPRk211Z5VL+QA@public.gmane.org> wrote: >> But once they use my way ... they won''t >> spend time deciphering, remembering, and making typos in their regexs >> for the common stuff. > > You should definitely factor out common validations. Here is one way: > > class ActiveRecord::Base > def self.validate_as_phone_number field_name > validate_format_of field_name, :with => /\d{10}/ > end > endYeah, exactly, that kind of stuff.>> Regex is handy, but it''s a speed bump every >> time you have to read it or write it. > > After a bit of practice that bump gets a lot smaller.Yeah, I''ve used regex a lot, so I don''t find it to be akin to reading klingon or anything, but I still find it quicker to read these other versions -- and, it''s more DSL-ish :-) Page 111 in this PDF http://www.pageblocks.org/downloads/docs/ pbGuide_r8.pdf shows most of the ones I developed. I recently added some newer ones not in that document.>> Rails has lot sof neat stuff. Rails isn''t perfect. So, I''m working my >> way through it and trying to decide where I need to spend time >> filling in holes and providing alternatives that I think are better >> from my past work. > > RAILS has been around for a while and most of the typical uses > are well-supported. Before you spend time "filling in holes" you > should probably ask more experienced RAILS developers how they > would solve > your problem. It may well be that your need is met by a feature you > have overlooked, or by an available plugin.Agreed. However, I spent over 5 years evolving my own open source framework extracted from real intranet apps in Gov, Edu, and Com spaces, publishing hundreds of pages of docs, examples, etc. So there''s some things I''ve learned and developed from experience as well. And of course there''s things simply not in rails like Auth. I know there''s a few auth plugins, but none have the scope of tools I am accustomed to. So that''s one I''m pretty far along in porting already. I have probably two more areas that I''ll build up. I had a pretty nice system for abstracting and minimizing the code needed for multi-form processes. I also had a pretty nice system for "multi-view- strings" that provided internationalization, device adaptation, and multi-facade adaptations to applications with a single simple API designed to help apps auto-adapt to various dynamic view environments (languages, PDAs, and hosted apps customized via configs). After that, I think most stuff is just different, but certainly not worth replacing. My biggest challenge wil be in writing these tools to feel at home in the Rails environment (despite some of the heebie jeebies I get from Ruby/Rails conventions, I am aware of the advantages to making my stuff feel Railsy). -- gw (www.railsdev.ws) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---