<Eiam>
and retry it too, because tries seem to fix it as well.
<Eiam>
same rescue block, just snag them both.
<Eiam>
oh
<Eiam>
dear
<Eiam>
I thought I was in #datamapper
<Eiam>
sigh
<Eiam>
sorry =) I saw your name and though gosh its weird that he is in #datamapper
<Eiam>
Derp, you aren't!
zekefast has quit [Quit: Leaving.]
<dkubb>
lol
cored has quit [Ping timeout: 268 seconds]
cored has joined #rom-rb
cored has quit [Changing host]
cored has joined #rom-rb
CraigBuchek has quit [Quit: CraigBuchek]
lgierth has quit [Ping timeout: 252 seconds]
lgierth has joined #rom-rb
<snusnu>
hey guys
<snusnu>
mbj: btw, do you use ducktraps for query params too?
<mbj>
snusnu: Sure ;)
<mbj>
snusnu: Very handy to do some ugly conversions. But I have to admit I "rarely" use query params.
<mbj>
snusnu: For various reasons.
<mbj>
snusnu: Only for traditional data browsing in CRUD backends.
<mbj>
snusnu: And I rarely write these (CRUD is boring)
<snusnu>
mbj: i probably wasn't precise enough .. i rarely use "pure" query params .. i should've said "router params"
<snusnu>
mbj: stuff like /some/resource/:id
knowtheory has quit [Ping timeout: 252 seconds]
<snusnu>
mbj: the reason i called them query params, is that in my app, i make a distinction between query_params and command_params .. the former essentially being params sent with a GET, the latter being the POST body
mbj has quit [Read error: Connection reset by peer]
mbj has joined #rom-rb
<dkubb>
I usually try to make a distinction between path params and query params
<dkubb>
I use path params to kind of "locate" a resource, while query params are used to do things like refine search results on a collection resource
<mbj>
dkubb: Yeah, summarizes my approach quite good.
<snusnu>
sounds feasible, not yet sure tho wether i'm gonna split the params into 3 methods tho
<snusnu>
in any case mbj, you use ducktraps for those router/path params?
<snusnu>
seems like "double validation" .. otoh, ducktraps would do the coercion
<dkubb>
what I would love to do eventually is have it so there's path and query params as hash-like objects, and then have the body be a parser instance that knows how to parse the body and provide an interface to it
<snusnu>
dkubb: that's what i do, apart from separating path/query params .. which i truly might consider
<snusnu>
it seems to make a lot of sense
<mbj>
snusnu: I "ducktrap transform" anything to present a pure OO interface to work with in later layers.
<mbj>
snusnu: So passing hashes around cant be avoided sometimes.
<snusnu>
dkubb: our app uses substation, plus subway (some stuff typical for web apps) .. so my approach is rather different from everything else, but very open to any good idea ;)
<mbj>
snusnu: Or I dont found a good abstraction yet. But most of my use cases have "feasable" Input objects.
<snusnu>
mbj: i see, i do that too
<mbj>
snusnu: So there is a layer transforming all that path/routing/query params to an domain specific use case input object.
<snusnu>
mbj: so, i guess i'll go with a path_param_id_trap for starters
<snusnu>
yeah ...
<mbj>
In my opinion: If you *cannot* do such a conversation your action does to much, or your requirements are bullshit ;)
<snusnu>
i fully agree
<mbj>
So I have an ever "growing" list of subclasses from MyApp::DTO
<snusnu>
i want specific objects to enter my actions, nothing else
<mbj>
And just deduplicating there from time to time helps me a lot to keep my code DRY.
<snusnu>
you have a base DTO class? never needed that so far ...
<mbj>
Its just an abstract namespace class.
<mbj>
Does inherit Adamantium, and Anima, no behavior.
<snusnu>
ah ok
<mbj>
Just fo maximum deduplication.
<snusnu>
right :)
<dkubb>
what I've thought about is modelling something around resources and representations. there'd be a 1:1 mapping between a URL and a resource, and it would have #get, #head, #post, #put methods on it that each accept header and body argument, and returns a representation. the representation object would basically be a streaming generator that returns the negotiated response type
<mbj>
dkubb: I HATE content negotiation. Its AFAIK a source of "indeterminism" and unnneded complexity.
<mbj>
/foo/bar.ext, one URL one resource, one content type.
<mbj>
If I wanna have more content types, use /foo/bar.other ;)
<mbj>
(Can be mapped to same action with a param for sure).
<dkubb>
I love content negotiation when it's done properly
<mbj>
Surry for coming up with such a controversial statement just before saying:
<mbj>
I have to run, surry guys maybe online later ;)
<dkubb>
the problem is that it's been done poorly so many times everyone has a bad experience with it
<dkubb>
lol
<mbj>
dkubb: maybe true! I'm happy to renegotiate ;)
<mbj>
have to run, cu. BTW my working title for my spec framework is "xspec", just experimenting how to make it "self hosting" ;)
<dkubb>
oh nice
<mbj>
Its a 200loc spike, nothing solid now.
<snusnu>
dkubb: fwiw, my approach is much more low level, i basically provide primitives to "route" me through logical branches an endpoint exposes (i.e. a chain of processors, where every processor has a failure chain for domain errors, and every chain itself has an exception chain in case of exceptions)
<mbj>
have to run, cu
mbj has quit [Quit: leaving]
<snusnu>
dkubb: this allows me to program very offensively :)
<snusnu>
very functional in nature
<snusnu>
dkubb: i basically compose the necessary processing steps (along with some logic branching) declaratively, and then implement every specific step in a dedicated class
<snusnu>
dkubb: makes for some very nice reuse of code, very easy to test, very dry, and so on .. ;) i like it
CraigBuchek has joined #rom-rb
knowtheory has joined #rom-rb
<snusnu>
dkubb: can't wait till we have some code to push for our side project, it's (gonna be) built like i described
<dkubb>
snusnu: I can't wait to see it. I still feel like the abstractions we commonly used aren't quite right
breakingthings has quit []
mbj has joined #rom-rb
<mbj>
Totally OT, is somebody familiar with the internals of the linux block io layer (bio) ?
CraigBuchek has quit [Quit: CraigBuchek]
mbj has quit [Quit: leaving]
lgierth has quit [Quit: Ex-Chat]
knowtheory has quit [Quit: Computer has gone to sleep]