| 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.
|
|
|
|
| |
This basically reverts c4d1a4efeec6f0b5b58222993aa0bec85a19b6a8
|
|
|
|
|
|
|
|
|
| |
Don't use remove_method or remove_possible_method just before a new
definition: at best the purpose is unclear, and at worst it creates a
race condition.
Instead, prefer redefine_method when practical, and
silence_redefinition_of_method otherwise.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Allow a default value to be declared for class_attribute
* Convert to using class_attribute default rather than explicit setter
* Removed instance_accessor option by mistake
* False is a valid default value
* Documentation
|
|
|
|
| |
Actually, private methods cannot be called with `self.`, so it's not just redundant, it's a bad habit in Ruby
|
| |
|
| |
|
|\
| |
| | |
Add missing `+` around a some literals.
|
| |
| |
| |
| |
| |
| | |
Mainly around `nil`
[ci skip]
|
|/
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But comments was still kept absolute position. This commit aligns
comments with method definitions for consistency.
|
|
|
|
|
|
| |
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But heredocs was still kept absolute position. This commit aligns
heredocs indentation for consistency.
|
|
|
|
|
|
|
|
| |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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?
|
|\
| |
| |
| | |
Mention that layout can call a Proc [ci skip]
|
|/
|
|
| |
Also document return values for Proc/Symbol arguments
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Before we were changing the state of the lookup_context for the duration
of the with_layout_format block, but since we already know the formats
we can just pass it explicitly.
Related with 8d7ce0f22aee09d20091a4dc58cb379a09d13e26
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit a9d58c77da800bb0052c9bfa432828b02526022c, reversing
changes made to 041c2c879a3c4086ad3aa6d30fed1eede1d53c11.
Reason: The old behavior is how it was working in previous version of
Rails since 4.0.x so it is not safe to backport to a stable branch.
See https://github.com/rails/rails/issues/19626#issuecomment-89862258
and https://github.com/rails/rails/pull/15050#issuecomment-45333449
|
|
|
|
|
|
|
| |
This commit fixes issue #19626
Don't need to check layout conditions if there is no condition
test for parent layout bug fix
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This is an option for to HTML content with a content type of
`text/html`. This rendering option calls `ERB::Util.html_escape`
internally to escape unsafe HTML string, so you will have to mark your
string as html safe if you have any HTML tag in it.
Please see #12374 for more detail.
|
|
|
|
|
|
|
|
| |
This is as an option to render content with a content type of
`text/plain`. This is the preferred option if you are planning to render
a plain text content.
Please see #12374 for more detail.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an option for sending a raw content back to browser. Note that
this rendering option will unset the default content type and does not
include "Content-Type" header back in the response.
You should only use this option if you are expecting the "Content-Type"
header to not be set. More information on "Content-Type" header can be
found on RFC 2616, section 7.2.1.
Please see #12374 for more detail.
|
| |
|
| |
|
| |
|
|
|