This is a good question, but not so much one for Jig as for Stuart's workflow pattern on which Jig's based.
Generally, I write my Clojure bottom-up, so that functions that do work against database connections and the like, take these as parameters, and not the whole system map. This leads to the situation where callers to these functions are doing stuff to extract the necessary values from the system map in order to pass them as parameters. Also, some functions have to take a lot of parameters. So at certain times I feel it's often easier to pass down the whole system map. This seems in violation of http://en.wikipedia.org/wiki/Principle_of_least_privilege - however, it's much better to pass state in to a function as a parameter, than have that function pull in state from vars that are scattered around various name-spaces. This also has a benefit to testing - it's possible to construct mock system map to test functions. On the plus side, there is some precedent here. Ring handlers take large request structures, Liberator and Pedestal handlers take similar large 'context' parameters. Datomic's query takes a whole database as a parameter! There is good support in Clojure for handling larger structures, such as clojure.walk, de-structuring, and so on. This would be a good time to mention Strucjure https://github.com/jamii/strucjure on which Jamie Brandon gave a great talk earlier this week in London. A common pattern in Strucjure is to use a tree walk and match on parts of the structure to drive processing. On Thursday, November 7, 2013 5:13:49 AM UTC, julius wrote: > > Another question, using jig, the connection/db/cache/storage will be > everywhere in our code as a parameter of functions, is it flexible? > ,currently I prefer to managing those side effect at one place but will not > spread out to our other core functions. > > Thanks > > On Saturday, October 12, 2013 12:23:41 AM UTC+8, Malcolm Sparks wrote: >> >> A few months ago, Stuart Sierra blogged about the workflow he follows for >> building Clojure applications. >> >> "One of the great pleasures of working with a dynamic language is being >> able to build a system while simultaneously interacting with it. " >> -- http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded >> >> Since then I've been using this workflow for my own projects, and found >> it to be amazingly effective. >> >> I've added some extra features, and the result is Jig, which builds on >> Stuart's work in the following ways :- >> >> - Multiple components can each contribute to the 'system' map >> - Components are started in dependency order >> - Components are specified and configured in a config (edn) file >> - Jig can host 'plain old' Leiningen projects - Jig will even >> 'reload' them too e.g. if their project.clj dependencies change. >> - Jig can host multiple projects simultaneously >> >> There's a small but growing list of optional re-usable components that >> provide extra functionality :- >> >> - Pedestal services support. Jig provides the system map and >> 'url-for' function in the service context. >> - Nginx cache purging on reload >> - Git pull prior reload >> - Reload via JMX >> - nREPL >> - Stencil cache purging >> - Firefox remote control support for 'browser refresh on reload' >> >> I know others are working on similar designs. I'd be interested to hear >> what people think and whether this is useful. >> >> Thanks, >> >> Malcolm >> >> PS: Jig can be found here: https://github.com/juxt/jig >> >> >> >> -- -- 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.
