This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-16
Channels
- # atlanta-clojurians (1)
- # aws (1)
- # beginners (65)
- # boot (4)
- # cider (81)
- # cljs-dev (25)
- # cljsrn (27)
- # clojure (129)
- # clojure-dusseldorf (12)
- # clojure-italy (68)
- # clojure-norway (5)
- # clojure-poland (4)
- # clojure-spec (14)
- # clojure-uk (72)
- # clojurescript (144)
- # code-reviews (19)
- # copenhagen-clojurians (5)
- # cursive (16)
- # datomic (21)
- # editors (1)
- # emacs (15)
- # events (1)
- # figwheel (6)
- # fulcro (54)
- # graphql (1)
- # hoplon (24)
- # jobs (6)
- # jobs-discuss (2)
- # keechma (4)
- # leiningen (6)
- # luminus (17)
- # lumo (2)
- # off-topic (43)
- # onyx (6)
- # pedestal (2)
- # perun (2)
- # portkey (3)
- # re-frame (22)
- # reagent (11)
- # ring-swagger (5)
- # shadow-cljs (46)
- # specter (8)
- # test-check (2)
- # testing (3)
- # vim (16)
- # yada (1)
What is the purpose of wrap-context
in middleware.clj?
I see it sets the :servlet-context key of the params map used to render in layout.clj, which if I’ve understood correctly will adjust any links to from /foo/bar
to /context/foo/bar
.
But if I’m right, what is the reason for using a dynamic binding to do this?
@alexchalk17 there are two use cases for this, one is if you're running inside an app server like jboss, where the context is provided at runtime, the other is if you decide to front multiple apps on the same domain with nginx or something
@yogthos, I’m still not sure I get it—in the jboss example, what stops you from querying the application context directly in layout.clj? Does it change during runtime?
is it because in the jboss scenario you can’t define *app-context*
in the render logic without passing in http request info? so the dynamic binding is a neater way of letting the rendering logic access a definition made in another part of the application?
it allows specifying the context via the middleware, and then accessing that context wherever it's needed
it might be better to just stick it as a key on the request though, that logic has been there for a while, and I haven't used it myself in ages
I'll take a look at getting rid of the dynamic var, those are always a bit of a smell 🙂
although then you would have to pass the request to the render
function in layout for all requests
thanks @yogthos, that makes sense now. I’m still pretty new to clojure, and discovering dynamic vars was a bit of a wtf moment 😛, but I agree that it is more elegant than always passing the req to the render function.