This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-11
Channels
- # beginners (2)
- # boot (97)
- # cider (58)
- # cljs-dev (10)
- # cljsrn (7)
- # clojure (79)
- # clojure-austin (4)
- # clojure-brasil (1)
- # clojure-france (1)
- # clojure-russia (42)
- # clojure-spec (12)
- # clojure-uk (22)
- # clojurescript (150)
- # clr (1)
- # conf-proposals (7)
- # core-matrix (2)
- # cursive (4)
- # datomic (9)
- # jobs (2)
- # klipse (28)
- # leiningen (3)
- # lumo (8)
- # nrepl (1)
- # off-topic (28)
- # om (18)
- # om-next (2)
- # perun (17)
- # planck (9)
- # rdf (1)
- # re-frame (18)
- # reagent (7)
- # ring (2)
- # rum (1)
- # specter (11)
- # test-check (3)
- # untangled (1)
- # yada (7)
I'm trying to understand the bidi yada aleph integration, the handler that alephs expect is a yada handler that has a uri param that is destructured by bidi?
The integration is optional and has 2 parts. First, if bidi vhosts are used, there will be an function placed in the request that provides the URL formation facility, and yada/url-info and friends provide convenient access.
Second, a yada handler is a record that satifies Bidi's Ring protocol, allowing it to be used as the righthand-side of a route pair.
For convenience, yada resource records also satisfy bidi's Ring protocol, so you don't have to wrap a resource in a handler record to put in a bidi route structure. This convenience actually makes the tree more naked data so easier to postwalk and process
malcolmsparks: when I get home I'll strip bidi's route structure from Yadas handler
malcolmsparks: I'm using the match-route fn on the (:uri req) with the map "/" pointing to a string, is this correct use?
The api-as-pure-data approach is useful. On Monday I have some client work to generate a PDF API document from it, should be straight-forward enough.