| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
For inform that need to add `erubis` to gemfile.
|
|
|
|
|
|
|
|
|
|
| |
There are some classes inherit from `ActionView::Template::Handlers::Erubis`.
(ex. https://github.com/haml/haml/blob/4.0.7/lib/haml/helpers/safe_erubis_template.rb#L3)
```
Class.new(ActionView::Template::Handlers::Erubis)
# => TypeError: superclass must be a Class (ActiveSupport::Deprecation::DeprecatedConstantProxy given)
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Erubi offers the following advantages for Rails:
* Works with ruby's --enable-frozen-string-literal option
* Has 88% smaller memory footprint
* Does no freedom patching (Erubis adds a method to Kernel)
* Has simpler internals (1 file, <150 lines of code)
* Has an open development model (Erubis doesn't have a
public source control repository or bug tracker)
* Is not dead (Erubis hasn't been updated since 2011)
Erubi is a simplified fork of Erubis that contains just the
parts that are generally needed (which includes the parts
that Rails uses). The only intentional difference in
behavior is that it does not include support for <%=== tags
for debug output. That could be added to the ActionView ERB
handler if it is desired.
The Erubis template handler remains in a deprecated state
so that code that accesses it directly does not break. It
can be removed after Rails 5.1.
|
|
|
|
| |
(I personally prefer writing one string in one line no matter how long it is, though)
|
| |
|
|
|
|
|
|
| |
Regexp#match? should be considered to be part of the Ruby core library. We are
emulating it for < 2.4, but not having to require the extension is part of the
illusion of the emulation.
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
| |
Where appropriate, prefer the more concise Regexp#match?,
String#include?, String#start_with?, or String#end_with?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In PR #24929 the changelog was updated to make note that while the new
template handler was changed to raw this changed the behavior when
outputting plain html or js files. Previously ERB would output the files
unescaped. Changing the default handler to RAW meant that these same
files would be rendered as escaped rather than as js or html.
Because of this change in behavior and after the discussion #24949 in we
decided to change the behavior of the Raw handler to output html_safe
strings by default.
Now files rendered with the default handler (raw) render the file
unescaped.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having collection caching that wraps templates and automatically tries
to infer if they are cachable proved to be too much of a hassle.
We'd rather have it be something you explicitly turn on.
This removes much of the code and docs to explain the previous automatic
behavior.
This change also removes scoped cache keys and passing cache_options.
|
| |
|
|
|
|
|
|
|
| |
This fixes the case when you try to render an html you know safe and the
file is named something.html. With this commit the content of the html
won't be escaped anymore because AV won't use Raw handler and choose
Html handler instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a template includes `# Template Collection: ...` anywhere in its
source, that name will be used as the cache name for the partial that is
rendered for the collection.
This allows users to enable collection caching even if the template
doesn't start with `<% cache ... do %>`.
Moreover, the `# Template Collection: ...` notation is recognized in all
template types (and template types other than ERB can define a
resource_cache_call_pattern method to allow the `cache ... do` pattern
to be recognized too).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The regular expression which was used to detect partial templates that
begin with a `<% cache ... do %>` call missed some cases. This commits
attempts to improve the detection for some cases such as multi-line
comments at the beginning of the template. The different templates are
listed in two new unit test methods.
Note that specially crafted Ruby code can still evade such `cache`-call
detection: for example, a user might have its own method which itself
calls the Rails `cache` helper. In such a case, the template's code
doesn't start with a literal `cache` string and therefore will not be
eligible for collection caching.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://github.com/ruby/ruby/pull/579 - there is a new optimization
since ruby 2.2
Previously regexp patterns were faster (since a string was converted to
regexp underneath anyway). But now string patterns are faster and
better reflect the purpose.
Benchmark.ips do |bm|
bm.report('regexp') { 'this is ::a random string'.gsub(/::/, '/') }
bm.report('string') { 'this is ::a random string'.gsub('::', '/') }
bm.compare!
end
# string: 753724.4 i/s
# regexp: 501443.1 i/s - 1.50x slower
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Collections can take advantage of `multi_read` if they render one template
and their partials begin with a cache call.
The cache call must correspond to either what the collections elements are
rendered as, or match the inferred name of the partial.
So with a notifications/_notification.html.erb template like:
```ruby
<% cache notification %>
<%# ... %>
<% end %>
```
A collection would be able to use `multi_read` if rendered like:
```ruby
<%= render @notifications %>
<%= render partial: 'notifications/notification', collection: @notifications, as: :notification %>
```
|
|
|
|
| |
Now ActionView accepts <%= foo(){ %> and <%= foo()do %> :golf:
|
| |
|
|
|
|
|
| |
This is much less common than string literal appends, so add a special
case method for it. Maybe fixes bug reported by @jeremy on 97ef636191933f1d4abc92fc10871e6d1195285c
|
| |
|
| |
|
|
|