or libs or whatever
i haven’t kept up in the last few years
w/ generators hopefully
fwiw I’m planning to add a new data transformation lib to dry-* family later this year
I don’t like rom-mapper anymore :)
@solnic imagine taking an ebay product in their api format and converting that to what amazon needs for their api
and what bing needs
so could be taking something in some weird xml format, applying biz logic, then send to whatever json format another service needs
i like hanami’s actions more than roda (at first glance) because it’s easy to see how to structure the code / actions
on a team i think having the convention is important
vs jumping between router dsl and action files
the way we use roda is that http-specific code lives in the routing trees, everything else is core app APIs
so basically http part of the whole system becomes an extension on top of the core app
I mean, that’s how it works in dry-web
how weird is the xml, and how complicated is the business logic?
we’re actually thinking about a dry-fp project with various functional APIs that many projects can rely on
there’s a big portion of transproc that could be moved there
then transproc could become a collection of data-transformation functions that are composable
and I’d like to extend it with more advanced features, like type-safety and guarded transformations with various fallback and error handling mechanisms
Hello folks, I wonder if there is a recommended (or better) way for validating related values in dry-validations, e.g.:
schema = Dry::Validation.Form do
key(:a).required(:int?, gteq?: 0)
key(:b).required(:int?)
rule(:b_gt_a) do
value(:b).gt?(value(:a))
end
end
result = schema.call(params)I noticed that the validation message is plain, for example, if I pass {a: 0, b: 0}, the schema says that b must be greater than 0, but it would be really helpful for the client to know that it must be greater than a
Here’s an example where I’ve just done it locally to the schema (not the best approach for widespread usage, but easy for me to test in isolation):
schema = Dry::Validation.Form do
configure do
def self.messages
Dry::Validation::Messages.default.merge(
en: { errors: { b_gt_a: 'b must be greater than a' } }
)
end
end
key(:a).required(:int?, gteq?: 0)
key(:b).required(:int?)
rule(:b_gt_a) do
value(:b).gt?(value(:a))
end
end
result = schema.call({a: 0, b: 0})
result.messages
# => {:b_gt_a=>["b must be greater than a"]}
thanks!
@nepalez what in particular were you planning to release with dry-initializer 0.1.0? the
Mixin change?