can you explain this project please?
@hasimisikli that might get you started
Working with a legacy app where a lot of logic is based on a nested hash. I'm convinced some keys have become obsolete and some keys contain typos, so I'm trying to work backwards to a schema where every entry of the hash adheres to, that gives a starting point to see what keys exactly exist. So I want the validation to error if extra keys are given.
I could also use dry-struct for it, but I'm not interested in the resulting struct (yet), and dry-validation gives more readable errors
because Types::Params::Bool already converts everything to true or false
which abstraction should i use to ensure only 'true' and 'false strings as input
From my point of view it is a bug...
please start an Issue
I will try to take a look
Anyone are using dry-web for their projects?
(and FWIW I’m looking at using hanami-router + hanami-controller as a front-end to dry-web/system for our future projects at work)
Also, from a personal perspective, I’m trying to help with hanami development. This is a way for me to get on top of (some parts of) the framework.
@gotar I use dry-web-roda for a couple of my (production) projects.
I also found some inconvenience of using big blocks to describe routes and would love to see a better solution (maybe Hanami, but I'm not sure). Now I just divide my routes to separated files (named as a resource e.g. users.rb for /users/*).
I also found some inconvenience of using big blocks to describe routes and would love to see a better solution (maybe Hanami, but I'm not sure). Now I just divide my routes to separated files (named as a resource e.g. users.rb for /users/*).
we will see
I'm in the process of converting GQL app from AR to ROM but on top of Rails. So far so good as I had validations and business logic in dry-* already. I have to be careful with GQL nested queries though - it was easier with AR to do so, but one could end up in a "circle of queries" if not being careful. Nesting with ROM is more visible and "terminated" at some point. Which I like.
Hi, is there less "verbose" interface for custom rules in dry-validations?
Here is how I check "all or none" fields for location.
Here is how I check "all or none" fields for location.
rule(location_provided: [:address, :latitude, :longitude]) do |address, latitude, longitude|
(address.filled? & latitude.filled? & longitude.filled?) |
(address.none? & latitude.none? & longitude.none?)
endeach attribute name repeated 4 times. Seems not readable.
I could extract internal code to some helper function like all_or_none(address, latitude, longitude)
but this will only reduce 1 mention of each name
Is it possible to use something like this?
rule(:location_provided) do |s| #s for schema
all_or_none(s.address, s.latitude, s.longitude)
endIs this something that's possible with dry-validation?
Probably not. At least dry-v should be used for other. Look at https://github.com/solnic/transproc, I use it for the same tasks as your.
@ethnt Yeah, I would do similar to @v-kolesnikov’s suggestion: put dry-validation as close as possible to the edge of the app, i.e. it would validate the input from the external API. After that point, you know you’re dealing with good data, so you could use transproc to transform it.
Thanks for the answers everyone. What we're trying to do is use
dry-validation's schema to validate the inputs from an internal system, call out to one of two external APIs, massage the responses from them, and then map those responses to an internal model. The problem we're running into is that we'd like to share the schema between dry-validation and the internal model (currently using dry-struct) but we can't really
The internal model isn't database backed. We considered ActiveType but it didn't really jive with what we were trying to do
