Closed albertored closed 5 years ago
whoops... just notice the other PR (#27) that address the same issue (#22)... sorry about that..
Sorry for the delay, I only found the time today to look into this. Thanks a lot for investing the time to come up with a solution. I like the approach in general that by default it returns the legacy format. If it's possible to keep backward compatibility without compromising the API design too much then it's worth doing that. I will have a look today to see how we can finally get this merged and released.
No problem, let me know if I can help somehow
I finally managed to release those changes in 0.6.0
. The README has some examples of how to use it. In the end I decided to keep backward compatibility and haven an option to disable the formatting (or provide a custom one). Thank you again for the help on this improvement.
Hi, I took your
validatio-errors
branch, added the missing format part, rebased on current master and fixed some dialyzer warnings.For the formatting part I added a new module (
ExJsonSchema.ErrorFormatter
) exposing a functionformat/{1,2}
that takes the output ofExJsonSchema.Validator.validate/{2,3}
and an optional keyword and formats the errors.When calling it without options the output format is the legacy one (
[{msg :: String.t(), path :: String.t()}]
.If called with
[output: :json]
as second argument the output is a "json-friendly" map that can be returned for instance in a body of a HTTP response. Something likeWe can also move the
:output
option in thevalidate
method having the result to be in the legacy format by default and adding a third option (maybe:bare
) to return the complex error struct.I would like to know your opinion, then, if you agree I can add some test and merge it.