Earlier quoted context omitted.
Here's another version that doesn't even use private methods in the controller and uses a PORO for the email grouping: https://gist.github.com/dhh/9333991
I can't seem to find it on Google. What's a PORO?
[deleted]
Rails – The Missing Parts
81–90 of 173 posts
Re: Rails – The Missing Parts
#82Earlier quoted context omitted.
Here's another version that doesn't even use private methods in the controller and uses a PORO for the email grouping: https://gist.github.com/dhh/9333991
I can't seem to find it on Google. What's a PORO?
Never seen the term used before, but by analogy to POJO and POCO it would have to be a "Plain Old Ruby Object".
Re: Rails – The Missing Parts
#83Re: Rails – The Missing Parts
#84Re: Rails – The Missing Parts
#85Earlier quoted context omitted.
If reassigning a case is part of the domain, it belongs in the model. I don't know how to put this gently, but this concoction looks like a hot mess with no separation between modeling and controlling. These commands have a ton of domain logic all tangled up with activity reporting, formatting, and parameter parsing. It looks like a big ball of mud to me :(
Perhaps that's why the OP used a simple example. Complex examples are pretty hard to get your head around at first glance; even sane systems can be perceived as a 'hot mess' upon a quick read without any context. I disagree that re-assigning a case belongs in the case model. It is a complex interaction between several models. Extracting it to a command object allows all of the rules to be easily understood.
I feel like showing off some tests would help when the example is this complex. That would give a bit more context in terms of what you're trying to accomplish here.
Re: Rails – The Missing Parts
#86Earlier quoted context omitted.
Here's another version that doesn't even use private methods in the controller and uses a PORO for the email grouping: https://gist.github.com/dhh/9333991
Thanks for writing this. While I often look for ways to take external-interaction-responsibility away from Rails objects, the OP didn't really make sense to me, at least in terms of saving time and making things more logical. However, there's a distinction that has to be made in your example and the OP's. In the OP, the failure of the Interactor, including the delivery of emails , would cause the controller to enter…
The failure of delivery of emails should be handled gracefully such as within a message queue that gets retried until it succeeds or dies.
Re: Rails – The Missing Parts
#87A good litmus test of an experienced Rails developer is how large their /lib directories are in relation to project sizes.
Is a large /lib a sign of experience or inexperience? I try to keep as much as possible out of /lib and moved into gems.
Inexperience. lib/ quickly turns into a dumping ground unless you are careful to keep it clear of business logic.
Re: Rails – The Missing Parts
#88Earlier quoted context omitted.
Sure - I don't think anyone in the Rails world is claiming to have invented these principles. The problem is that Rails ships with a very limited set of core architectural concepts, and many inexperienced Rails developers feel like they've got to cram all of their code into a Model, View or Controller. Once your codebase reaches a certain complexity, principles from other programming paradigms are extremely useful.
Interactors, domain objects, service objects, etc. are still models; people just don't generally believe that their models are allowed to inherit from things other than ActiveRecord::Base.
I keep looking at interactors and thinking "I'd make this a command object and then hide it in the model" - so I'd be doing something like (inside the 'member' class)
method confirm_grouper () {
MyApp::Action::ConfirmGrouper->new(leader => $self)
->run
}
my $result = $member->confirm_grouper;Re: Rails – The Missing Parts
#89Earlier quoted context omitted.
If you need a gem to implement some of these complementary patterns, you're doing it wrong. Draper, Naught, DisplayCase and all of the other gems of patterns are over abstraction 99% of the time. Implement the pattern yourself. Most of these Presenter and Service object patterns are different variations of the Decorator pattern. Ruby happens to ship with 3 great ways to implement decorators: SimpleDelegator (my perso…
The biggest pain points that gems like Draper solve are allowing view helpers in your decorators (which is by no means straightforward when you get into routing helpers), and dealing with some of the strangeness that you get into by wrapping ActiveRecord models (JSON serialization was a biggie for us). It's less about what Ruby gives you, and more about navigating around some of the darker, messier corners of Rails.
They just wrapped the view_context with a method_missing proxy (another form of a Decorator) that the controller instance gives you. You can accomplish the same very easily using dependency injection in your controller action:
MassivelyUpVotedPostPresenter.new(@post, self.view_context)
Or just inject the whole controller instance and you have your router helpers too!
MassivelyUpVotedPostPresenter.new(@post, self)
Re: Rails – The Missing Parts
#90Earlier quoted context omitted.
If reassigning a case is part of the domain, it belongs in the model. I don't know how to put this gently, but this concoction looks like a hot mess with no separation between modeling and controlling. These commands have a ton of domain logic all tangled up with activity reporting, formatting, and parameter parsing. It looks like a big ball of mud to me :(
Perhaps that's why the OP used a simple example. Complex examples are pretty hard to get your head around at first glance; even sane systems can be perceived as a 'hot mess' upon a quick read without any context. I disagree that re-assigning a case belongs in the case model. It is a complex interaction between several models. Extracting it to a command object allows all of the rules to be easily understood.
[deleted]