This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-07
Channels
- # aws (2)
- # bangalore-clj (4)
- # beginners (62)
- # boot (74)
- # cider (408)
- # cljsrn (17)
- # clojure (117)
- # clojure-dusseldorf (1)
- # clojure-russia (21)
- # clojure-spec (17)
- # clojure-uk (15)
- # clojurescript (154)
- # cursive (3)
- # datomic (16)
- # emacs (33)
- # funcool (3)
- # hoplon (99)
- # off-topic (7)
- # om (10)
- # overtone (3)
- # portland-or (1)
- # protorepl (9)
- # re-frame (83)
- # reagent (11)
- # remote-jobs (1)
- # ring-swagger (24)
- # specter (10)
- # untangled (1)
- # yada (11)
Has anyone been able to get the authorization button for ring swagger from the demo for swagger ui (http://petstore.swagger.io/) ? I am looking through the docs and not sure how to get this to show up. I tried to add a :secuirtyDefinition to the defapi for swagger, but it doesn't seem to work. Do I need to make my own custom index.html page to have the authorize button?
So, apparently, to turn off coercions but leave validations in place one must use this:
(compojure.api.sweet/api
{:coercion (fn validation-only
[_request]
(fn [_coercion-type]
(fn [_schema]
nil))) ...
@metametadata does this work? :coercion (constantly (constantly nil))
?
it should be :coercion (constantly (constantly (constantly nil)))
🙂
btw, just did a PR out of the :body
params (don’t keywordize keys), does that look right: https://github.com/metosin/compojure-api/pull/265
oh nice
I need some time to scan through the diff..
there is the one test to verify that. Updated ring-swagger to support non-keyworded map keys too.
I've spent some time today figuring out the coercion code. And I'm not sure but think there's a conceptual problem:
the library by default applies json-*-matcher
even though the input/output formats of my API is going to be Transit which doesn't require all the ceremony the "loosely-typed" JSON needs. So I'm now leaning towards turning off the coercion all together in my API and see how it goes.
and I also saw that it will addressed in the future
"The plan is to provide extendable protocol-based coercion out-of-the-box (Transit doesn't need any coercion, XML requires some extra love with sequences). Stay tuned."
^ somewhere in the wiki
you are right on that. with 1.2, Muuntaja publishes the used in & out format into the request, so that could be used. Should be done by the c-api.
awesome! so it looks like the current patch just addresses the particular problem which will be fixed in a better way in the future
e.g. change the default-coercion-matchers to read the used type and do coercion based on that.
unfortunately, I don't yet have enough time to do a PR
created a issue out of that, tagged for 1.2: https://github.com/metosin/compojure-api/issues/266
I've updated the wiki with the example of turning off coercion and added a link to this new issue: https://github.com/metosin/compojure-api/wiki/Validation-and-coercion