Fork me on GitHub
#ring-swagger
<
2018-03-21
>
jmckitrick13:03:20

Another question. In swagger-ui, there’s a column for ‘description’ for each of the parameters. How can I get a value into that column for each parameter?

jmckitrick15:03:28

I saw that, but does it work with spec, @ikitommi?

ikitommi15:03:13

no. spec uses spec-tools, which has the new syntax. I believe it reads the :json-schema/description field.

ikitommi15:03:20

so, something like:

ikitommi15:03:44

(st/spec
  {:spec integer?
   :name "integer"
   :description "it's an int"
   :json-schema/default 42})

ikitommi15:03:26

actually, it reads the :description and merges :json-schema/* things on top.

ikitommi15:03:35

Schema will get same api, soon.

ikitommi15:03:24

e.g.

(schema-tools.core/schema
  {:schema s/Int
   :description "it's an int"})

(spec-tools.core/schema
  {:spec int?
   :description "it's an int"})

jmckitrick15:03:03

Perfect. I’ll try it out shortly

ikitommi15:03:09

we are porting all the stuff from ring-swagger int schema-tools (and polish things), will also work with ClojureScript, which is kinda awesome 🙂

jmckitrick15:03:50

I want to help with the docs as well.

ikitommi15:03:42

that’s really good. the auth docs… many people have been asking about ready integration into auth via buddy. We have had many versions of those, but nothing that could have been pushed to c-api.

ikitommi15:03:12

Thanks to Colin, Cursive does static analysis on all the c-api macros, could be those too. But super busy with a project and with all the libs, don’t have extra time to do those. Feel free to suggest something 🙂

jmckitrick15:03:24

My first question is what needs to be documented for c-api that isn’t covered by the existing buddy docs?

jmckitrick15:03:36

It makes sense to just add links to the example projects with buddy to start.

ikitommi15:03:42

yes, that would be a good start.

ikitommi15:03:29

some people have used custom keys meta-data like :roles to mark who can access the routes. and :user to bind the buddy user. Not sure is that a good idea to have those in c-api itself.

ikitommi15:03:40

it’s between a library and a monolith.

fingertoe19:03:40

still kinda stuck on this - I am using compojure.api.sweet when I access it from ClojureScript I get No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ’http://localhost:8080' is therefore not allowed access. Where do I fix that in the compojure-api.sweet setup?

juhoteperi19:03:51

@fingertoe If you want to access make http requests from one origin to another, you need to enable CORS headers, you can use: https://github.com/r0man/ring-cors

juhoteperi19:03:02

Like from localhost to http://example.com, or probably from localhost:3000 to localhost:8080, in latter case it is probably better choice to also serve the Cljs app from same origin as the API so there is no need for CORS

fingertoe19:03:12

Good deal. I will give it a go. There is a lot to learn!

jmckitrick20:03:57

@ikitommi So if user and roles shouldn’t be in c-api, where would be a better place?