dry-rb/chat - Gitter

Jonah

@jonahx

Feb 07 2017 00:01

@solnic, so if i have an Email type defined using format: and some other custom type like “SocialSecurityNumber” or whatever also defined using format, how would I distinguish between the errors? (Assuming the error message is just keyed on the generic format? key)

Piotr Solnica

@solnic

Feb 07 2017 00:07

depends on the use case, if they are used in structs, you’ll see which attribute failed

Jonah

@jonahx

Feb 07 2017 00:31

ok thx

Jonah

@jonahx

Feb 07 2017 07:29

@solnic so i’ve been thinking about custom domain objects and how they relate to validations all day, and i don’t know how hard this would be for you to implement (or if it’s already implemented and i suck at reading docs!), but i think my concerns would be answered it there was a way to specify a “self validating object” in the schema. eg, say I already have an Email object which will raise an error if I attempt to create an instance using a string which has no @. Then I could write:

required(:email).filled(valid_instance?: Email)

And, assuming input was called with input, the validation procedure would consist of running Email(input) inside of a begin…rescue block. If it ran without error, it would return the Email instance. Otherwise the raised error message would be used as the validation error message. Thoughts?

Jonah

@jonahx

Feb 07 2017 08:02

just one more thought before i crash. i could be convinced of pushing all error messages into a central location (yaml file or otherwise) and then having the domain objects like Email use that to get the error messages they need. so the second part of the above request is imo far less important than the first, and is only a convenience for small projects. the first part is pretty important imo, but i suspect there is a way to do it already somehow that i’m missing….

Piotr Solnica

@solnic

Feb 07 2017 08:16

@jonahx this type of functionality is not needed, constrained types can be used with dry-v and it’ll extract their constraints and use them for rules. using exceptions would be an overkill

Jonah

@jonahx

Feb 07 2017 08:21

@solnic you don’t think there would be a benefit to being able to use custom objects (that already contain validation and coercion logic) within the validations? or am i misunderstanding you?

for me this all comes down to avoiding any kind of lockin. not that i don’t like dry-types (i do), but i feel i should be able to levarage the logic contained within dry-validation using my own POROs if i feel like doing that.

Piotr Solnica

@solnic

Feb 07 2017 08:27

required(:email, Email) will do what you need but Email would have to encapsulate everything, so both coercion and rules

and it must be a dry-type type

Jonah

@jonahx

Feb 07 2017 08:29

@solnic so if I had an existing email object, i would need to need to wrap it as a dry-type in order to use it within a validation? what would be the mimimal interface i would need to implement to do so? are there docs on that?

Piotr Solnica

@solnic

Feb 07 2017 08:33

it would require defining a predicate that will rescue the exception and return false

but I never tried that

and yes, it would have to be wrapped in a dry-type object

Jonah

@jonahx

Feb 07 2017 08:34

@solnic ty. i will attempt it tomorrow and report back

passing out now, gn.

Piotr Solnica