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.

0 files changed, 0 insertions, 0 deletions