It doesn't appear that include PublicActivity::Common works in the current release of the gem, so not sure how this appeared to work in the episode without using a pre-release version of the gem.
FYI... Rails 4 deprecates match routes. As far as I can tell, replacing "match" with "get" in config/routes.rb makes this episode Rails 4 friendly. Maybe that is obvious, but I was surprised the 'auth/:provider/callback' route wasn't a POST.
config/routes.rb
get 'auth/:provider/callback', to:'sessions#create'
get 'auth/failure', to: redirect('/')
get 'signout', to:'sessions#destroy', as:'signout'
I'm curious why you don't feel the controller should know about Presenters? It seems to me the one thing controllers and presenters have in common, is they both have knowledge of both the model and the view.
I need to look more into the subtle differences between presenters and decorators... maybe understanding that will help me understand why you think the presenters should be instantiated in the view.
It doesn't appear that
include PublicActivity::Commonworks in the current release of the gem, so not sure how this appeared to work in the episode without using a pre-release version of the gem.See https://github.com/pokonski/public_activity/issues/62 for workarounds.
FYI... Rails 4 deprecates
matchroutes. As far as I can tell, replacing "match" with "get" in config/routes.rb makes this episode Rails 4 friendly. Maybe that is obvious, but I was surprised the'auth/:provider/callback'route wasn't a POST.I wouldn't mind seeing a Revised Railscast on this episode, that included passing arguments to rake tasks.
I'm curious why you don't feel the controller should know about Presenters? It seems to me the one thing controllers and presenters have in common, is they both have knowledge of both the model and the view.
I need to look more into the subtle differences between presenters and decorators... maybe understanding that will help me understand why you think the presenters should be instantiated in the view.