Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rails 3: undefined method render_template' for class ActionView::Template' (NameError) #17

Open
galetahub opened this issue Apr 27, 2010 · 11 comments

Comments

@galetahub
Copy link

We need some fix in file "actionview_extension.rb" (http://github.com/brynary/rack-bug/blob/master/lib/rack/bug/panels/templates_panel/actionview_extension.rb)

ActionView::Template now has method "render" and "virtual_path". So please replace file "actionview_extension.rb":

if defined?(ActionView) && defined?(ActionView::Template)
  ActionView::Template.class_eval do

    def render_with_rack_bug(*args, &block)
      Rack::Bug::TemplatesPanel.record(virtual_path) do
        render_without_rack_bug(*args, &block)
      end
    end

    alias_method_chain :render, :rack_bug
  end
end
@lukemelia
Copy link
Contributor

Rails 3 support is not yet in master. Jose Valim's fork has some work in this direction, but we need to figure out how to merge it in such a way that preserves Rails 2 support. Or not.

@lorennorman
Copy link

Hummm, any movement on this? Using Rails 3 in production now and I need my Rack Bug!

@lukemelia
Copy link
Contributor

@lorennorman can you try the rails3 branch on this repo (http://github.com/brynary/rack-bug/tree/rails3)? I think it is mostly working with a test app, but I'm not running Rails 3 in production yet, so it hasn't gotten a real workout.

@lorennorman
Copy link

Yeah, I found that branch and just tried it but it breaks in a bad way.

I'm not really sure what is happening, but the Ruby process spikes to 100% CPU for about 30 seconds, then Rack::Bug renders itself inline to the page with a MASSIVE amount of text under Server Variables for... Warden?

This is my first time troubleshooting middlewares, apologies for not knowing more.

Running rake middleware shows Rack::Bug right between Warden and Sass:
...
use Warden::Manager
use Rack::Bug
use Sass::Plugin::Rack
...

Something I'm doing wrong or should try?

@lukemelia
Copy link
Contributor

sounds like perhaps Warden puts a lot of stuff into the rack env hash. If there is a pattern to the keys that it adds, you could try filtering them out by following the pattern of line 40 of lib/rack/bug/panels/request_variables_panel.rb

If that solves your problem, we can think about how to come up with a cleaner solution.

@lorennorman
Copy link

I can't imagine that this is normal behavior for Warden, the amount of data is enormous! Maybe RackBug is causing it to do something insane.

I'll poke around a bit and see if I can figure out what is going on.

@lorennorman
Copy link

So I was able to get it fairly stabilized by doing these things:

  • filtering "warden" from the server vars

  • filtering "action_controller.instance" from the server vars

  • added Rack::Bug to the middleware chain BEFORE Warden by doing:

    config.middleware.insert_before "Warden::Manager", "Rack::Bug"

Is it common for action_controller.instance to be enormous and to slow things down? I didn't see why I should have to filter it, but it was clearly lagging the DOM widget when I switched to that view due to its immense size, similar to what Warden was doing.

I'm also not totally sure what changing the order of the middlewares is doing, but I'm fairly certain that it helped as the Rails process doesn't spike to 100% CPU for long periods of time anymore.

My problem is that I'd never used Rack::Bug previous to this, so I don't really know what to compare against, but I'd happily fork and publish what I did if I thought I was doing it right and being helpful!

BTW, what's the best way to swap from relying on an external dependency to actually hacking on that dependency locally? I simply cloned Rack::Bug into vendor/gems and changed my Gemfile line from:

gem 'rack-bug', :require => 'rack/bug', :git => 'git://github.com/brynary/rack-bug', :branch => 'rails3'

...to:

gem 'rack-bug', :require => 'rack/bug', :path => 'vendor/gems/rack-bug'

...and manually checked out the rails3 branch in the cloned repo. From there I just added my hack and restarted the server. Good enough in the absence of my own fork, i guess?

Thanks again!
-Loren

@lorennorman
Copy link

Also getting this deprecation warning, not sure if I caused it or if it's Rails 3 generally being unhappy with Rack::Bug

DEPRECATION WARNING: All middlewares in the chaing are active since the laziness was removed from the middleware stack. (called from block in <module:Info> at /Users/lorennorman/.rvm/gems/ruby-1.9.2-preview3@rails3/gems/railties-3.0.0.beta4/lib/rails/info.rb:92)

@pascalbetz
Copy link

Rack Bug does not work for me on Rails 3.0.5 / Ruby 1.8.7. I can click the "toggle Rack Bug" link and from then on all the requests time out or i get a "can not allocate memory" error.
I tried the brynary and the lorennorman rails3 branch.
Any hints?

@XJ4
Copy link

XJ4 commented Jan 3, 2013

Hey @lorennorman , how did you "filtering "warden" from the server vars" please?

@lorennorman
Copy link

@XJ4 This is ancient history, and I don't think I ever got this working terribly well so I'm not endorsing any of this. But to answer your question directly, this is what I was referring to with respect to filtering server vars:
lorennorman@bddb969

Good luck!

Napolskih pushed a commit to Napolskih/rack-bug that referenced this issue May 12, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants