Ryan Sandridge's Profile

Nevermind. I found where the recursion was happening...

I added the following to development.rb:

config.assets.compile=true

Have you tried calling #build as you mention? That seemingly innocent change somehow sends me into an infinite recursive loop; that is to say, link_to_add_fields gets called over and over again. I can't imagine how building the new object through the association would have this side effect. Here is the line of code before the change:

new_object = f.object.class.reflect_on_association(association).klass.new

after:

f.object.send(association).build

Any ideas?

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.

See https://github.com/pokonski/public_activity/issues/62 for workarounds.

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.

get 'auth/:provider/callback', to: 'sessions#create'
get 'auth/failure', to: redirect('/')
get 'signout', to: 'sessions#destroy', as: 'signout'

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.