On 29 December 2017 at 18:19, Pablo J. Villacorta <olbapj...@gmail.com> wrote:
> Thanks! You are right, I have tried another minimal statement and does not > throw any exception... looks like the statement on that repo is not correct > either (I don't know what's wrong with it), but don't know how to output > proper error messages. According to the repo, > > (xs/validate-statement-data statement-str) ;; => returns statement edn > > but I do not know what edn stands for. Moreover, I always have the > argument as a plain string, not as an object as in this > <https://github.com/yetanalytics/xapi-schema/blob/master/README.org#clojurescript>example. > I have read also this: > > (xs/errors->data (xs/statement-checker bad-statement :en)))) ;; ltag is > optional, defaults to :en > ;; => {"actor" "Missing required key", "id" "Not a string: 123"} > > but I am unclear of the meaning of -> and how to use that from Java. Looks > like statement-checker is for objects, not for strings? > > I have a minimal working example here: https://github.com/ > olbapjose/xapi-clojure > > Regards and happy new year! > Disclaimer: I am not familiar with this library at all, so there's a little bit of guesswork on my part. >From the README, it looks like validate-statement-data accepts either Clojure data (a.k.a. "edn", a combination of nested maps and vectors) or a string that can be parsed as JSON. It will throw an exception if the data given is not valid, and otherwise return the data, i.e. it will return its argument unchanged if you pass in Clojure data, but if you pass it a string, it will parse that to Clojure data and then (assuming no validation error) it will return the (parsed) data. In Java terms this would be the kind of signature you'd expect in so-called "fluent" APIs. statement-checker seems to have essentially the same underlying semantics, but be designed for a more imperative API: it returns null if the given data is valid, and an error otherwise. This seems to be the same java.lang.Exception that would be thrown by validate-statement-checker, but it is simply returned instead of being thrown. So this is designed for a usage pattern where you want to have an explicit if statement rather than a try/catch. Because Exception objects are not that great to work with, the library supplies a errors->data function that extracts some additional descriptive data from the exception. The -> is just part of the normal, valid characters for identifiers in Clojure, so this is just the name of the function with no special (language-level) semantics; the intention here is that this function transforms an error into data, so the -> is meant to represent an arrow. You can read it as "error to data". (I don't really see a reason why statement-checker doesn't just return the error data, rather than wrapping it in an exception, though I'm sure the author had some reason for designing it this way.) EDN stands for "extensible data notation"; more details here: https://github.com/edn-format/edn However, in this context I think the author simply means "Clojure data" when he writes "edn". Clojure data is composed of nested maps and vectors, that respectively implement java.lang.Map and java.lang.List. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
