This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-15
Channels
- # aatree (23)
- # admin-announcements (13)
- # announcements (3)
- # beginners (49)
- # boot (50)
- # braid-chat (1)
- # braveandtrue (37)
- # cider (72)
- # cljs-dev (25)
- # cljsjs (6)
- # cljsrn (37)
- # clojure (78)
- # clojure-berlin (8)
- # clojure-greece (1)
- # clojure-ireland (2)
- # clojure-madison (14)
- # clojure-new-zealand (2)
- # clojure-poland (10)
- # clojure-russia (149)
- # clojured (2)
- # clojurescript (49)
- # community-development (6)
- # core-async (37)
- # cursive (1)
- # data-science (1)
- # datomic (30)
- # emacs (4)
- # euroclojure (1)
- # funcool (1)
- # graclj (1)
- # hoplon (17)
- # jobs (2)
- # jobs-rus (45)
- # ldnclj (6)
- # mount (12)
- # off-topic (124)
- # om (270)
- # onyx (131)
- # parinfer (70)
- # perun (2)
- # proton (168)
- # re-frame (32)
- # reagent (29)
- # ring-swagger (8)
- # testing (9)
- # yada (39)
@malcolmsparks: ok, makes sense
the question in fact is: how do I create a resource from another resource with some extra options
{:parameters {:path APIRequestPath
:query APIRequestQuery}
:produces #{"application/json"
"application/edn"}}
the error happens on 'produces', since it's not in the format [{:media-type "application/json"},...]
(defn update-routes [routes f & args]
(postwalk
(fn [x]
(if (or (instance? Resource x))
(apply f x args)
x))
routes))
(defn deep-merge-options [m routes]
(update-routes routes
(fn [res]
(deep-merge res m))))
@imre: if I use that syntax with media-type the schema validation works, but I always get a 406 then
[{:media-type #{"application/edn"
"application/transit+json;q=0.9"
"application/json;q=0.8"
"text/html;q=0.7"}
:charset #{"UTF-8"}}]
(defn update-routes [routes f & args]
(postwalk
(fn [x]
(if (or (instance? Resource x))
(resource (apply f x args))
x))
routes))
(defn deep-merge-options [m routes]
(update-routes routes
(fn [res]
(deep-merge res m))))
then it's also possible to use the shorthand form :produces #{"application/json" "application/edn"}
walking of a routes tree is a lot more powerful now that a resource is just a map instead of the collection of implementation of protocols in 1.0
@malcolmsparks: to come back to the 401/403 response. I do understand that it needs to happen in the 'authorize' step and not authenticate, but why does it happen in yada.authorization/validate and not in yada.security/authorize?
@stijn you're right, that's wrong. The 401/403 was coded before the authorization thing was pluggable
401/403 determination need to happen in yada, not in the user's authorization
On the tree walking thing, the only strong opinion I have is that resources should be fully specified prior to request processing - so security should be woven into every resource
I'd prefer to settle on a design where bidi/yada integration avoided yada's handler or resource function entirely.
["/customers" {:methods {:get {:response (fn [ctx] ...)}}}]
Given that maps are redundant in bidi (and I believe they should not be used), the map literal is available to unambiguously indicate a resource map in the tree.
There are many ways to modify a tree of data in Clojure, at least as many ways as there are to skin a cat
But 'the yada way' is not to be open-ended (like Ring middleware) but to add constraints
(if there is such a thing as 'the yada way', I don't mean it to be pretentious)
So I believe that there ought to be an idiom for modifying data trees.
1. Walk the tree - for each map, a) expand the map via coercion to remove short-forms, b) apply functions to the canonical map, functions must code towards the canonical map, not any short-forms (which are for hand-authors only), and c) construct a yada resource record from the final result (so any problems in the modifying functions are caught early and d) construct a yada handler from the resulting resource