I have gone the dynamic var before, played well with ring handlers. Why ? Because I wanted to ensure consistency between "reads" to the configuration map for the duration of the ring handler call.
So just having the configuration and read the root value at different times would not suffice. I just created a little ring middleware which would bind the dynamic var's value before delegating to the real handler. This enables me to change the configuration's root var without worrying about concurrency conflicts with running handlers, since the handlers see a consistent bound value. My 0,02€, -- Laurent 2013/9/10 Christopher Allen <c...@bitemyapp.com>: > I do a hybrid in Bulwark. > > github.com/bitemyapp/bulwark/ > > Defaults to accepting a closure of a config map for nice testing and > hygiene, with a fallback to a global atom map for configuration for muggles. > > Works well for me. > > > On Tuesday, September 10, 2013 12:19:35 AM UTC-7, Alexandr Kurilin wrote: >> >> I'm trying to determine how to best deal with the concept of globals in >> Clojure. Say I have a map of configuration values for my Ring app, populate >> at app startup from disk or env, and I need to reference the contents of >> this map from all over the project. Assuming MVC, models and controllers all >> would be interested in its contents. I just want to clarify that the >> question is not so much about "configuration" as it is about dealing with >> state that many different components in an application might be all >> interested in. This is an issue that seems to arise very often. >> >> I'm seeing a couple of options here: >> >> Pass the configs map along with each Ring request with some middleware, >> and then down every subsequent function call that might eventually need it. >> It's a bit of a hassle since now you're passing more data, potentially >> increasing the # of parameters, or forcing you to use a parameter map >> everywhere where you might have passed along just 1 primitive. Nonetheless, >> this is as pure as it gets. >> Def the configs map in a namespace somewhere and refer to it from >> wherever, just like global state. The trick is now that now you're no longer >> certain what e.g. your model functions are expecting there to be in the >> system and testing becomes trickier. Now you have to either lein test with a >> separate set of configurations (which doesn't actually give you much >> per-test granularity) or use with-redefs everywhere to make sure the right >> test config state is being used. >> Something in the middle where perhaps you agree to never directly >> reference the configs map from your models (again, thinking MVC here) and >> instead only ever access it from controllers, and pass the necessary options >> along down to the model functions. This way you can test both controllers >> and models in isolation in purity. >> >> Ultimately I want to contain the chaos of having to know internal >> implementation details of my functions at different layers and want them to >> be easily testable in isolation. It does seem like the first option is the >> most straightforward, but I'd be curious to find out what those of you who >> have deal with the problem for a while would recommend. Purity all the way, >> or are there patterns that can give you the best of both worlds? Or what >> else? >> >> > -- > -- > 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/groups/opt_out. -- -- 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/groups/opt_out.
