Introduce a file type template

[tenderlove]

Every template that specifies a "virtual path" loses the template source
when the template gets compiled:

rails/actionview/lib/action_view/template.rb

Line 275 in eda0f57

@source = nil if @virtual_path

The "refresh" method seems to think that the source code for a template
can be recovered if there is a virtual path:

rails/actionview/lib/action_view/template.rb

Lines 171 to 188 in eda0f57

	# Receives a view object and return a template similar to self by using @virtual_path.
	#
	# This method is useful if you have a template object but it does not contain its source
	# anymore since it was already compiled. In such cases, all you need to do is to call
	# refresh passing in the view object.
	#
	# Notice this method raises an error if the template to be refreshed does not have a
	# virtual path set (true just for inline templates).
	def refresh(view)
	raise "A template needs to have a virtual path in order to be refreshed" unless @virtual_path
	lookup = view.lookup_context
	pieces = @virtual_path.split("/")
	name = pieces.pop
	partial = !!name.sub!(/^_/, "")
	lookup.disable_cache do
	lookup.find_template(name, [ pieces.join("/") ], partial, @locals)
	end
	end

Every call site that allocates a template object and provides a
"virtual path" reads the template contents from the filesystem:

rails/actionview/lib/action_view/template/resolver.rb

Lines 229 to 231 in eda0f57

	contents = File.binread(template)
	Template.new(contents, File.expand_path(template), handler,

Templates that are inline or literals don't provide a "virtual path":

rails/actionview/lib/action_view/renderer/template_renderer.rb

Line 34 in eda0f57

Template.new(options[:inline], "inline template", handler, locals: keys)

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:

rails/actionview/lib/action_view/testing/resolvers.rb

Line 53 in eda0f57

[ActionView::Template.new("Template generated by Null Resolver", path.virtual, handler, virtual_path: path.virtual, format: format, variant: variant)]

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.

[rafaelfranca]

What is the plan to this class? We will always have a LegacyTemplate or we plan to remove it some day?

[tenderlove]

I think we can remove it eventually. I want to change this call to pass in the view and the source. But for backwards compatibility we need to pass an object that has a reference to the mutated source.

I'll follow up with another commit that deprecates arity one blocks

[tenderlove]

I changed this to not deprecate refresh. I think we might be able to deprecate and remove it in the future, but right now it's not clear. In test, we have a custom resolver that instantiates template objects that have a view path, but aren't associated with a file:

rails/actionview/lib/action_view/testing/resolvers.rb

Lines 26 to 47 in 2169bd3

	def query(path, exts, _, _)
	query = +""
	EXTENSIONS.each_key do |ext|
	query << "(" << exts[ext].map { |e| e && Regexp.escape(".#{e}") }.join("|") << "|)"
	end
	query = /^(#{Regexp.escape(path)})#{query}$/
	templates = []
	@hash.each do |_path, array|
	source, updated_at = array
	next unless query.match?(_path)
	handler, format, variant = extract_handler_and_format_and_variant(_path)
	templates << Template.new(source, _path, handler,
	virtual_path: path.virtual,
	format: format,
	variant: variant,
	updated_at: updated_at
	)
	end
	templates.sort_by { |t| -t.identifier.match(/^#{query}$/).captures.reject(&:blank?).size }
	end

After this PR, the common case will be to instantiate FileTemplate objects, so I just implemented a refresh on FileTemplate that returns itself (since it can get the source).

[rafaelfranca]

I changed this to not deprecate refresh. I think we might be able to deprecate and remove it in the future, but right now it's not clear. In test, we have a custom resolver that instantiates template objects that have a view path

Ah right. This is something we support and José's book talk about it in the "Retrieving View Templates from Custom Stores" chapter https://pragprog.com/book/jvrails2/crafting-rails-4-applications

[morgoth]

While upgrading to Rails 6.0 I'm getting warning:

DEPRECATION WARNING: Single arity template handlers are deprecated.  Template handlers must
now accept two parameters, the view object and the source for the view object.
Change:
  >> Class#call(template)
To:
  >> Class#call(template, source)
 (called from <top (required)> at /home/wojtek/Projects/some_project/config/environment.rb:5)

which is not really clear where to find it. I suspect some gem, as I don't mess with templates in the app.
Do you have a clue how to track it?

[Sun-Mountain]

While upgrading to Rails 6.0 I'm getting warning:

DEPRECATION WARNING: Single arity template handlers are deprecated.  Template handlers must
now accept two parameters, the view object and the source for the view object.
Change:
  >> Class#call(template)
To:
  >> Class#call(template, source)
 (called from <top (required)> at /home/wojtek/Projects/some_project/config/environment.rb:5)

which is not really clear where to find it. I suspect some gem, as I don't mess with templates in the app.
Do you have a clue how to track it?

I have the same question. I am now updating our rails app and getting the same message but cannot find anywhere this might affect our app. (We also do not use templates outside of the devise gem.)

[eugeneius]

Setting config.active_support.deprecation = :raise in config/environments/development.rb and trying to run the application will give you a backtrace that includes the line that's causing the problem. It's most likely due to an older version of the jbuilder or coffee-script gems.

I think the code that tries to extract the culprit from the backtrace could be doing a better job here.