> we do this using Graph Could you show a simple example of this? I think this might be a good topic for a blog post.
On Thursday, September 12, 2013 6:35:20 AM UTC+2, Jason Wolfe wrote: > > At Prismatic, we do this using Graph: > > https://github.com/Prismatic/plumbing > > I really try to avoid global vars, but passing through the seven > parameters or resources you need through four layers of intermediate > functions is also a hassle. Graph makes it easier to define your service > in a functional way, instantiate it with your parameters, and the data > automatically flows to the leaves where it's needed. When we leave the > Graph core and enter ordinary function land, resources and parameters are > passed through as a nested map, which at least means you only have a single > context argument rather than a mess of args. It's not a complete solution, > but I think it's worked pretty well for us thus far. > > 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.
