1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
rails--rails/actionview/lib/action_view/template.rb

390 lines
14 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
require "thread"
Introduce a file type template, deprecate `Template#refresh` Every template that specifies a "virtual path" loses the template source when the template gets compiled: https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/template.rb#L275 The "refresh" method seems to think that the source code for a template can be recovered if there is a virtual path: https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/template.rb#L171-L188 Every call site that allocates a template object *and* provides a "virtual path" reads the template contents from the filesystem: https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/template/resolver.rb#L229-L231 Templates that are inline or literals don't provide a "virtual path": https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/renderer/template_renderer.rb#L34 This commit introduces a `FileTemplate` type that subclasses `Template`. The `FileTemplate` keeps a reference to the filename, and reads the source from the filesystem. This effectively makes the template source immutable. Other classes depended on the source to be mutated while being compiled, so this commit also introduces a temporary way to pass the mutated source to the ERB (or whatever) compiler. See `LegacyTemplate`. I think we should consider it an error to provide a virtual path on a non file type template an non-file templates can't recover their source. Here is an example: https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/testing/resolvers.rb#L53 This provides a "virtual path" so the source code (a string literal) is thrown away after compilation. Clearly we can't recover that string, so I think this should be an error.
2019-01-31 18:34:09 -05:00
require "delegate"
2009-04-14 20:22:51 -04:00
module ActionView
# = Action View Template
class Template
extend ActiveSupport::Autoload
2009-12-22 18:27:37 -05:00
def self.finalize_compiled_template_methods
ActiveSupport::Deprecation.warn "ActionView::Template.finalize_compiled_template_methods is deprecated and has no effect"
end
def self.finalize_compiled_template_methods=(_)
ActiveSupport::Deprecation.warn "ActionView::Template.finalize_compiled_template_methods= is deprecated and has no effect"
end
# === Encodings in ActionView::Template
#
# ActionView::Template is one of a few sources of potential
# encoding issues in Rails. This is because the source for
# templates are usually read from disk, and Ruby (like most
# encoding-aware programming languages) assumes that the
# String retrieved through File IO is encoded in the
# <tt>default_external</tt> encoding. In Rails, the default
# <tt>default_external</tt> encoding is UTF-8.
#
# As a result, if a user saves their template as ISO-8859-1
# (for instance, using a non-Unicode-aware text editor),
# and uses characters outside of the ASCII range, their
# users will see diamonds with question marks in them in
# the browser.
#
# For the rest of this documentation, when we say "UTF-8",
# we mean "UTF-8 or whatever the default_internal encoding
# is set to". By default, it will be UTF-8.
#
# To mitigate this problem, we use a few strategies:
# 1. If the source is not valid UTF-8, we raise an exception
# when the template is compiled to alert the user
# to the problem.
# 2. The user can specify the encoding using Ruby-style
# encoding comments in any template engine. If such
# a comment is supplied, Rails will apply that encoding
# to the resulting compiled source returned by the
# template handler.
# 3. In all cases, we transcode the resulting String to
# the UTF-8.
#
# This means that other parts of Rails can always assume
# that templates are encoded in UTF-8, even if the original
# source of the template was not UTF-8.
#
# From a user's perspective, the easiest thing to do is
# to save your templates as UTF-8. If you do this, you
# do not need to do anything else for things to "just work".
#
# === Instructions for template handlers
#
# The easiest thing for you to do is to simply ignore
# encodings. Rails will hand you the template source
# as the default_internal (generally UTF-8), raising
# an exception for the user before sending the template
# to you if it could not determine the original encoding.
#
# For the greatest simplicity, you can support only
# UTF-8 as the <tt>default_internal</tt>. This means
# that from the perspective of your handler, the
# entire pipeline is just UTF-8.
#
# === Advanced: Handlers with alternate metadata sources
#
# If you want to provide an alternate mechanism for
# specifying encodings (like ERB does via <%# encoding: ... %>),
# you may indicate that you will handle encodings yourself
# by implementing <tt>handles_encoding?</tt> on your handler.
#
# If you do, Rails will not try to encode the String
# into the default_internal, passing you the unaltered
# bytes tagged with the assumed encoding (from
# default_external).
#
# In this case, make sure you return a String from
# your handler encoded in the default_internal. Since
# you are handling out-of-band metadata, you are
# also responsible for alerting the user to any
# problems with converting the user's data to
# the <tt>default_internal</tt>.
#
2013-01-26 11:36:38 -05:00
# To do so, simply raise +WrongEncodingError+ as follows:
#
# raise WrongEncodingError.new(
# problematic_string,
# expected_encoding
# )
2015-02-18 14:40:58 -05:00
##
# :method: local_assigns
#
# Returns a hash with the defined local variables.
#
# Given this sub template rendering:
#
# <%= render "shared/header", { headline: "Welcome", person: person } %>
#
# You can use +local_assigns+ in the sub templates to access the local variables:
#
# local_assigns[:headline] # => "Welcome"
2009-12-22 18:27:37 -05:00
eager_autoload do
autoload :Error
2019-04-01 19:29:03 -04:00
autoload :RawFile
2009-12-22 18:27:37 -05:00
autoload :Handlers
autoload :HTML
autoload :Inline
autoload :Sources
2009-12-22 18:27:37 -05:00
autoload :Text
autoload :Types
2009-12-22 18:27:37 -05:00
end
extend Template::Handlers
attr_reader :identifier, :handler, :original_encoding, :updated_at
attr_reader :variable, :format, :variant, :locals, :virtual_path
Speed up partial rendering by caching "variable" calculation This commit speeds up rendering partials by caching the variable name calculation on the template. The variable name is based on the "virtual path" used for looking up the template. The same virtual path information lives on the template, so we can just ask the cached template object for the variable. This benchmark takes a couple files, so I'll cat them below: ``` [aaron@TC ~/g/r/actionview (speed-up-partials)]$ cat render_benchmark.rb require "benchmark/ips" require "action_view" require "action_pack" require "action_controller" class TestController < ActionController::Base end TestController.view_paths = [File.expand_path("test/benchmarks")] controller_view = TestController.new.view_context result = Benchmark.ips do |x| x.report("render") do controller_view.render("many_partials") end end [aaron@TC ~/g/r/actionview (speed-up-partials)]$ cat test/benchmarks/test/_many_partials.html.erb Looping: <ul> <% 100.times do |i| %> <%= render partial: "list_item", locals: { i: i } %> <% end %> </ul> [aaron@TC ~/g/r/actionview (speed-up-partials)]$ cat test/benchmarks/test/_list_item.html.erb <li>Number: <%= i %></li> ``` Benchmark results (master): ``` [aaron@TC ~/g/r/actionview (master)]$ be ruby render_benchmark.rb Warming up -------------------------------------- render 41.000 i/100ms Calculating ------------------------------------- render 424.269 (± 3.5%) i/s - 2.132k in 5.031455s ``` Benchmark results (this branch): ``` [aaron@TC ~/g/r/actionview (speed-up-partials)]$ be ruby render_benchmark.rb Warming up -------------------------------------- render 50.000 i/100ms Calculating ------------------------------------- render 521.862 (± 3.8%) i/s - 2.650k in 5.085885s ```
2019-02-05 18:07:55 -05:00
def initialize(source, identifier, handler, format: nil, variant: nil, locals: nil, virtual_path: nil, updated_at: nil)
unless locals
ActiveSupport::Deprecation.warn "ActionView::Template#initialize requires a locals parameter"
locals = []
end
@source = source
@identifier = identifier
@handler = handler
@compiled = false
@locals = locals
@virtual_path = virtual_path
Speed up partial rendering by caching "variable" calculation This commit speeds up rendering partials by caching the variable name calculation on the template. The variable name is based on the "virtual path" used for looking up the template. The same virtual path information lives on the template, so we can just ask the cached template object for the variable. This benchmark takes a couple files, so I'll cat them below: ``` [aaron@TC ~/g/r/actionview (speed-up-partials)]$ cat render_benchmark.rb require "benchmark/ips" require "action_view" require "action_pack" require "action_controller" class TestController < ActionController::Base end TestController.view_paths = [File.expand_path("test/benchmarks")] controller_view = TestController.new.view_context result = Benchmark.ips do |x| x.report("render") do controller_view.render("many_partials") end end [aaron@TC ~/g/r/actionview (speed-up-partials)]$ cat test/benchmarks/test/_many_partials.html.erb Looping: <ul> <% 100.times do |i| %> <%= render partial: "list_item", locals: { i: i } %> <% end %> </ul> [aaron@TC ~/g/r/actionview (speed-up-partials)]$ cat test/benchmarks/test/_list_item.html.erb <li>Number: <%= i %></li> ``` Benchmark results (master): ``` [aaron@TC ~/g/r/actionview (master)]$ be ruby render_benchmark.rb Warming up -------------------------------------- render 41.000 i/100ms Calculating ------------------------------------- render 424.269 (± 3.5%) i/s - 2.132k in 5.031455s ``` Benchmark results (this branch): ``` [aaron@TC ~/g/r/actionview (speed-up-partials)]$ be ruby render_benchmark.rb Warming up -------------------------------------- render 50.000 i/100ms Calculating ------------------------------------- render 521.862 (± 3.8%) i/s - 2.650k in 5.085885s ```
2019-02-05 18:07:55 -05:00
@variable = if @virtual_path
base = @virtual_path.end_with?("/") ? "" : ::File.basename(@virtual_path)
Speed up partial rendering by caching "variable" calculation This commit speeds up rendering partials by caching the variable name calculation on the template. The variable name is based on the "virtual path" used for looking up the template. The same virtual path information lives on the template, so we can just ask the cached template object for the variable. This benchmark takes a couple files, so I'll cat them below: ``` [aaron@TC ~/g/r/actionview (speed-up-partials)]$ cat render_benchmark.rb require "benchmark/ips" require "action_view" require "action_pack" require "action_controller" class TestController < ActionController::Base end TestController.view_paths = [File.expand_path("test/benchmarks")] controller_view = TestController.new.view_context result = Benchmark.ips do |x| x.report("render") do controller_view.render("many_partials") end end [aaron@TC ~/g/r/actionview (speed-up-partials)]$ cat test/benchmarks/test/_many_partials.html.erb Looping: <ul> <% 100.times do |i| %> <%= render partial: "list_item", locals: { i: i } %> <% end %> </ul> [aaron@TC ~/g/r/actionview (speed-up-partials)]$ cat test/benchmarks/test/_list_item.html.erb <li>Number: <%= i %></li> ``` Benchmark results (master): ``` [aaron@TC ~/g/r/actionview (master)]$ be ruby render_benchmark.rb Warming up -------------------------------------- render 41.000 i/100ms Calculating ------------------------------------- render 424.269 (± 3.5%) i/s - 2.132k in 5.031455s ``` Benchmark results (this branch): ``` [aaron@TC ~/g/r/actionview (speed-up-partials)]$ be ruby render_benchmark.rb Warming up -------------------------------------- render 50.000 i/100ms Calculating ------------------------------------- render 521.862 (± 3.8%) i/s - 2.650k in 5.085885s ```
2019-02-05 18:07:55 -05:00
base =~ /\A_?(.*?)(?:\.\w+)*\z/
$1.to_sym
end
if updated_at
ActiveSupport::Deprecation.warn "ActionView::Template#updated_at is deprecated"
@updated_at = updated_at
else
@updated_at = Time.now
end
@format = format
@variant = variant
@compile_mutex = Mutex.new
2009-04-14 20:22:51 -04:00
end
deprecate :original_encoding
deprecate :updated_at
deprecate def virtual_path=(_); end
deprecate def locals=(_); end
deprecate def formats=(_); end
deprecate def formats; Array(format); end
deprecate def variants=(_); end
deprecate def variants; [variant]; end
2019-04-04 15:48:52 -04:00
deprecate def refresh(_); self; end
# Returns whether the underlying handler supports streaming. If so,
# a streaming buffer *may* be passed when it starts rendering.
def supports_streaming?
handler.respond_to?(:supports_streaming?) && handler.supports_streaming?
end
2010-10-09 17:56:08 -04:00
# Render a template. If the template was not compiled yet, it is done
# exactly before rendering.
#
# This method is instrumented as "!render_template.action_view". Notice that
# we use a bang in this instrumentation because you don't want to
# consume this in production. This is only slow if it's being listened to.
Ensure cache fragment digests include all templates A Rails view may rely on several templates (e.g. layouts and partials) in addition to the template for the action being rendered (e.g. "show.html.erb"). To track which view file is currently being rendered for the purpose of generating template tree digests used in cache fragment keys, Action View uses a stack, the top item of which is accessed via the @current_template variable (introduced in 1581cab). Consider the following template: <!-- home.html.erb --> <%= render layout: "wrapper" do %> <%= cache "foo" %> HOME <%= end %> <%= end %> Inside the block passed to the render helper, @current_template corresponds to the wrapper.html.erb template instead of home.html.erb. As wrapper.html.erb is then used as the root node for generating the template tree digest used in the cache fragment key, the cache fragment fails to expire upon changes to home.html.erb. Additionally, should a second template use the wrapper.html.erb layout and contain a cache fragment with the same key, the cache fragment keys for both templates will be identical - causing cached content to "leak" from one view to another (as described in #38984). This commit skips adding templates to the stack when rendered as a layout with a block via the render helper, ensuring correct and unique cache fragment digests. Additionally, the virtual_path keyword arguments found in CacheHelper and all references to the are removed as they no longer possess any function. (Following the introduction of @current_template, virtual_path is accessed via @current_template.virtual_path rather than as a standalone variable.)
2020-04-24 17:29:00 -04:00
def render(view, locals, buffer = ActionView::OutputBuffer.new, add_to_stack: true, &block)
instrument_render_template do
compile!(view)
Ensure cache fragment digests include all templates A Rails view may rely on several templates (e.g. layouts and partials) in addition to the template for the action being rendered (e.g. "show.html.erb"). To track which view file is currently being rendered for the purpose of generating template tree digests used in cache fragment keys, Action View uses a stack, the top item of which is accessed via the @current_template variable (introduced in 1581cab). Consider the following template: <!-- home.html.erb --> <%= render layout: "wrapper" do %> <%= cache "foo" %> HOME <%= end %> <%= end %> Inside the block passed to the render helper, @current_template corresponds to the wrapper.html.erb template instead of home.html.erb. As wrapper.html.erb is then used as the root node for generating the template tree digest used in the cache fragment key, the cache fragment fails to expire upon changes to home.html.erb. Additionally, should a second template use the wrapper.html.erb layout and contain a cache fragment with the same key, the cache fragment keys for both templates will be identical - causing cached content to "leak" from one view to another (as described in #38984). This commit skips adding templates to the stack when rendered as a layout with a block via the render helper, ensuring correct and unique cache fragment digests. Additionally, the virtual_path keyword arguments found in CacheHelper and all references to the are removed as they no longer possess any function. (Following the introduction of @current_template, virtual_path is accessed via @current_template.virtual_path rather than as a standalone variable.)
2020-04-24 17:29:00 -04:00
view._run(method_name, self, locals, buffer, add_to_stack: add_to_stack, &block)
end
rescue => e
2010-10-09 17:56:08 -04:00
handle_render_error(view, e)
end
def type
@type ||= Types[format]
end
def short_identifier
@short_identifier ||= defined?(Rails.root) ? identifier.delete_prefix("#{Rails.root}/") : identifier
end
def inspect
"#<#{self.class.name} #{short_identifier} locals=#{@locals.inspect}>"
end
def source
@source.to_s
end
2011-12-20 06:39:28 -05:00
# This method is responsible for properly setting the encoding of the
2011-12-20 05:06:37 -05:00
# source. Until this point, we assume that the source is BINARY data.
# If no additional information is supplied, we assume the encoding is
# the same as <tt>Encoding.default_external</tt>.
#
# The user can also specify the encoding via a comment on the first
# line of the template (# encoding: NAME-OF-ENCODING). This will work
# with any template engine, as we process out the encoding comment
# before passing the source on to the template engine, leaving a
# blank line in its stead.
def encode!
2019-01-31 17:06:21 -05:00
source = self.source
return source unless source.encoding == Encoding::BINARY
2011-12-20 06:39:28 -05:00
# Look for # encoding: *. If we find one, we'll encode the
# String in that encoding, otherwise, we'll use the
# default external encoding.
if source.sub!(/\A#{ENCODING_FLAG}/, "")
2011-12-20 06:39:28 -05:00
encoding = magic_encoding = $1
else
encoding = Encoding.default_external
end
2011-12-20 05:06:37 -05:00
2011-12-20 06:39:28 -05:00
# Tag the source with the default external encoding
# or the encoding specified in the file
source.force_encoding(encoding)
# If the user didn't specify an encoding, and the handler
# handles encodings, we simply pass the String as is to
# the handler (with the default_external tag)
if !magic_encoding && @handler.respond_to?(:handles_encoding?) && @handler.handles_encoding?
source
# Otherwise, if the String is valid in the encoding,
# encode immediately to default_internal. This means
# that if a handler doesn't handle encodings, it will
# always get Strings in the default_internal
elsif source.valid_encoding?
source.encode!
# Otherwise, since the String is invalid in the encoding
# specified, raise an exception
else
raise WrongEncodingError.new(source, encoding)
2011-12-20 05:06:37 -05:00
end
end
# Exceptions are marshalled when using the parallel test runner with DRb, so we need
# to ensure that references to the template object can be marshalled as well. This means forgoing
# the marshalling of the compiler mutex and instantiating that again on unmarshalling.
def marshal_dump # :nodoc:
[ @source, @identifier, @handler, @compiled, @locals, @virtual_path, @updated_at, @format, @variant ]
end
def marshal_load(array) # :nodoc:
@source, @identifier, @handler, @compiled, @locals, @virtual_path, @updated_at, @format, @variant = *array
@compile_mutex = Mutex.new
end
private
2010-10-09 17:56:08 -04:00
# Compile a template. This method ensures a template is compiled
# just once and removes the source after it is compiled.
def compile!(view)
2010-10-09 17:56:08 -04:00
return if @compiled
# Templates can be used concurrently in threaded environments
# so compilation and any instance variable modification must
# be synchronized
@compile_mutex.synchronize do
# Any thread holding this lock will be compiling the template needed
# by the threads waiting. So re-check the @compiled flag to avoid
# re-compilation
return if @compiled
mod = view.compiled_method_container
2013-05-03 08:28:16 -04:00
instrument("!compile_template") do
2014-08-27 20:59:34 -04:00
compile(mod)
2013-05-03 08:28:16 -04:00
end
@compiled = true
2010-10-09 17:56:08 -04:00
end
end
Introduce a file type template, deprecate `Template#refresh` Every template that specifies a "virtual path" loses the template source when the template gets compiled: https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/template.rb#L275 The "refresh" method seems to think that the source code for a template can be recovered if there is a virtual path: https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/template.rb#L171-L188 Every call site that allocates a template object *and* provides a "virtual path" reads the template contents from the filesystem: https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/template/resolver.rb#L229-L231 Templates that are inline or literals don't provide a "virtual path": https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/renderer/template_renderer.rb#L34 This commit introduces a `FileTemplate` type that subclasses `Template`. The `FileTemplate` keeps a reference to the filename, and reads the source from the filesystem. This effectively makes the template source immutable. Other classes depended on the source to be mutated while being compiled, so this commit also introduces a temporary way to pass the mutated source to the ERB (or whatever) compiler. See `LegacyTemplate`. I think we should consider it an error to provide a virtual path on a non file type template an non-file templates can't recover their source. Here is an example: https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/testing/resolvers.rb#L53 This provides a "virtual path" so the source code (a string literal) is thrown away after compilation. Clearly we can't recover that string, so I think this should be an error.
2019-01-31 18:34:09 -05:00
class LegacyTemplate < DelegateClass(Template) # :nodoc:
attr_reader :source
def initialize(template, source)
super(template)
@source = source
end
end
# Among other things, this method is responsible for properly setting
2011-12-20 05:06:37 -05:00
# the encoding of the compiled template.
#
# If the template engine handles encodings, we send the encoded
# String to the engine without further processing. This allows
# the template engine to support additional mechanisms for
# specifying the encoding. For instance, ERB supports <%# encoding: %>
#
# Otherwise, after we figure out the correct encoding, we then
# encode the source into <tt>Encoding.default_internal</tt>.
# In general, this means that templates will be UTF-8 inside of Rails,
# regardless of the original source encoding.
def compile(mod)
2019-01-31 17:06:21 -05:00
source = encode!
code = @handler.call(self, source)
2013-06-07 16:43:06 -04:00
# Make sure that the resulting String to be eval'd is in the
# encoding of the code
2019-02-17 23:07:16 -05:00
original_source = source
source = +<<-end_src
def #{method_name}(local_assigns, output_buffer)
2019-01-16 20:39:42 -05:00
@virtual_path = #{@virtual_path.inspect};#{locals_code};#{code}
end
end_src
# Make sure the source is in the encoding of the returned code
source.force_encoding(code.encoding)
# In case we get back a String from a handler that is not in
# BINARY or the default_internal, encode it to the default_internal
source.encode!
# Now, validate that the source we got back from the template
# handler is valid in the default_internal. This is for handlers
# that handle encoding but screw up
unless source.valid_encoding?
2019-01-31 17:06:21 -05:00
raise WrongEncodingError.new(source, Encoding.default_internal)
end
2019-02-17 23:07:16 -05:00
begin
mod.module_eval(source, identifier, 0)
2019-02-17 23:07:16 -05:00
rescue SyntaxError
# Account for when code in the template is not syntactically valid; e.g. if we're using
# ERB and the user writes <%= foo( %>, attempting to call a helper `foo` and interpolate
# the result into the template, but missing an end parenthesis.
raise SyntaxErrorInTemplate.new(self, original_source)
end
end
def handle_render_error(view, e)
2010-10-09 17:56:08 -04:00
if e.is_a?(Template::Error)
e.sub_template_of(self)
raise e
else
raise Template::Error.new(self)
end
end
def locals_code
# Only locals with valid variable names get set directly. Others will
# still be available in local_assigns.
locals = @locals - Module::RUBY_RESERVED_KEYWORDS
locals = locals.grep(/\A@?(?![A-Z0-9])(?:[[:alnum:]_]|[^\0-\177])+\z/)
# Assign for the same variable is to suppress unused variable warning
locals.each_with_object(+"") { |key, code| code << "#{key} = local_assigns[:#{key}]; #{key} = #{key};" }
2010-10-09 17:56:08 -04:00
end
def method_name
2014-10-07 06:59:58 -04:00
@method_name ||= begin
m = +"_#{identifier_method_name}__#{@identifier.hash}_#{__id__}"
m.tr!("-", "_")
2014-10-07 06:59:58 -04:00
m
end
end
def identifier_method_name
short_identifier.tr("^a-z_", "_")
end
2013-05-03 08:28:16 -04:00
def instrument(action, &block) # :doc:
ActiveSupport::Notifications.instrument("#{action}.action_view", instrument_payload, &block)
end
def instrument_render_template(&block)
ActiveSupport::Notifications.instrument("!render_template.action_view", instrument_payload, &block)
end
def instrument_payload
{ virtual_path: @virtual_path, identifier: @identifier }
2013-05-03 08:28:16 -04:00
end
end
end