Sign in through GitHub

Please read for an updated status on RailsCasts:

Learn more or hide this

Ryan Sandridge's Profile

GitHub User: dissolved

Comments by Ryan Sandridge

Avatar

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

Avatar

I added the following to development.rb:

config.assets.compile=true
Avatar

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?

Avatar

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.

Avatar

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'
Avatar

I wouldn't mind seeing a Revised Railscast on this episode, that included passing arguments to rake tasks.

Avatar

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.