Permalink
Browse files

Removed config.action_view.cache_template_loading, use config.cache_c…

…lasses instead
  • Loading branch information...
1 parent 5cc3ea6 commit 83e29b9773ac113ceacb1e36c2f333d692de2573 @josh josh committed Jul 16, 2008
View
@@ -1,5 +1,7 @@
*Edge*
+* Removed config.action_view.cache_template_loading, use config.cache_classes instead [Josh Peek]
+
* Get buffer for fragment cache from template's @output_buffer [Josh Peek]
* Set config.action_view.warn_cache_misses = true to receive a warning if you perform an action that results in an expensive disk operation that could be cached [Josh Peek]
@@ -171,9 +171,10 @@ class << self
delegate :erb_trim_mode=, :to => 'ActionView::TemplateHandlers::ERB'
end
- # Specify whether templates should be cached. Otherwise the file we be read everytime it is accessed.
- @@cache_template_loading = false
- cattr_accessor :cache_template_loading
+ def self.cache_template_loading=(*args)
+ ActiveSupport::Deprecation.warn("config.action_view.cache_template_loading option has been deprecated and has no affect. " <<
+ "Please remove it from your config files.", caller)
+ end
def self.cache_template_extensions=(*args)
ActiveSupport::Deprecation.warn("config.action_view.cache_template_extensions option has been deprecated and has no affect. " <<
@@ -16,6 +16,14 @@ def self.type_cast(obj)
end
class Path #:nodoc:
+ def self.eager_load_templates!
+ @eager_load_templates = true
+ end
+
+ def self.eager_load_templates?
+ @eager_load_templates || false
+ end
+
attr_reader :path, :paths
delegate :to_s, :to_str, :inspect, :to => :path
@@ -37,6 +45,9 @@ def reload!
@paths = {}
templates_in_path do |template|
+ # Eager load memoized methods and freeze cached template
+ template.freeze if self.class.eager_load_templates?
+
@paths[template.path] = template
@paths[template.path_without_extension] ||= template
end
@@ -48,10 +59,7 @@ def reload!
def templates_in_path
(Dir.glob("#{@path}/**/*/**") | Dir.glob("#{@path}/**")).each do |file|
unless File.directory?(file)
- template = Template.new(file.split("#{self}/").last, self)
- # Eager load memoized methods and freeze cached template
- template.freeze if Base.cache_template_loading
- yield template
+ yield Template.new(file.split("#{self}/").last, self)
end
end
end
@@ -72,7 +72,7 @@ def #{render_symbol}(local_assigns)
# if local_assigns has a new key, which isn't supported by the compiled code yet.
def recompile?(symbol)
meth = Base::CompiledTemplates.instance_method(template.method) rescue nil
- !(meth && Base.cache_template_loading)
+ !(meth && frozen?)
end
end
end
@@ -22,7 +22,6 @@
ActionController::Base.logger = nil
ActionController::Routing::Routes.reload rescue nil
-ActionView::Base.cache_template_loading = true
FIXTURE_LOAD_PATH = File.join(File.dirname(__FILE__), 'fixtures')
ActionController::Base.view_paths = FIXTURE_LOAD_PATH
@@ -10,7 +10,6 @@
# Full error reports are disabled and caching is turned on
config.action_controller.consider_all_requests_local = false
config.action_controller.perform_caching = true
-config.action_view.cache_template_loading = true
# Use a different cache store in production
# config.cache_store = :mem_cache_store
@@ -414,6 +414,7 @@ def initialize_framework_logging
# paths have already been set, it is not changed, otherwise it is
# set to use Configuration#view_path.
def initialize_framework_views
+ ActionView::PathSet::Path.eager_load_templates! if configuration.cache_classes
ActionMailer::Base.template_root ||= configuration.view_path if configuration.frameworks.include?(:action_mailer)
ActionController::Base.view_paths = [configuration.view_path] if configuration.frameworks.include?(:action_controller) && ActionController::Base.view_paths.empty?
end
@@ -1,6 +1,5 @@
require 'action_controller/performance_test'
ActionController::Base.perform_caching = true
-ActionView::Base.cache_template_loading = true
ActiveSupport::Dependencies.mechanism = :require
Rails.logger.level = ActiveSupport::BufferedLogger::INFO

17 comments on commit 83e29b9

so, as of this commit, is there no longer a way to have view code recompile without recompiling classes as well?

Owner

jeremy replied Dec 12, 2008

You could turn off ActionView::PathSet::Path.eager_load_templates by hand.

This was so rarely used that it because configuration noise.

Contributor

eric1234 replied Dec 30, 2008

I’m surprised at this also! I know Rails tries to encourage best practices so I don’t mind that the templates do not reload by default because best practices dictate you should only update production templates via a deployment system like Capistrano that will restart the application when done with the template update.

But not everybody lives in that ideal world. I work with a lot of people coming from the static HTML and PHP world where they are used to being able to make simple text changes on the production server and not need a “professional” to make every text change. They assume the risk associated with this style of development to save on costs. Restarting the application after every text change is out of their league also as they are not comfortable with the command line (they update the files via FTP manually). Obviously Rails should encourage people away from this style of development but I have always found it useful that this style of development was possible. I don’t even mind changing a config value to enable it.

This change (6 months old but not all of us live on the edge) now means that if I choose to allow this style of development I am also punished into having ALL of my classes reload on every request! Old versions of Rails where smart enough to check timestamps and only reload what needs to be reloaded. I consider this a step backwards.

Just my two cents.

Member

josh replied Dec 30, 2008

eric I kind of want that functionality back too, but its a bit more difficult now

PID :)

Member

NZKoz replied Dec 30, 2008

I believe he means PDI ;)

anyway, you can use passenger and just touch tmp/restart.txt in the meantime, it’s not some huge ordeal like restarting a monit-managed mongrel-farm

Owner

dhh replied Dec 30, 2008

I’d like this back as well. It’s very useful when restarting your app is expensive. Say when you’re dealing with 200 req/sec in prime time and your visitors would feel slowdown if everything was bounced.

Contributor

eric1234 replied Dec 30, 2008

@josh, I don’t understand why it would be so difficult to restore the functionality.

Seems to me that we could just add “config.action_view.cache_template_loading” back. If true (the default to encourage best practices) then updates to templates do not affect the running application. If false then it would still cache the compiled template (for performance) but prior to running it, a quick check of the template’s last modified time-stamp would be done. If the template is newer than the cached value in memory then invalidate the cache and re-compile the template. Otherwise just use the compiled template already in memory.

So developer have a choice of “super-fast but inflexible (and if you are using standard deployment techniques this inflexibility won’t get in your way)” or “fast (since only changed templates are re-processed) but flexible”.

Member

josh replied Dec 30, 2008

@eric You make it sound so easy :)

If you can make a patch, I’d be happy to apply it.

Contributor

csmuc replied Feb 3, 2009

Another vote for bringing this back. The need for a full restart is just too painful for small changes on the views and reduces the overall availability of the app. At least this is my experience.

Member

lifo replied Feb 3, 2009

I think we all agree it should be back. So at this point, we probably need a patch and not only votes :)

Contributor

alloy replied Feb 3, 2009

+1 lifo ;)

Contributor

thedarkone replied Feb 3, 2009

I have this exact “timestamping-on-change-reloading-templates” implemented in my fork of rails-dev-boost (the plugin patches a few things to get production like speeds in dev mode).

It is implemented against Rails 2.2 APIs though… I’ll have a look how portable it is for the 2.3 branch.

akia replied Feb 4, 2009

+1 for bringing this back :)

Contributor

thedarkone replied Feb 4, 2009

I updated the plugin to be compatible with Rails 2.3.

The implementation is obviously not thread safe… after all I only care about the speedy development mode.

Owner

pixeltrix replied Feb 8, 2009

Patch for bringing it back:
http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1909

Comments appreciated!

Why was this removed? This really increases my development time. I have a programmer who only modifies erb code and this is super annoying to have requests that take 3-4 seconds. Please reconsider adding this back in 3.1.

Contributor

josevalim replied Aug 13, 2011

It is already in 3.1

Please sign in to comment.