Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
:company?
required(:type, :string)
.filled(:str?, :entity_type?)
.when(:company?) { value(:contact_name).str? ^ value(:executive_name).str? }
.when(:person?) { value(:date_of_birth).date? }
@abrthel I'll try that. I don't know exactly how that resolves but if they were both true
the total result will be false
won't it? I feel like there needs an operator that says, "Just do it all and if anything in here is false
return false
, but don't halt execution." +
was what I was considering if I added my own extension for the time being. Although I am going to wait and see how much I actually need it. Basically, I want something to nicely make conditional validations work like the top level validations. Everything in required
and optional
gets validated. Unless I'm missing something, that can't happen in a when
or rule
block.
I did some refactoring last night and it came together nicely though, in terms of strict vs. loose. In the "loose" schema I just use optional
and maybe
together to set the rules I want for if a value is present. Then I do this in my strict schema:
strict_schema = Dry::Validation.Schema(loose_schema) do
%i[att1 att2 att3].each { |att| rule(att => [att], &:filled?) }
end
And I add other rules for conditionals if they're conditionally required to be filled.
^
symbol in dry-validation means and/or
so it should get you what you're looking for assuming I'm not totally misinterpreting what you're saying. The test spec for XOR@abrthel In the example, if both .eql?
validations return true
it results in an error for be_reasonable
. If one of them is true
and the other is false
you end up with a pass. So, value(:contact_name).str? ^ value(:executive_name).str?
will certainly always evaluate both, but if both are true
the rule as a whole will result in a failure. What I want is &
functionality without short circuiting.
I can get the results I want though, it just requires more rules than I think it should but... I also don't know how often I'm going to do this. A non-ideal solution is fine for now. I'll try hacking in a +
operator or something later. It'd be a good exercise if nothing else.