Re: Disable swagger.ui in production
I'm going to buck a trend here.
Why do you want to do this? (That's rhetorical. Don't feel like you need to
answer).
One of the fundamental principles behind REST is that it is discoverable.
Maybe even that it's explorable.
Maybe you aren't building a REST end-point. It's totally possible that I
read too much into your post.
But I'm curious about bigger-picture issues: why wouldn't you include
something like swagger as part of your public API?
(Don't get me wrong: I can think of 4 different reasons off the top of my
head. I'm just curious why you don't want to).
On Wednesday, February 20, 2019 at 11:24:01 AM UTC-6, Brjánn Ljótsson wrote:
>
> Hi,
>
> I'm trying out compojure-api and have included swagger.ui in my api:
>
> (api
> {:swagger {:ui "/swagger-ui"
> :spec "/swagger.json"
> :data {:info {:version "1.0.0"
>:title "Title"
> ...)
>
> However, I don't want swagger to be included in my production build. What
> is the best way to disable swagger in production?
>
> Best,
> Brjánn Ljótsson
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Any way to replace function body?
You have several options for this in Clojure. However, rebinding the same toplevel var that holds the original function is probably not the right way to do this if you want to be able to retrieve the old function value later. Consider the following approaches: 1. Define a single multi-arity function: (defn fetch-data ([arg1 arg2] (db/fetch-data ...)) ([arg1 arg2 & args] (let [result (fetch-data arg1 arg2)] ;; do something with the remaining args (transform-result result 2. Derive the second function by composition: (defn fetch-data [arg1 arg2] (db/fetch-data ...)) (def fetch-transformed-data (comp transform-result fetch-data)) 3. Use "let" to rebind the function's definition within a lexical scope: (defn fetch-data [arg1 arg2] (db/fetch-data ...)) ;; ...somewhere later in my program... (let [fetch-data (fn [arg1 arg2] (transform-result (fetch-data arg1 arg2)))] (fetch-transformed-data "foo" "bar")) ;; Note: While this works, it is pretty sketchy. You should probably just call the new local version of the function something else. 4. Use "binding" to rebind the function's definition within a dynamic scope: (defn ^:dynamic fetch-data [arg1 arg2] (db/fetch-data ...)) ;; ...somewhere later in my program... (let [fetch-data-orig fetch-data] (binding [fetch-data (fn [arg1 arg2] (transform-result (fetch-data-orig arg1 arg2)))] (fetch-data "foo" "bar"))) ;; Note: You can't use binding to create a self-referential (recursive) function or you will trigger an infinite recursion. Use let to close over the original value of fetch-data before referencing it within the body of the new function used with binding. There are probably several other approaches that you could experiment with as well if you wanted to look a bit farther afield. IMO, I would just go with the function composition solution. It's clear and concise and doesn't require you to remember the specifics of dealing with recursion in dynamic binding forms. Happy hacking! Gary On Saturday, January 19, 2019 at 2:58:29 PM UTC, Janko Muzykant wrote: > > Hi, > > Is there an way to replace body of existing (interned) function with own > code still being able to call original fn? > Suppose, I have a function: > > (defn fetch-data [arg1 arg2] > (db/fetch-data ...)) > > I would like to intern a slightly modified version of this fn. Something > like this: > > (defn fetch-data [& args] > (let [result (apply original-fetch-data args)] > (transform-result result))) > > The problem I see is how to keep the reference to original fetch-data fn > (here denoted by original-fetch-data), > so it could be still called in a altered version of fetch-data function. > > Best, > JM. > > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Inside Clojure Journal
On Wed, Jan 30, 2019 at 12:03 AM Shaun Parker wrote: > I just wanted to say thanks to Alex for taking the time to journal all the > Clojure things he's working on (and the non-Clojure things as well). > They're enjoyable to read and eye-opening. It's a great window into the > effort that he and others are putting into Clojure. It's been fun to follow > the spec-alpha2 commits and get to read the thoughts/direction in the > journal. Great work Alex! > > You can find them on the Inside Clojure blog: http://insideclojure.org/ > Oooo this is awesome. I hadn't seen it before. Alex is pretty great. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Inside Clojure Journal
+1 I really appreciate this blog more and more. I is great to know that Clojure is vitally evolving and to have idea about is direction. Much appreciated, thanks Alex! On Wednesday, January 30, 2019 at 6:03:24 AM UTC+1, Shaun Parker wrote: > > I just wanted to say thanks to Alex for taking the time to journal all the > Clojure things he's working on (and the non-Clojure things as well). > They're enjoyable to read and eye-opening. It's a great window into the > effort that he and others are putting into Clojure. It's been fun to follow > the spec-alpha2 commits and get to read the thoughts/direction in the > journal. Great work Alex! > > You can find them on the Inside Clojure blog: http://insideclojure.org/ > > Shaun > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
