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
Yeah, I get this
(The role of the container to connect things)
rack middlewares => final routing end-point => application end-point => specific objects that process data => perrsistence operations => db result => app result => http response
esp with monitoring capabilities
Worth a watch if anyone hasn't seen it yet
I wouldn’t want dry-component to turn into a highly customizable object construction framework
some of them is rather app specific though
personally I’m not interested in such a thing
and did you try to use it in a rails app or dry-web stack or something else?
but this would be external, so dry-component would have its own simple one (the existing stuff) and you could configure your own
lol
this was a deal breaker for me
nobody had the time to take care of this, that’s all
I'm including a dry-validation schema class on my models and checking it before saving. It works, but I'm not sure how happy I am with it.
Hi, guys; I'm having trouble with a
Types::Strict::DateTime initialisation. When I use the "raw" Gem-supplied types to define everything, all is well; when I use a self-defined module constant, I get a NoMethodError running what looks like the exact same code. Gist with short single-source-file demo code here
Initialising with
DateTime.now works when using Types::Strict::DateTime.default { DateTime.now }; it does not work when attempting to use a constant defined as Types::Strict::DateTime.default { DateTime.now }