Fork me on GitHub
#yada
<
2016-02-15
>
stijn12:02:53

has anyone implemented a walk over bidi routes with yada 1.1?

stijn12:02:10

the question in fact is: how do I create a resource from another resource with some extra options

stijn12:02:57

just merging doesn't work as it needs to do the coercion on the input schema first

imre12:02:14

have you got any examples for "extra options"

stijn12:02:26

{:parameters {:path  APIRequestPath
                :query APIRequestQuery}
   :produces   #{"application/json"
                 "application/edn"}}

stijn12:02:40

APIRequestPath and Query are a prismatic schema

stijn12:02:01

the error happens on 'produces', since it's not in the format [{:media-type "application/json"},...]

imre12:02:42

[{:media-type #{"application/edn"
                                          "application/transit+json"
                                          "application/json"}}]

stijn12:02:45

i'm using the following 2 functions to walk the bidi tree:

stijn12:02:52

(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))))

stijn12:02:21

or should I call

resource
after the deep-merge?

imre12:02:51

without fully understanding how the tree generation works I'd say the latter

stijn12:02:34

@imre: if I use that syntax with media-type the schema validation works, but I always get a 406 then

stijn12:02:42

regardless of the Accept header

stijn12:02:49

let's try with calling resource simple_smile

imre12:02:16

charset?

stijn12:02:18

yes, that's it

imre12:02:22

[{:media-type #{"application/edn"
                                          "application/transit+json;q=0.9"
                                          "application/json;q=0.8"
                                          "text/html;q=0.7"}
                            :charset    #{"UTF-8"}}]

stijn12:02:33

(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))))

stijn12:02:41

like that

stijn12:02:18

then it's also possible to use the shorthand form :produces #{"application/json" "application/edn"}

stijn13:02:36

yada 1.1 is going to save sooo much code duplication simple_smile

stijn13:02:39

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

stijn13:02:52

@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?

malcolmsparks17:02:45

@stijn you're right, that's wrong. The 401/403 was coded before the authorization thing was pluggable

malcolmsparks17:02:05

401/403 determination need to happen in yada, not in the user's authorization

malcolmsparks17:02:53

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

malcolmsparks17:02:54

I'd prefer to settle on a design where bidi/yada integration avoided yada's handler or resource function entirely.

malcolmsparks17:02:02

["/customers" {:methods {:get {:response (fn [ctx] ...)}}}]

malcolmsparks17:02:46

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.

malcolmsparks17:02:42

There are many ways to modify a tree of data in Clojure, at least as many ways as there are to skin a cat

malcolmsparks17:02:48

But 'the yada way' is not to be open-ended (like Ring middleware) but to add constraints

malcolmsparks17:02:12

(if there is such a thing as 'the yada way', I don't mean it to be pretentious)

malcolmsparks17:02:45

So I believe that there ought to be an idiom for modifying data trees.

malcolmsparks17:02:35

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