Validate absence of
Paul Gillard
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
Xavier Noria
Interesting! Can you explain some uses cases?
If it makes sense I think it could be added.
Paul Gillard
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:
Nicolás Sanguinetti
> 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 rubyonra...@googlegroups.com.
> To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
>
Peter Vandenabeele
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
James B. Byrne
Bot trapping with hidden fields that no human would complete?
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:Byr...@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
Everton Moreth
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 ?
--
