| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
I want to start reducing the calls to `lookup_context`. That method
caches the lookup context in an ivar, but I would like to cache the
lookup context on the stack. That way we aren't coupled to the behavior
of the `lookup_context` method.
|
| |
|
|
|
|
| |
Currently, `ActionView::Base.new` will raise a `NotImplementedError` when given an instance of `ActionView::PathSet` on initialization. This commit prevents the raised error in favor of a deprecation warning.
|
|
|
|
|
| |
We no longer depend on `rendered_format` side effects, so we can remove
this method now. 🎉
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces "rendered template" and "rendered collection"
objects. The template renderers can now return a more complex object
than just strings. This allows the framework to get more information
about the templates that were rendered. In this commit we use the
rendered template object to set the "rendered_format" on the lookup
context in the controller rather than all the way in the template renderer.
That means we don't need to check the "rendered_format" every time we
render a template, we just do it once after all templates have been
rendered.
|
|
|
|
|
|
| |
This commit is to remove direct access to the "rendered_format"
attribute on the lookup context. "rendered_format" is an implementation
detail that we shouldn't test directly.
|
| |
|
| |
|
|\
| |
| | |
Pass the template format to the digestor
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit passes the template format to the digestor in order to come
up with a key. Before this commit, the digestor would depend on the
side effect of the template renderer setting the rendered_format on the
lookup context. I would like to remove that mutation, so I've changed
this to pass the template format in to the digestor.
I've introduced a new instance variable that will be alive during a
template render. When the template is being rendered, it pushes the
current template on to a stack, setting `@current_template` to the
template currently being rendered. When the cache helper asks the
digestor for a key, it uses the format of the template currently on the
stack.
|
|\ \
| | |
| | |
| | |
| | | |
y-yagi/show_deprecated_message_instead_of_raise_exception
Show deprecated message instead of raise exception in `compiled_method_container` method
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`compiled_method_container` method
Since #35036, the subclasses of `ActionView::Base` requires
the `compiled_method_container`.
This is incompatible. For example, `web-console` use view class that
subclass of `ActionView::Base`, and does not work it now cause of this.
Actually, since it seems that it is only `ActionView::Base` that
`compiled_method_container` is necessary, modified the condition that
emits a warning.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
Currently `csp_meta_tag` generates `name` attribute only.
However, in libraries like `Material-UI` and `JSS`, expect that the meta tag
that contains the nonce with `property` attribute.
https://material-ui.com/css-in-js/advanced/#how-does-one-implement-csp
https://github.com/cssinjs/jss/blob/master/docs/csp.md
This patch allows `csp_meta_tag` to specify arbitrary options and
allows `nonce` to be passed to those libraries.
|
| |
|
|\
| |
| | |
Cached collections only work if there is one template
|
| |
| |
| |
| |
| | |
Cached collections only work if there is one template. If there are
more than one templates, the caching mechanism doesn't have a key.
|
| |
| |
| |
| | |
https://codeclimate.com/github/rails/rails/pull/35254
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit keeps a stack of lookup contexts on the ActionView::Base
instance. If a format is passed to render, we instantiate a new lookup
context and push it on the stack, that way any child calls to "render"
will use the same format information as the parent. This also isolates
"sibling" calls to render (multiple calls to render in the same
template).
Fixes #35222 #34138
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
| |
This commit exposes all system wide view paths so that we can clear
their caches.
|
|
|
|
|
| |
This commit splits the digest cache from the "details identity" cache.
Now both caches can be managed independently.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Revert "Remove finalizer and configuration"
This reverts commit 9e7b4a3173788ea43b11e74a4d2f69a5f1565daa.
|
| |
|
|
|
|
| |
Then we don't need the extra module.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Now we can throw away the subclass and the generated methods will get
GC'd too
|
|\
| |
| | |
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
```
|
|\ \
| | |
| | |
| | | |
Closes #34975.
|
| | | |
|
|\ \ \
| | | |
| | | | |
Improve regexp of `html_safe_translation_key?`
|
| | |/
| |/|
| | |
| | |
| | |
| | | |
- Use `\z` instead of `$`
- Use character class instead of alternation
- Optimize alternation order
|
|/ /
| |
| |
| |
| | |
If they're not set we'll still fall back to localhost, but this makes it
possible to run the tests against a remote Postgres / Redis / whatever.
|
| |
| |
| |
| | |
Refs: rails/jbuilder#452
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit passes the mutated source to the template handler as a
parameter and deprecates the old handlers. Old handlers required that
templates contain a reference to mutated source code, but we would like
to make template objects "read only". This change lets the template
remain "read only" while still giving template handlers access to the
source code after mutations.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The AV::Base constructor was too complicated, and this commit tightens
up the parameters it will take. At runtime, AV::Base is most commonly
constructed here:
https://github.com/rails/rails/blob/94d54fa4ab641a0ddeb173409cb41cc5becc02a9/actionview/lib/action_view/rendering.rb#L72-L74
This provides an AV::Renderer instance, a hash of assignments, and a
controller instance. Since this is the common case for construction, we
should remove logic from the constructor that handles other cases. This
commit introduces special constructors for those other cases.
Interestingly, most code paths that construct AV::Base "strangely" are
tests.
|