some simple delegations
but getting attribute translations and form builder compatibility :)
Be interesting to see what Piotr thinks when he gets back though, I'm not all that familiar with dry-validation myself
But again, people don't want too many dependencies, so lets have a gem for utitility classes, a gem for managing concurrency and a gem for active anything
I can't wait to see what Tim does with https://github.com/icelab/dry-web-skeleton tho, hopefully will be able to get the full stack running on top of dry and rom soon
I can see Luca's opinion on the API stability front. It's something he's decided to take on, with hanami being a "one stop shop"/all-encompassing solution for developers, something they can rely on above all else.
I guess it's a bit different to how an app using e.g. dry-web or other non-frameworks is put together, where you decide to use whichever gems you want, and then learn/use them directly and keep on top of any API changes they may (or may not) ever need.
(I know that's possible with hanami too, but in offering a full range of functionality as an in-house option, I'd imagine the majority of hanami users would follow that path)
I'll release a dry-web gem release today and try to get some minimal docs in our icelab skeleton, @AMHOL :)
I also want to think about what constitutes a viable minimum skeleton too, something perhaps less opinionated than ours (which comes out of the box with things like a background job runner, etc., things that people might not necessarily want).
On dependencies, they're not something people should be afraid of, especially the right type of dependencies :)
I also started documenting the skeleton that we use for icelab dry-web projects: https://github.com/icelab/dry-web-skeleton
S/massively/as best I can/ :)
@timriley https://github.com/hanami/validations/pull/98#issuecomment-212694147
That was a fanatstic reply.
@tak1n great! Would love to hear how you go. Let me know if you have question.
BTW, at Icelab we're currently building our now company site as a dry-web app started from this skeleton. It's still very early, but it may serve as a helpful point of reference. It's on GitHub as icelab/berg.
It might be useful to just explain the purpose of the
Hi everyone, I'm writing a form object powered by dry-validation. Let's say the form has two keys - :code and :organization_id.
I want to validate whether a pair [:code, :organization_id] is unique in my db, yet I'm failing in doing so.
First I though about using rule(uniq_code: [:code, :organization_id]) but it clearly wants me to run predicates on the keys I've passed into it, so I decided to go with my custom predicate and ended up with the following
Create = Dry::Validation.Form do
key(:code).required(uniq?: "organization_id")
key(:name).required
key(:countries_id).required
key(:description).required
key(:organization_id).required
key(:active).required
configure do
option :market_repo, WheelsApp.instance["repositories.market"]
def uniq?(organization_id, value)
# query logic here
end
endHow can I pass to uniq? method a value of :organization_id that comes from object I've passed into the form?
I tried with
value(:organziation_id) but that returns something like an ast graph
@timriley @sled thank you for your answers. As you suggested I went back on "high level rule" track and it looks like this now
https://gist.github.com/kubakrzempek/f6c15643b9adae7e3de27a6b946aee30
but it still doesn't work, because sequel queries expect
I commented the
Do you know any other way to implement block assigned to
https://gist.github.com/kubakrzempek/f6c15643b9adae7e3de27a6b946aee30
but it still doesn't work, because sequel queries expect
organization_id and code to be values, not Dry::Validation::Schema::Rule objects.I commented the
unique? method's body and returned false explicitly, and the rule(:uniq_code_organization) failed, because it didn't expected to receive a FalseClass object.Do you know any other way to implement block assigned to
rule?