Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Tim Riley
@timriley
(This might need to be a medium-term thing - before RDRC I'd like to see if I can just smooth some rough corners in what we already have)
Piotr Solnica
@solnic
yep
Tim Riley
@timriley
Since there's not that long until then.
Cool. Well, I'll write up some notes about that on Sun or Mon :)
Piotr Solnica
@solnic
another good example of a system would be http routing
basically entire http front-end can be contained within a system
Tim Riley
@timriley
Yeah, that feels better
Piotr Solnica
@solnic
ie hanami router + rack + middlewares == http system
Tim Riley
@timriley
It shouldn't be some exceptional thing
Piotr Solnica
@solnic
you just plug it into your app, the top-level system
Tim Riley
@timriley
And that http system would depend on the app's system?
Piotr Solnica
@solnic
another one, view rendering, also a system
no it shouldn’t know about the app’s system
it’s plugged into it
I think, thinking out loud :)
the integration point is the app’s container, which provides the app’s API to the http front-end
that, we already have, it’s just about making this more formal with better vocabulary :)
and an explicit object representation
Tim Riley
@timriley
Hmm, right
Yeah, I get this
(The role of the container to connect things)
Piotr Solnica
@solnic
it’s gonna be really cool to build a tool that looks at your setup and generates a visual representation of what happens when a request comes in :D
rack middlewares => final routing end-point => application end-point => specific objects that process data => perrsistence operations => db result => app result => http response
Oskar Szrajer
@gotar
NewRelic^2 ;]
Piotr Solnica
@solnic
right, this would be taken to the next level
esp with monitoring capabilities
Tim Riley
@timriley
Oh man, Michael at Icelab would love this
Piotr Solnica
@solnic
:)
Oskar Szrajer
@gotar
idea for product - $$$
Hannes Nevalainen
@kwando
@timriley more customizable / less restrictive auto_registration for dry-component would be nice, read that you were going to spend some quality time with dry-component =)
Worth a watch if anyone hasn't seen it yet
Piotr Solnica
@solnic
@kwando if you don’t like default behavior just register your objects yourself
I wouldn’t want dry-component to turn into a highly customizable object construction framework
Hannes Nevalainen
@kwando
@solnic I already got my own registration strategies
some of them is rather app specific though
Maciej Mensfeld
@mensfeld
@solnic will there be a strict mode for dry-validations? I mean now I can pass a field that I haven't declared and it is there
Piotr Solnica
@solnic
yes there will be a predicate which checks that
Maciej Mensfeld
@mensfeld
I really need that for what I do ;) (and all the other magic you guys work on :D)
Piotr Solnica
@solnic
@kwando this is not a DI/IoC framework and it won’t be, for complex object construction strategies we could create an interface for integration with external libs that handle that
personally I’m not interested in such a thing
Hannes Nevalainen
@kwando
well, I ditched dry-component and rolled my own instead
Piotr Solnica
@solnic
is it OSS?
and did you try to use it in a rails app or dry-web stack or something else?
Hannes Nevalainen
@kwando
no it is not, it will be if I ever get to extract it from this app though =)
Piotr Solnica
@solnic
we can have a way of registering custom handlers
but this would be external, so dry-component would have its own simple one (the existing stuff) and you could configure your own
Hannes Nevalainen
@kwando
really enjoying how omakase the dry ecosystem is =)
Piotr Solnica
@solnic
yeah man it’s omakase and you consume it with really sharp knifes :laughing:
Hannes Nevalainen
@kwando
:laughing: