Fork me on GitHub

@malcolmsparks: indeed map notation is redundant in bidi and I rarely use it, as it gives unpredictable results for matching routes (order is important in our api). That would be really cool if the 'map' form would be the integration with bidi


The use case for walking the tree is as follows: there are multiple 'apps' on the platform, and each endpoint has a route /:app-id/some/resource, now there's two things for which I'm using postwalk: 1/ all these endpoints share quite a lot in terms of parameters, produces, ... 2/ i would like to send a 404 when the :app-id doesn't exist. also, when it exists, already assoc the app retrieved from the database in the context.


the second one looks for existing :methods, and adapts the :response function to do the 404 check and inserting the app inside the ctx


not sure if that's in line with the yada idiom for modifying trees simple_smile


Yes I agree. Less boilerplate and more 'dataish'. I think I'll deprecate the map syntax in bidi - I agree it causes more problems that it solves


I'm also thinking of functions e.g. 'api' that take such a tree and to the tree walk for you, calling your resource 'filters' ehich you can give it. A resource filter would update a resource (e.g. add a security model). 'Filter' in the dsp sense, not in the clojure core lib sense


I think that's a good idea. I just modified the old update-routes to

(defn update-routes [routes f & args]
    (fn [x]
      (if (instance? Resource x)
        (resource (apply f x args))