| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
respond_with (and consequently the class-level respond_to)
are being removed from Rails. Instead of moving it to a 3rd
library, the functionality will be moved to responders gem
(at github.com/plataformatec/responders) which already provides
some responders extensions.
|
| | |
|
| |
|
|
| |
defined (just like any other variant)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow setting `request.variant` as an array - an order in which they will be
rendered.
For example:
request.variant = [:tablet, :phone]
respond_to do |format|
format.html.none
format.html.phone # this gets rendered
end
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like `format.any`, you can do the same with variants.
It works for both inline:
respond_to do |format|
format.html.any { render text: "any" }
format.html.phone { render text: "phone" }
end
and block syntax:
respond_to do |format|
format.html do |variant|
variant.any(:tablet, :phablet){ render text: "any" }
variant.phone { render text: "phone" }
end
end
|
| |
|
|
|
|
|
|
|
|
|
| |
* Added release notes for secrets.yml and mentioned it in the highlights
* Added release notes for Mailer previews and mentioned it in the highlights
* Added release notes for Module#concerning
* Removed mention for AV extraction from the highlights
* Rearranged the major features to put highlighted features first
* Various improvements and typo fixes
[ci skip]
|
| |
|
|
|
|
| |
* Extend method documentation
* Mention it in actionpack/CHANGELOG
* Update release notes
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In most cases, when setting variant specific code, you're not sharing any code
within format.
Inline syntax can vastly simplify defining variants in those situations:
respond_to do |format|
format.js { render "trash" }
format.html do |variant|
variant.phone { redirect_to progress_path }
variant.none { render "trash" }
end
end
Becomes:
respond_to do |format|
format.js { render "trash" }
format.html.phone { redirect_to progress_path }
format.html.none { render "trash" }
end
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
@responses hash needs to be initialized with mime types that we get from
Collector#collect_mimes_from_class_level. Mime::Type class as key and nil as
value. This need to happen before content negotiation. Before that, it was
looping though mime types and executing mime-type-generated method inside
collector (see
AbstractController::Collector#generate_method_for_mime). That approach resulted
in 2 unnecessary method calls for each mime type
collected by Collector#collect_mimes_from_class_level.
Now hash is initialized in place, without usage of Collector#custom method.
|
| |
|
|
|
|
|
| |
little more work!
This reverts commit 186161148a189839a1e0924043f068a8d155ce69, reversing
changes made to cad9eb178ea5eec0e27d74e93518f4ed34e2f997.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In most cases, when setting variant specific code, you're not sharing any code
within format.
Inline syntax can vastly simplify defining variants in those sitiations:
respond_to do |format|
format.js { render "trash" }
format.html do |variant|
variant.phone { redirect_to progress_path }
variant.none { render "trash" }
end
end
`
Becomes:
respond_to do |format|
format.js { render "trash" }
format.html.phone { redirect_to progress_path }
format.html.none { render "trash" }
end
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
@responses hash needs to be initialized with mime types that we get from
Collector#collect_mimes_from_class_level. Mime::Type class as key and nil as
value. This need to happen before content negotiation. Before that, it was
looping though mime types and executing mime-type-generated method inside
collector (see
AbstractController::Collector#generate_method_for_mime). That approach resulted
in 2 unnecessary method calls for each mime type
collected by Collector#collect_mimes_from_class_level.
Now hash is initialized in place, without usage of Collector#custom method.
|
| |
|
|
| |
controller
|
| | |
|
| |
|
|
|
| |
Avoid one-liner conditionals when they are too big. Avoid concatenating
strings to build error messages. Improve messages a bit.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
atom_feed_helper_test.rb to fail with "SystemStackError: stack level too deep".
This reverts commit d3a1ce1cdc60d593de1682c5f4e3230c8db9a0fd.
|
| |\
| |
| | |
Used Yield instead of block.call
|
| | | |
|
| |/
|
|
| |
Ruby 1.8 legacy. Since 1.9 hash preserves insertion order. No need for additional array to achieve this
|
| |
|
|
|
|
|
|
| |
This fixes an issue where the respond_with worked directly with the given
options hash, so that if a user relied on it after calling respond_with,
the hash wouldn't be the same.
Fixes #12029
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Conflicts:
guides/source/getting_started.md
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by Active Support)
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
- #respond_to's documentation refer to .respond_to, but it was
written as just <respond_to>. Added class name for clarification.
|
| | |
|
| | |
|
| |
|
|
| |
format, rather than responding with a head :not_acceptable (406)
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |\ |
|
| | | | |
|
| | |/
|/| |
|
| |/ |
|
| | |
|
