Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support symbol and string actions in AC#respond_to options #3289

Merged
merged 1 commit into from
Oct 11, 2011
Merged

Support symbol and string actions in AC#respond_to options #3289

merged 1 commit into from
Oct 11, 2011

Conversation

avakhov
Copy link
Contributor

@avakhov avakhov commented Oct 11, 2011

class HomeController < ApplicationController
  before_filter :some, :only => [:aaa, 'bbb'] # Works well
  respond_to :xml, :only => [:aaa, 'bbb']     # <-- Should also work

  def aaa
    respond_with :aaa => 3
  end

  def bbb
    respond_with :bbb => 3
  end

  private
  def some
    # ...
  end
end

josevalim added a commit that referenced this pull request Oct 11, 2011
Support symbol and string actions in AC#respond_to options
@josevalim josevalim merged commit 7b84e36 into rails:master Oct 11, 2011
jrochkind added a commit to samvera/browse-everything that referenced this pull request Nov 19, 2018
A Rails app is generated with a sass-rails dependency, so no changes to tests were needed -- the engine-cart-generated test app adds it's own sass-rails dependency.

While current Rails releases generate with sass-rails dependency, sass-rails is sunsetted/deprecated, due to the underlying pure-ruby ruby-sass gem being deprecated, and instructs "consider switching to the sassc gem"  https://github.com/sass/ruby-sass .

Rails 6.0 will perhaps depend on the sassc-rails gem instead, or perhaps the sass-rails gem itself will be changed to depend on sassc instead of sass-ruby. I am not sure if it is yet determined/done. rails/rails#3289

But apps now may wish to switch to sassc-rails, especially if it's a new app. While sassc-rails _ought_ to be a drop-in replacement, bugs can happen, and the timeline of switching (or refraining from switching) should be up to a dependent app.  However, if an app depends on both sass-rails and sassc-rails, problems can occur. sass/sassc-rails#6

So, removing the sass-rails as an explicit dependency from browse-everything will allow dependent apps to choose sass-rails or sassc-rails themselves, switching on their own timeline, without the browse-everything dependency interfering. This change is unlikely to pose any backwards compatibility problems, as dependent apps should have sass-rails in their Gemfile already, as it is generated by Rails. In the unlikely event some dependent app did not have sass-rails independently declared as a dependency, however, they would have to add it."
jrochkind added a commit to samvera/browse-everything that referenced this pull request Nov 19, 2018
A Rails app is generated with a sass-rails dependency, so no changes to tests were needed -- the engine-cart-generated test app adds it's own sass-rails dependency.

While current Rails releases generate with sass-rails dependency, sass-rails is sunsetted/deprecated, due to the underlying pure-ruby ruby-sass gem being deprecated, and instructs "consider switching to the sassc gem"  https://github.com/sass/ruby-sass .

Rails 6.0 will perhaps depend on the sassc-rails gem instead, or perhaps the sass-rails gem itself will be changed to depend on sassc instead of sass-ruby. I am not sure if it is yet determined/done. rails/rails#3289

But apps now may wish to switch to sassc-rails, especially if it's a new app. While sassc-rails _ought_ to be a drop-in replacement, bugs can happen, and the timeline of switching (or refraining from switching) should be up to a dependent app.  However, if an app depends on both sass-rails and sassc-rails, problems can occur. sass/sassc-rails#6

So, removing the sass-rails as an explicit dependency from browse-everything will allow dependent apps to choose sass-rails or sassc-rails themselves, switching on their own timeline, without the browse-everything dependency interfering. This change is unlikely to pose any backwards compatibility problems, as dependent apps should have sass-rails in their Gemfile already, as it is generated by Rails. In the unlikely event some dependent app did not have sass-rails independently declared as a dependency, however, they would have to add it."
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants