Re: component: dynamic configuration
Thanks for the clarifications! On 07/07/2015 11:52 PM, Stuart Sierra wrote: Hi pyr, There are many downsides to hierarchical structure of components and systems. The effects are complicated and hard to understand. See, for example, the discussion at https://groups.google.com/forum/#!topic/clojure/2-baBp61XTs/discussion I recommend that system maps be kept flat, without any nested systems. To prevent name clashes, you can always generate unique keys for the components. –S On Tuesday, July 7, 2015 at 2:47:03 PM UTC-4, Pierre-Yves Ritschard wrote: Would you directly assoc :inputA :inputB :outputA :outputB components in the first layer of the system map or would you retain a hierarchical structure and if so, are there any downsides to this ? -- 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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: component: dynamic configuration
Not sure if this helps, but remember that components and systems are just records, and records behave like maps. You can construct an empty `system-map` and then `assoc` components or even `merge` other maps into it. –S On Tuesday, July 7, 2015 at 1:00:51 PM UTC-4, Pierre-Yves Ritschard wrote: Hi, I've been using an approximation of what component provides in my applications for quite a while, and I'm trying to see if it's feasible to move to component, in the sake of homogeneity with the rest of the clojure world and to see if there are things that make my life easier. I have a couple of apps which expose a somewhat generic way of manipulating data in a certain way. Most follow the pattern of having several possible inputs (which must all adhere to a protocol), an engine that does its work and several possible outputs (again, adhering to a protocol). While configuring each of these inputs or outputs as components is straightforward, I failed to find a good strategy for storing them and constructing the system-map correctly. Did anyone tackle this yet and if so are they willing to share their approach ? Cheers, - pyr -- 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: component: dynamic configuration
This could be a nice example of how to use component in practise: https://github.com/bevuta/pepa Internally we configure the system map differently. This is based on yet another library https://github.com/RedBrainLabs/system-graph We have extended the idea of this library and we now have a file based system configuration where subsystems (graphs/maps) can be merged. HTH On Tue, Jul 7, 2015 at 7:07 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: Not sure if this helps, but remember that components and systems are just records, and records behave like maps. You can construct an empty `system-map` and then `assoc` components or even `merge` other maps into it. –S On Tuesday, July 7, 2015 at 1:00:51 PM UTC-4, Pierre-Yves Ritschard wrote: Hi, I've been using an approximation of what component provides in my applications for quite a while, and I'm trying to see if it's feasible to move to component, in the sake of homogeneity with the rest of the clojure world and to see if there are things that make my life easier. I have a couple of apps which expose a somewhat generic way of manipulating data in a certain way. Most follow the pattern of having several possible inputs (which must all adhere to a protocol), an engine that does its work and several possible outputs (again, adhering to a protocol). While configuring each of these inputs or outputs as components is straightforward, I failed to find a good strategy for storing them and constructing the system-map correctly. Did anyone tackle this yet and if so are they willing to share their approach ? Cheers, - pyr -- 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. -- 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.
component: dynamic configuration
Hi, I've been using an approximation of what component provides in my applications for quite a while, and I'm trying to see if it's feasible to move to component, in the sake of homogeneity with the rest of the clojure world and to see if there are things that make my life easier. I have a couple of apps which expose a somewhat generic way of manipulating data in a certain way. Most follow the pattern of having several possible inputs (which must all adhere to a protocol), an engine that does its work and several possible outputs (again, adhering to a protocol). While configuring each of these inputs or outputs as components is straightforward, I failed to find a good strategy for storing them and constructing the system-map correctly. Did anyone tackle this yet and if so are they willing to share their approach ? Cheers, - pyr -- 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: component: dynamic configuration
Hi,
I did get this far indeed. My general question was rather: what's your
general approach ?
Say I happen to have a config that loosely looks like:
{:inputs [{:type :inputA ...} {:type :inputB ...}]
:engine {:engine-opt1 :engine-arg1}
:outputs [{:type :outputA ...} {:type :outputB ...}]}
Would you directly assoc :inputA :inputB :outputA :outputB components
in the first layer of the system map or would you retain a hierarchical
structure and if so, are there any downsides to this ?
Cheers,
- pyr
On 07/07/2015 07:07 PM, Stuart Sierra wrote:
Not sure if this helps, but remember that components and systems are
just records, and records behave like maps. You can construct an empty
`system-map` and then `assoc` components or even `merge` other maps into it.
–S
On Tuesday, July 7, 2015 at 1:00:51 PM UTC-4, Pierre-Yves Ritschard wrote:
Hi,
I've been using an approximation of what component provides in my
applications for quite a while, and I'm trying to see if it's feasible
to move to component, in the sake of homogeneity with the rest of the
clojure world and to see if there are things that make my life easier.
I have a couple of apps which expose a somewhat generic way of
manipulating data in a certain way. Most follow the pattern of having
several possible inputs (which must all adhere to a protocol), an
engine
that does its work and several possible outputs (again, adhering to a
protocol).
While configuring each of these inputs or outputs as components is
straightforward, I failed to find a good strategy for storing them and
constructing the system-map correctly.
Did anyone tackle this yet and if so are they willing to share their
approach ?
Cheers,
- pyr
--
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
mailto:clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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: component: dynamic configuration
Hi pyr, There are many downsides to hierarchical structure of components and systems. The effects are complicated and hard to understand. See, for example, the discussion at https://groups.google.com/forum/#!topic/clojure/2-baBp61XTs/discussion I recommend that system maps be kept flat, without any nested systems. To prevent name clashes, you can always generate unique keys for the components. –S On Tuesday, July 7, 2015 at 2:47:03 PM UTC-4, Pierre-Yves Ritschard wrote: Would you directly assoc :inputA :inputB :outputA :outputB components in the first layer of the system map or would you retain a hierarchical structure and if so, are there any downsides to this ? -- 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.
