I want to create a handler function which takes two inputs. One is a parameter taken from the url /name, and second is a param from the query string /name?x=3
(def my-app (app
[page-name] (handler page-name)))
(defn handler
[{:keys [params]} page-name]
(let [x (params "x")]
(-> (page-templ page-name x) response constantly)))
The above fails because the handler is expecting 2 params, however I am only passing one.
How do I get hold of the request map, and pass it to the handler ?
The request map in the above case contains a param named x.
It is best if you could dispatch on the page name, like that:
(app
[""] (index-page)
["login"] (serve-login))
Here functions index-page and serve-login return function of one argument.
(defn index-page[]
(fn [req] ..))
req is the request that will contain all the url parameters in key/value map. To get parameter value do this:
(-> req (get :params) (get :x))
So the full solution would look something like this:
(def my-app (app
["page1-name"] (handler)))
(defn handler []
(fn [req]
(let [x (-> req :params :x)]
(-> (page-templ page-name x) response))))
EDIT: Don't forget to wrap you application into (wrap-keyword-params) and (wrap-params), here's how you can do it:
(def my-wrapped-app
(-> my-app
(wrap-keyword-params)
(wrap-params))
Related
I've created a new Compojure Leiningen project using lein new compojure test. Web server is run by lein repl and then
user=> (use 'ring.adapter.jetty)
user=> (run-jetty test.handler/app {:port 3000})
Routes and app handler specification is trivial:
(defroutes app-routes
(GET "/*.do" [] "Dynamic page")
(route/not-found "Not Found"))
(def app
(wrap-defaults app-routes site-defaults))
Now, after changing anything in app-routes definition (e.g. changing "Dynamic page" text to anything else, or modifying URI matching string), i do not get the updated text/routes in the browser. But, when changing app-routes definition slightly to
(defn dynfn [] "Dynamic page fn")
(defroutes app-routes
(GET "/*.do" [] (dynfn))
(route/not-found "Not Found"))
i do get dynamic updates when changing the return value of dynfn. Also, following the advice from this article and modifying the app definition to
(def app
(wrap-defaults #'app-routes site-defaults))
(note the #' that transparently creates a var for app-routes) also helps!
Why is that so? Is there any other way one could get a truly dynamic behaviour in defroutes?
Thanks!
#'app-routes is a reader macro that expands to (var app-routes). When a var is used as if it were a function, it is dereferenced anew on each invocation, and then the value returned by that deref is called.
If you were to supply app-routes as the argument, the compiler would give the dereferenced value to wrap-defaults, and when the var is updated, the previous value is not changed, so changing the var does not change the behavior of app.
The following repl transcript might be instructive:
user=> (defn foo [] "original")
#'user/foo
user=> (defn caller [f] #(f))
#'user/caller
user=> (def call-foo-value (caller foo))
#'user/call-foo-value
user=> (call-foo-value)
"original"
user=> (def call-foo-var (caller #'foo))
#'user/call-foo-var
user=> (call-foo-var)
"original"
user=> (defn foo [] "changed")
#'user/foo
user=> (call-foo-value)
"original"
user=> (call-foo-var)
"changed"
This code is from the default luminus template:
(deftype RenderableTemplate [template params]
Renderable
(render
[this request]
(content-type
(->>
(assoc
params
(keyword (s/replace template #".html" "-selected"))
"active"
:servlet-context
(:context request)
:user-id
(session/get :user-id)
:user
(session/get :user))
(parser/render-file (str template-path template))
response)
"text/html; charset=utf-8")))
(defn render [template & [params]]
(RenderableTemplate. template params))
And I need to test this function using clojure.test:
(defn home-page [& [user]]
(layout/render
"home.html"
{:user user}))
How will I test the above function with the value associated to the key :user?
I suggest you to read some documentation and make a reasonable effort before launching so general questions. This could be an start http://blog.jayfields.com/2010/08/clojuretest-introduction.html
After you feel a bit comfortable with clojure test you may like to move to https://github.com/marick/Midje/wiki/A-tutorial-introduction-for-Clojure.test-users
Enjoy :)
First set your routes and handlers like this:
(defn home-page [& [user]]
(layout/render
"home.html"
{:user user}))
; setting routes
(defroutes main-routes
(GET "/user/:user" [user] (home-page user)))
Then do the unit testing:
Basic unit test
(deftest home-page-test
; Check if response code is 200
(is (= 200 (:status (main-routes {:request-method :get :uri "/user/Michael"})))))
or you can also use Midje
Using Midje
(:use midje.sweet
clojure.test)
(fact "Homepage Test"
(:status (main-routes {:request-method :get :uri "/user/Michael")) => 200)
I faced the same problem.
Calling (home-page) directly will return a RenderableTemplate type which isn't useful for testing.
In your test require:
(:require [capacityplanning.layout :as layout]
[selmer.parser :as parser])
Add this function:
(def template-path "templates/")
(defn mockRender [template params]
(parser/render-file (str template-path template) params))
And in your test you can bind:
(with-redefs [layout/render mockRender]
(home-page user))
Now when home-page is called it will return the html as a string. This should be more useful to write unit tests against.
I'm writing some middleware for Ring and I'm really confused as to why I have to reverse the order of the middleware.
I've found this blog post but it doesn't explain why I have to reverse it.
Here's a quick excerpt from the blog post:
(def app
(wrap-keyword-params (wrap-params my-handler)))
The response would be:
{; Trimmed for brevity
:params {"my_param" "54"}}
Note that the wrap keyword params didn't get called on it because the params hash didn't exist yet. But when you reverse the order of the middleware like so:
(def app
(wrap-params (wrap-keyword-params my-handler)))
{; Trimmed for brevity
:params {:my_param "54"}}
It works.
Could somebody please explain why you have to reverse the order of the middleware?
It helps to visualize what middleware actually is.
(defn middleware [handler]
(fn [request]
;; ...
;; Do something to the request before sending it down the chain.
;; ...
(let [response (handler request)]
;; ...
;; Do something to the response that's coming back up the chain.
;; ...
response)))
That right there was pretty much the a-ha moment for me.
What's confusing at first glance is that middleware isn't applied to the request, which is what you're thinking of.
Recall that a Ring app is just a function that takes a request and returns a response (which means it's a handler):
((fn [request] {:status 200, ...}) request) ;=> response
Let's zoom out a little bit. We get another handler:
((GET "/" [] "Hello") request) ;=> response
Let's zoom out a little more. We find the my-routes handler:
(my-routes request) ;=> response
Well, what if you wanted to do something before sending the request to the my-routes handler? You can wrap it with another handler.
((fn [req] (println "Request came in!") (my-routes req)) request) ;=> response
That's a little hard to read, so let's break out for clarity. We can define a function that returns that handler. Middleware are functions that take a handler and wrap it another handler. It doesn't return a response. It returns a handler that can return a response.
(defn println-middleware [wrapped-func]
(fn [req]
(println "Request came in!")
(wrapped-func req)))
((println-middleware my-route) request) ;=> response
And if we need to do something before even println-middleware gets the request, then we can wrap it again:
((outer-middleware (println-middleware my-routes)) request) ;=> response
The key is that my-routes, just like your my-handler, is the only named function that actually takes the request as an argument.
One final demonstration:
(handler3 (handler2 (handler1 request))) ;=> response
((middleware1 (middleware2 (middleware3 handler1))) request) ;=> response
I write so much because I can sympathize. But scroll back up to my first middleware example and hopefully it makes more sense.
The ring middleware is a series of functions which when stacked up return a handler function.
The section of the article that answers your question:
In case of Ring wrappers, typically we have “before” decorators that
perform some preparations before calling the “real” business function.
Since they are higher order functions and not direct function calls,
they are applied in reversed order. If one depends on the other, the
dependent one needs to be on the “inside”.
Here is a contrived example:
(let [post-wrap (fn [handler]
(fn [request]
(str (handler request) ", post-wrapped")))
pre-wrap (fn [handler]
(fn [request]
(handler (str request ", pre-wrapped"))))
around (fn [handler]
(fn [request]
(str (handler (str request ", pre-around")) ", post-around")))
handler (-> (pre-wrap identity)
post-wrap
around)]
(println (handler "(this was the input)")))
This prints and returns:
(this was the input), pre-around, pre-wrapped, post-wrapped, post-around
nil
As you may know the ring app is actually just a function that receives a request map and returns a response map.
In the first case the order in which the functions are applied is this:
request -> [wrap-keyword-params -> wrap-params -> my-handler] -> response
wrap-keyword-params looks for the key :params in the request but it's not there since wrap-params is the one who adds that key based on the "urlencoded parameters from the query string and form body".
When you invert the order of those two:
request -> [wrap-params -> wrap-keyword-params -> my-handler] -> response
You get the desired result since once the request gets to wrap-keyword-params, wrap-params has already added the corresponding keys.
The answer by danneu is nice, but it only really "clicked" for me after I visualized it in code to see how the chaining of middleware really looks like without the "->" threading macro magic (here's a link if you're not familiar with it). This is what I ended up with:
Let's say you have a request handler that looks like this:
(def amazing-handler
(-> #'some-amazing-fn
some-mware
another-mware
one-more-mware))
^^ The above handler, written without using a threading macro, would look like this (and I'm extending the indentation on purpose, so it is visually easier to understand which request belongs to which handler):
(def amazing-handler
(one-more-mware
(another-mware
((some-mware #'some-amazing-fn) request-from-another-mware)
request-from-one-more-mware)
original-request))
^^ The above is a style of code that requires us to read it from inside out (which sometimes is hard to follow), the threading macros (-> and ->>) allow us to read code in a natural left-to-right way, but it requires understanding on our part of how exactly it allows us to compose code in this "natural" way behind the scene.
Here's a more complete example:
;; For reference: this is how the end result of the entire "threading" looks like:
;; (((#'some-amazing-fn req-from-up-passed-down) req-from-up-passed-down) original-request)
(defn some-amazing-fn [req] ;; this "req" is the one that will get passed to this function from "some-mware"
(println "this is the final destination of the req", req)
(ring.util.http-response/ok {:body "some funny response"}))
(defn one-more-mware [some-argument] ;; the "some-argument" in this case is (another-mware (some-mware #'some-amazing-fn))
(fn [req] ;; the "req" here is the original request generated by the ring adaptors and passed to this chain of middleware
(println "|--> from fn inside one-more-mware")
(some-argument req))) ;; here we provide the another-mware with the request that it will then pass down the chain of middleware, you can imagine that chain, at this point in time, to look like this:
;; ((another-mware (some-mware #'some-amazing-fn)) req)
(defn another-mware [dunno-something] ;; the "dunno-something" in this case is (some-mware #'some-amazing-fn)
(fn [req] ;; the "req" here is passed from one-more-mware function
(println "|--> from fn inside another-mware")
(dunno-something req))) ;; here we are passing the "req" down the line to the (some-mware #'some-amazing-fn), so the entire thing behind the scenes, at this point in time, looks like this:
;; ((some-mware #'some-amazing-fn) req)
(defn some-mware [some-handler] ;; the "some-handler" arg here refers to #'some-amazing-fn
(fn [req] ;; the "req" here is passed to this function from another-mware function
(println "|--> from fn inside some-mware")
(some-handler req))) ;; here is where we are passing a "req" argument to the #'some-amazing-fn, so behind the scenes it could be thought of as looking like this:
;; (#'some-amazing-fn req)
(def amazing-handler
(-> #'some-amazing-fn
some-mware
another-mware
one-more-mware))
;; |--> from fn inside one-more-mware
;; |--> from fn inside another-mware
;; |--> from fn inside some-mware
;; |--> this is the final destination of the req {.. .. ..}
I'm using an AngularJS resource to basically $.ajax() some form data.
Post.put({user:$scope.getLoggedInUser(), action:"new"},{body:$scope.postBody, "public":$scope.postPublic}, function(post) {
On the form is a checkbox named "public."
I am using this function to merge the form data with the params from the URL:
(defn get-params [request]
(merge (:params request) (parse-string (slurp (request :body)) true)))
when I println from my route's handler like so I get a nice true when the checkbox is checked:
(println (:public (get-params request)))
However, when I pass the parameter (i.e. not the println) to another function in my controller that talks to the database, I do another println at the beginning of that function and get nil instead.
I've tried passing it as
(read-string x)
(boolean (Boolean/valueOf x))
(Boolean/valueOf x)
to no avail.
One thing that might be causing it (but I don't know why) is that I'm wrapping the request through authentication like this:
(auth? request #(create x y z))
where the (create) function creates a record in the database.
I can't get it to be true no matter what I've tried.
EDIT: more complete code
CONTROLLER
(defn auth? [request callback-true & [callback-false]]
(println (callback-true))
(let [login-response (auth/login request)]
(if (and (not (string? login-response))
login-response)
(callback-true)
(if callback-false
(callback-false)
(json-response (str "{\"auth\":" login-response "}"), 401)))))
(defn create [user logged-in-user body public?]
(if (= logged-in-user user)
(json-response (post-view/single-post (post/create user body public?)))
(json-response "{\"auth\":\"can't create post under different logged in user\"}" 401)))
(defroutes routes
....
(PUT "/api/:user/new" request
(println request)
(auth? request
#(create (:user (request :params))
(:user (request :session))
(:body (get-params request))
(:public (get-params request)))))
....
)
MODEL
(defn create [username body public?]
(println public?)
(when-not (and
(str/blank? body)
(str/blank? username))
(let [user-id (:id (get-id-from-username username))
new-post-id
(:id
(sql/with-connection db
(sql/insert-values :post
[:usr_id :body :public] [user-id body (Boolean/valueOf public?)])))]
(by-id new-post-id))))
Don't call get-params twice. (request :body) returns a stream, which can't be read twice.
I have a Clojure library which defines a MQHandle protocol, and extends it
(ns example.mq
(:import [java.util.concurrent BlockingQueue]))
(defprotocol MQHandle
(send-message [this key body & params])
(extend-type BlockingQueue
MQHandle
(send-message [this key body & params]
(.put this (merge {::key key, ::body body}
(into {} (partition 2 params)))))
(defn get-handle ^BlockingQueue [& config]
"return a BlockingQueue tied to a thread which consumes messages
and submits them to a remote message queue"
...)
...but when I try to use it:
(require '[example.mq :as mq])
(def handle (mq/get-handle config))
(satisfies? mq/MQHandle handle)
; => true
(mq/send-message handle "key" "body")
; java.lang.IllegalArgumentException: No single method: send_message of interface:
; com.indeed.clojure_network_repl.mq.MQHandle found for function: send-message of
; protocol: MQHandle
I don't grok the meaning of this exception, or what I should be doing differently.
Protocol functions don't support rest arguments.