This project is archived and is in readonly mode.

Rails 3.0.1 - config.action_view.cache_template_loading is missing

#5847

In Rails 2.3 we could set config.action_view.cache_template_loading to decide if we want cache view templates or not.

In Rails 3 there is no such setting available.

Current implementation /actionpack-3.0.1/lib/action_view/template/resolver.rb :

def caching?
  @caching ||= !defined?(Rails.application) || Rails.application.config.cache_classes
end

Temporary workaround:

# Rails.app/config/environments/env_name.rb
AppName::Application.configure do
  # Settings specified here will take precedence over those in config/environment.rb

  # In the development environment your application's code is reloaded on
  # every request.  This slows down response time but is perfect for development
  # since you don't have to restart the webserver when you make code changes.

  config.cache_classes = true

  .
  .
  .

end

ActiveSupport.on_load(:after_initialize) do
  ActionView::Resolver.class_eval do
    def caching?
      false
    end
  end
end

Reported by Robert Pankowecki · October 20th, 2010 @ 12:15 PM

Activity

Eric
The workaround is a little harsh. It seems to recompile the template each time it is executed. This means that in a loop the template could be re-compiled hundreds of times make it really slow. The following workaround gives me the same result although I am thinking it is likely not thread-safe:
```
ActiveSupport.on_load(:after_initialize) do
  ActionController::Base.before_filter do
    ActionController::Base.view_paths.each(&:clear_cache)
  end
end
```
With the above solution I am clearing the cache at the start of each request but within the request the cache is used.
December 13th, 2010 @ 10:51 PM
José Valim
- Assigned user set to Piotr Sarnacki
- Importance changed from to Low
In Rails master (or 3.1), the first hack (which sets caching to false) would be better because it would just recompile the template if it actually changed in the filesystem. But yeah, we could probably bring the option we had on 2.3.x back.

December 14th, 2010 @ 10:03 AM
Eric
I'm not sure if that is actually what is happening. I have a view which has lots of partials in a recursive loop so each partial gets called many times. With the first hack it was taking 6-7 seconds to render the view. When I ran the request in ruby-prof I believe I saw the same partial recompiled multiple times within the same request.

With my newer hack (clear the cache before the request) the time to render that view got reduced to about 1-1.5 seconds.

December 14th, 2010 @ 03:24 PM
Repository
- State changed from new to resolved
(from [e89fff2f6b815529cf729fc8e900a8275c9514e8]) Bring back config.action_view.cache_template_loading [#5847 state:resolved] https://github.com/rails/rails/commit/e89fff2f6b815529cf729fc8e900a...

December 16th, 2010 @ 09:27 PM
Robert Pankowecki
Thank you for bringing back this feature. The tests are really well done.

December 18th, 2010 @ 07:58 AM
Piotr Sarnacki
Robert: Thanks!

Although the patch is already applied, I will look into Eric's issue with clearing view paths cache, maybe it could be cleared by default in dev mode.

December 18th, 2010 @ 08:39 AM
José Valim
Piotr, for Rails 3.0 we never cache the template in development, his hack was for production. In Rails 3.1, the template is always cached, but if config.action_view.cache_template_loading is false, we check if the template was changed in the filesystem before serving it.

December 18th, 2010 @ 08:43 AM
Piotr Sarnacki
José Valim: thanks for clarification!

December 18th, 2010 @ 09:07 AM
bingbing
louis vuitton watches

March 26th, 2011 @ 02:12 AM
rubyconvict
I checked in 3.0.5 and 3.0.7, and this code is not implemented. I have the problem with BrowserCMS for R3 where I need page template/partial reloading on production env. Thanks to Eric, I had it solved.

By the way, hi Robert, your old buddy from Cubi, Marcin here :-)

May 12th, 2011 @ 11:11 AM
José Valim
This is surely on rails 3.1.

May 12th, 2011 @ 11:38 AM
Robert Pankowecki
@rubyconvict - Nice to hear from you again, Marcin. As you can see, we still encounter same bugs, even when working for new companies and in different cities.

May 12th, 2011 @ 10:02 PM