Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 18 2018 11:02

    jarohen on master

    Update README.org (compare)

  • Aug 18 2018 11:01

    jarohen on master

    Add deprecation notice (compare)

  • Aug 18 2018 10:59
    jarohen closed #5
  • May 12 2017 12:10

    jarohen on rethink

    (compare)

  • May 12 2017 11:57

    jarohen on rethink

    (compare)

  • Feb 06 2017 18:07
    whodidthis closed #11
  • Mar 07 2016 08:53
    jarohen commented #19
  • Mar 07 2016 08:52

    jarohen on 0.1.3

    (compare)

  • Mar 07 2016 08:52

    jarohen on master

    using java to get hostname rath… Merge remote-tracking branch 'f… Bumping versions - 0.1.3 (compare)

  • Mar 07 2016 08:52
    jarohen closed #19
  • Feb 23 2016 14:32
    jarohen commented #19
  • Feb 23 2016 11:38
    firthh opened #19
  • Aug 30 2015 09:27
    AndreaCrotti commented #17
  • Aug 30 2015 09:01
    piranha commented #18
  • Aug 30 2015 07:36
    jarohen closed #18
  • Aug 30 2015 07:36
    jarohen commented #18
  • Aug 30 2015 07:34
    jarohen closed #17
  • Aug 30 2015 07:34
    jarohen commented #17
  • Aug 30 2015 07:32

    jarohen on master

    plugins is a vector of vectors (compare)

  • Aug 27 2015 10:09
    piranha opened #18
James Henderson
@jarohen
Hi all, and welcome! Feel free to post any questions/issues etc in here :)
Alexander Solovyov
@piranha
I wonder how people manage configuration with component-based systems
should I create some component with configuration, which only serves for carrying a bit of stuff around?
or... what do you guys do?
James Henderson
@jarohen
if the configuration's for the component itself, I'd make it part of the Phoenix component map
not sure I understand the context here though?
Alexander Solovyov
@piranha
@james-henderson more like configuration of my app
like, it's not exactly tied to any component, just something for business logic
James Henderson
@jarohen
hmm - I'm still reasonably new to the Component pattern, so trying to figure out what works well, etc :)
but there's probably a few options you could try; see what fits in this particular situation
first one is to make a component out of the necessary functions - if they require parameters apart from what you're willing to provide from a caller, you could argue that they are a component?
second is to get any callers to pass the configuration - if we're aiming for referential transparency we'd like the function to depend solely on its inputs (of which the configuration is one)
this then moves the question to 'where does the caller get the configuration from?' - to which the answer seems to be recursive, I'm afraid!
finally (and probably least recommended, to be avoided if possible) is that the whole configuration map is available at @phoenix/system (in 0.1.0+, probably earlier) so can pull values out wherever you are in the code
James Henderson
@jarohen
I'm not particularly keen on that solution because it's essentially a global variable (albeit an immutable one), and ties you into Phoenix (which you're not under the previous two solutions - can replace everything with another Component library)
if it's possible, could you post a gist with some context? (i.e. what's calling your functions, how complex the business logic functions are etc)
Alexander Solovyov
@piranha
thanks for giving that some thought!
Alexander Solovyov
@piranha
so current thing is that I have to skip one item when displaying outputting items, because it's somehow very special for business logic and is handled just by its own id (I realize this is bad design, but I'm not really in position to fix this right now) - and it's different from production/staging/dev environments
I guess the best way to handle this is just by directly accessing phoenix/system... I think I'll just wrap it in some record and get-conf call, and will stop overthinking this
James Henderson
@jarohen
no worries :)