| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now referencing the constant `AbstractController::Rendering`
causes `ActionView::Base` to be loaded, and thus the load hooks for
action_view are run. If that load hook references any part of action
view that then references action controller (such as
`ActionView::TestCase`), the constant `AbstractController::Rendering`
will attempt to be autoloaded and blow up.
With this change, `ActionView::LoadPaths` no longer requires
`ActionView::Base` (which it had no reason to require). There was a
needed class from `AbstractController::Base` in the Rendering module,
which I've moved into its own file so we don't need to load
all of `AbstractController::Base` there.
This commit fixes
https://github.com/rails/rails-controller-testing/issues/21
|
| |
|
| |
|
|
|
|
|
|
| |
rails view directory
CVE-2016-0752
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rails 4.x and earlier didn't support `Mime::Type[:FOO]`, so libraries
that support multiple Rails versions would've had to feature-detect
whether to use `Mime::Type[:FOO]` or `Mime::FOO`.
`Mime[:foo]` has been around for ages to look up registered MIME types
by symbol / extension, though, so libraries and plugins can safely
switch to that without breaking backward- or forward-compatibility.
Note: `Mime::ALL` isn't a real MIME type and isn't registered for lookup
by type or extension, so it's not available as `Mime[:all]`. We use it
internally as a wildcard for `respond_to` negotiation. If you use this
internal constant, continue to reference it with `Mime::ALL`.
Ref. efc6dd550ee49e7e443f9d72785caa0f240def53
|
|
|
|
|
|
|
| |
Just a slight refactor that delegates file sending to the response
object. This gives us the advantage that if a webserver (in the future)
provides a response object that knows how to do accelerated file
serving, it can implement this method.
|
|
|
|
|
| |
We should be asking the mime type method for the mime objects rather
than via const lookup
|
|
|
|
|
| |
everything above metal really doesn't care about setting the content
type, so lets rearrange these methods to be in metal.
|
|
|
|
|
|
|
| |
_set_content_type only does something when there is a request object,
otherwise the return value of _get_content_type is always ignored. This
commit moves everything to the module that has access to the request
object so we'll never to_s unless there is a reason
|
|
|
|
|
|
| |
In this commit, we set the content-type to `text/html` in AbstractController if the `options[:html]` is true so that we don't include ActionView::Rendering into ActionController::Metal to set it properly.
I removed the if `options[:plain]` statement because `AbstractController#rendered_format` returns `Mime::TEXT` by default.
|
|
|
|
|
| |
If the response method is defined, then calling `response` will return a
response.
|
|
|
|
|
|
|
|
|
|
| |
If AV::Rendering is mixed in, then `rendered_format` will be calculated
based on the current `lookup_context`, but calling `_process_format`
will set the `rendered_format` back on to the same lookup context where
we got the information in the first place!
Instead of getting information from an object, then setting the same
information back on to that object, lets just do nothing instead!
|
|
|
|
|
| |
Apparently the AbstractController (whatever "abstract" means) is
expected to work without a request and response.
|
|
|
|
|
| |
`render` is the only possible source for the `plain` option. Pulling
the conditional up to the `render` method removes far away conditionals
|
|
|
|
|
|
| |
We don't need to pass the full hash just to pull one value out. It's
better to just pass the value that the method needs to know about so
that we can abstract it away from "options"
|
| |
|
| |
|
|
|
|
|
|
| |
Fixes internal links, adds examples and set fixed-width fonts.
[ci skip]
|
|
|
|
| |
closes #14125
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Previously, requiring action_view/view_paths did cause an uninitialized
constant error for ENCODING_FLAG, which is defined in action_view.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TLDR: always return an object that responds to the query methods from
request.format, and do not touch Mime::Type[] lookup to avoid bugs.
---
Long version:
The initial issue was about being able to do checks like
request.format.html? for request with an unknown format, where
request.format would be nil.
This is where the issue came from at first in #7837 and #8085
(merged in cba05887dc3b56a46a9fe2779b6b228880b49622), but the
implementation went down the path of adding this to the mime type
lookup logic.
This unfortunately introduced subtle bugs, for instance in the merged
commit a test related to send_file had to be changed to accomodate the
introduction of the NullType.
Later another bug was found in #13064, related to the content-type being
shown as #<Mime::NullType:...> for templates with localized extensions
but no format included. This one was fixed in #13133, merged in
43962d6ec50f918c9970bd3cd4b6ee5c7f7426ed.
Besides that, custom handlers were not receiving the proper template
formats anymore when passing through the rendering process, because of
the NullType addition. That was found while migrating an application
from 3.2 to 4.0 that uses the Markerb gem (a custom handler that
generates both text and html emails from a markdown template).
---
This changes the implementation moving away from returning this null
object from the mime lookup, and still fixes the initial issue where
request.format.zomg? would raise an exception for unknown formats due to
request.format being nil.
|
|\ |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default, variants in the templates will be picked up if a variant is set
and there's a match. The format will be:
app/views/projects/show.html.erb
app/views/projects/show.html+tablet.erb
app/views/projects/show.html+phone.erb
If request.variant = :tablet is set, we'll automatically be rendering the
html+tablet template.
In the controller, we can also tailer to the variants with this syntax:
class ProjectsController < ActionController::Base
def show
respond_to do |format|
format.html do |html|
@stars = @project.stars
html.tablet { @notifications = @project.notifications }
html.phone { @chat_heads = @project.chat_heads }
end
format.js
format.atom
end
end
end
The variant itself is nil by default, but can be set in before filters, like
so:
class ApplicationController < ActionController::Base
before_action do
if request.user_agent =~ /iPad/
request.variant = :tablet
end
end
end
This is modeled loosely on custom mime types, but it's specifically not
intended to be used together. If you're going to make a custom mime type,
you don't need a variant. Variants are for variations on a single mime
types.
|
|
|
|
|
|
|
| |
constant.
`view_assigns` can use the precalculated sets and remove instance
variables without allocating any extra arrays
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The methods:
* #render_to_body
* #render_to_string
* #_normalize_render
Haven't had anything specyfic to ActionView. This was common code which should belong to AbstractController
|
| |
|
|
|
|
| |
This reverts commit 7de994fa215e9f4c2856d85034bc4dd7b65d0c01.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This interface should be use when implementing renderers.
|
|
|
|
| |
This reverts commit 6fe91ec5008838338e54ab8570f7c95ee0cdd8e8.
|
|
|
|
| |
Since all rendering stuff was extracted to AV, the only thing that left was single class with error so file name wasn't relevant anymore
|