-
Notifications
You must be signed in to change notification settings - Fork 21.4k
Commit
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,31 @@ | ||
## Rails 4.0.0 (unreleased) ## | ||
|
||
* Rename all action callbacks from *_filter to *_action to avoid the misconception that these | ||
callbacks are only suited for transforming or halting the response. With the new style, | ||
it's more inviting to use them as they were intended, like setting shared ivars for views. | ||
|
||
Example: | ||
|
||
class PeopleController < ActionController::Base | ||
before_action :set_person, except: [ :index, :new, :create ] | ||
before_action :ensure_permission, only: [ :edit, :update ] | ||
|
||
... | ||
|
||
private | ||
def set_person | ||
@person = current_account.people.find(params[:id]) | ||
end | ||
|
||
def ensure_permission | ||
current_person.change_change?(@person) | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
dhh
via email
Author
Member
|
||
end | ||
end | ||
|
||
The old *_filter methods still work with no deprecation notice. | ||
|
||
*DHH* | ||
|
||
* Add :if / :unless conditions to fragment cache: | ||
|
||
<%= cache @model, if: some_condition(@model) do %> | ||
|
32 comments
on commit 9d62e04
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice one!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing this to action
makes a lot more sense for people learning these things (like me) in understanding that there's a verb going on here (as in :authenticate
as an action). Thanks for this.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dig it. ⚡
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small changes like this is Rails that make it better semantically are what keep me using it. Great change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I miss Merb's before
and after
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the return value (true or false) still control the flow?
It looks more natural for me to expect method with such a name before_action
to raise exception or call some another method like halt!
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
works for me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The return value was taken into account in the early days, but it's been a long time since filters are halted by rendering or redirecting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dhh why not just before :action, :do_something
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Marcelo, because that's terribly ambiguous. before what? before rendering? before :authenticate
"before authenticate"? before_action :authenticate
is much clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like the example in the documentation:
def set_person
@person = current_account.people.find(params[:id])
end
Having a separate method just to set an ivar is an antipattern. I don't want to teach this to less experienced developer.
A much better implementation would be: (although, then it quits being an example for before_action
)
def current_person
@current_person ||= current_account.people.find(params[:id])
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
before_filter did confuse me a little bit at the beginning. Nice change. I was thinking before_do
, after_do
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @dhh, Thanks for your reply. One of the best thinks about rails is it clean and easy to read syntax. For sure _action
is more meaningful than _filter
but both add redundancy to de code. In plain english before :save, :calculate_total
reads much cleaner than before_action :save, :calculate_total
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel 😐 about this. I think it would have been nice if it were called before_action
from the beginning of time but I dunno if you actually get a lot of milage from the principle of least surprise . As someone thats been coding rails for a while I'm going to be like: "WTF is a before_action
!?" If it aint broke, why fix it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not an alias method which inform about the removing version - dont take all the old legacy code with every version. better clean it. too much similar methods also confuses newcomers
alias_deprecated_method 4.1, :old, :new
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@muescha because it is not deprecated at this time. Just introducing a new name. If it's significantly nicer, we'll deprecate the old one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This name makes much more sense! 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
对代码有洁癖
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. +1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think _action
is self-explanatory. It'd be nice though if we had a backport for 3.2.10, just one more thing we need to remember to do for the upgrade. Before you all retaliate I know before_filter
and after_filter
aren't deprecated yet, but most will want to use the new syntax, so moving to _action
will become the norm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MeetDom sorry, no new features are backported to 3.2, only bug fixes. But it should be dead easy to alias the methods before/after filter in your application controller, and start using as before/after action.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good job ,it's more appropriate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
长姿势了:+1
Should that read
current_person.can_change?(@person)
?