Responses inline :)
On 18 Mar 2015, at 09:49, James Henderson ja...@jarohen.me.uk wrote:
On Wednesday, 18 March 2015 09:29:59 UTC, James Laver wrote:
component’ is a difficult term to google for, so I hadn’t come across your
project :)
Same problem here when I started writing Phoenix -
Thanks - thoughts inline :)
On Wednesday, 18 March 2015 09:29:59 UTC, James Laver wrote:
Hi James,
‘component’ is a difficult term to google for, so I hadn’t come across
your project :)
Same problem here when I started writing Phoenix - there could be many
libraries trying to solve the
Hi James,
This looks very similar to Phoenix
https://github.com/james-henderson/phoenix - a project I've been working
on for the last few months. It's pretty likely you hadn't heard of it (and
that's fine - it's not been hugely publicised!), but if you have, I was
wondering whether there was
Hi James,
‘component’ is a difficult term to google for, so I hadn’t come across your
project :)
I think your module had slightly different design goals from mine. Mine were:
* everything in one config file (although i also provide support for separate
data-config and system config)
* be
I've been using stuartsierra's handy component library for a while now, but
I wanted an easier way of connecting components together.
To that end, I wrote oolong. The main mode of operation is to take an edn
configuration file and connect the specified systems and components.
Just a quick look so far, but it looks pretty interesting. I'm working on a
multi-module project and I'd like to have the flexibility to run those
modules separately or together. Extracting the component structure out into
a config file could be pretty helpful in that regard. Nice work!
Andrew
If nothing else, the functions in oolong.util should be pretty handy for
manipulating them. Or can serve as a guide for manipulate them programmatically.
I’m working on a bunch of complementary stuff to this at present, including a
library for developing components on top of oolong that will
