Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
schema = Dry::Validation.Form do
configure do
def future_date?(value)
Date.new < Date.parse(value)
end
end
required(:date).filled(:future_date?)
end
MyCustomObj
. is this easily possible too?
Color
object that has some nice methods for working with colors, say.
future_date?
method and i’d prefer to define it in code near where future_date
itself is defined
schema = Dry::Validation.Form do
configure do
def future_date?(value)
Date.today < value
end
def self.messages
Messages.default.merge(
en: { errors: { future_date?: 'Date must be in the future' } }
)
end
end
required(:date).filled(:date?, :future_date?)
end
Form
instead of Schema
but Schema
isn’t working for me either...
schema = Dry::Validation.Form do
configure do
def future_date?(value)
Date.today < value
end
def self.messages
default_messages.merge(
en: { errors: { future_date?: 'Date must be in the future' } }
)
end
end
required(:date).filled(:date?, :future_date?)
end
include Dry::Validation
in spec_helper there heh
messages
rather than default_messages
, but you get infinite recursion doing that...
predicate(:foo?, message: “oh noez”) do.. end
@
symbol, why wouldn’t you want to be able to throw a custom message if someone tries to create an instance with bad data: “An email just have an ‘@‘ symbol”. How is that not an improvement upon a generic message about a contraint violation or whatnot?
Email
type, and then, if i want, define my validation using that logic, yet without repeating that logic. that is, a validator which catches the InvalidEmail
or whatever it raises, and the processes that as it sees fit. otherwise, aren’t you either 1. duplicating the logic in your type in your validator or 2. breaking apart your type so that the type itself does not contain its own constraints. If i’m missing an alternative please lmk
Types::Strict::String.constrained(format: /email-regex/)
and then add a custom message for format?
rule failure
Email = String.constrained(format: /@/)
. So 2 independent questions: 1. How can I, in my validator, catch specifically a failure of the Email
type and create a custom error message for that? 2. I’d still like a custom error in the Email type itself, just in case, eg, I am using the type in a non-validation situation, and eg, hardcode an email in my constructor but mistype ‘me#gmail.com’ instead of ‘me@gmail.com’, when i run the code it would be nice to have a specific error message vs a general statement about constraints