Hello Core, I often need to validate the absence of active record fields. That validation being the direct opposite of validating the presence of a field. Would the core team be willing to accept a patch to that effect? Thanks, Paul -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Mon, Feb 27, 2012 at 10:15 AM, Paul Gillard <paulmgillard@gmail.com> wrote:> I often need to validate the absence of active record fields. That > validation being the direct opposite of validating the presence of a > field. Would the core team be willing to accept a patch to that > effect?Interesting! Can you explain some uses cases? If it makes sense I think it could be added. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Two that spring to mind are: validates :auth_code, :absence => true, :unless => :payment_complete? validates :comments, :absence => true, :unless => published? There may in some cases be some perceived repetition along the lines of the code below. I''d be interested to hear people''s thoughts on if this is acceptable. Though there is repetition I''d feel the intention of the code is clear. validates :auth_code, :presence => true, :if => :payment_complete? validates :auth_code, :absence => true, :unless => :payment_complete? On Feb 27, 9:18 am, Xavier Noria <f...@hashref.com> wrote:> On Mon, Feb 27, 2012 at 10:15 AM, Paul Gillard <paulmgill...@gmail.com> wrote: > > I often need to validate the absence of active record fields. That > > validation being the direct opposite of validating the presence of a > > field. Would the core team be willing to accept a patch to that > > effect? > > Interesting! Can you explain some uses cases? > > If it makes sense I think it could be added.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Mon, Feb 27, 2012 at 11:15 AM, Paul Gillard <paulmgillard@gmail.com> wrote:> Two that spring to mind are: > > validates :auth_code, :absence => true, :unless => :payment_complete?If the auth_code is something that won''t be set until you get a response from your payment gateway, then why bother with this? If what you want is to prevent users from updating this field when submitting the payment form, use attr_protected.> validates :comments, :absence => true, :unless => published?I''m guessing something that isn''t published usually won''t be surfaced to users, so no one will be able to comment on it. So why validate something? Adding a validation means adding code that runs each time you save your object, so validations that are just there to look nice but don''t really help (because they will always be valid since there''s no way the user can break them) will only make your app slower for no real benefit. I''m not saying there''s no use case for this (I just can''t think of any), but these particular use cases don''t warrant adding anything into core, IMO. Cheers, -foca> There may in some cases be some perceived repetition along the lines > of the code below. I''d be interested to hear people''s thoughts on if > this is acceptable. Though there is repetition I''d feel the intention > of the code is clear. > validates :auth_code, :presence => true, :if => :payment_complete? > validates :auth_code, :absence => true, :unless > => :payment_complete? > > On Feb 27, 9:18 am, Xavier Noria <f...@hashref.com> wrote: >> On Mon, Feb 27, 2012 at 10:15 AM, Paul Gillard <paulmgill...@gmail.com> wrote: >> > I often need to validate the absence of active record fields. That >> > validation being the direct opposite of validating the presence of a >> > field. Would the core team be willing to accept a patch to that >> > effect? >> >> Interesting! Can you explain some uses cases? >> >> If it makes sense I think it could be added. > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Mon, Feb 27, 2012 at 2:15 PM, Paul Gillard <paulmgillard@gmail.com>wrote:> validates :comments, :absence => true, :unless => published? >A particular problem I would expect with this one is that a post that has already received comments while it was published cannot easily be unpublished.> post.update_attributes(:published => false)will then fail because of this validation (and does it makes sense to delete all comments when setting it to unpublished?). A possible validation could then be: validates :comments, :absence => true, :if => never_published? More fundamentally, maybe there is a confusion between: * "validations" as intended to validate the user enter correct values through the {AP|GU}I before processing/persisting this data input * "assertions" as intended to double check the internal state of the program (I would typically raise an "internal error" with explanation on the problem if such an assertion failed). HTH, Peter -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Mon, February 27, 2012 04:18, Xavier Noria wrote:> On Mon, Feb 27, 2012 at 10:15 AM, Paul Gillard > <paulmgillard@gmail.com> wrote: > >> I often need to validate the absence of active record >> fields. That >> validation being the direct opposite of validating the >> presence of a >> field. Would the core team be willing to accept a patch >> to that >> effect? > > Interesting! Can you explain some uses cases? > > If it makes sense I think it could be added. >Bot trapping with hidden fields that no human would complete? -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I believe that this one was a bad example... I found myself implementing this a couple times in the last year: validate :a_or_b> > def a_or_b > if a? && b? > self.errors.add :a, "You can''t choose both options at the same time." > end > end >One of the cases was extremely common: Choose something: [ ] Option 1 [ ] Option 2 [ ] Option 3 [ ] Other <input type="text"> Each option would be an *option_id : integer*, and Other would be *other_option : string* . For that case : validates :option_id, :absence => true, :if => :other_option? validates :other_option, :absence => true, :if => :option_id? Would fit perfectly! (Considering that at least one of them is obrigatory). What do you think ? -- Att, Everton -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Assume you have a tree, where you want to have set attributes only, if a node is a root. Otherwise the model should not accept entries for a specific attribute. I.e. if you have a tree of categories and want to have a locale attribute only on roots you could do s''thing like this: class Category < ActiveRecord::Base validates :locale, :presence => true, :if => :root? validates :locale, :absence => true, :unless => :root? end Actually I''m doing this a lot. I''ll use s''thing else, if someone has a better pattern. Cheers, Roberto -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/_Qgt0vhDA4wJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I just worked this into rails and submitted a pull request: https://github.com/rails/rails/pull/7155 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/WqPA-wN07LkJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.