I don't see the need for a :uniq option, when you can use :only
and :except on the before_filter and skip_before_filter flavors...
I think of it as way to remove the burden from the programmer to
think about whether or not the filter was already present in the
inheritance chain or not.
Specially when you have multiple plugins interacting and setting
filters, it can get messy.
Also, we can make a parallel to alias_method_chain, think of a filter
as a simpler form of:
alias_method_chain :perform_action, :filter_name
In that case, the chain would never be aliased twice.
Maybe you are seeing deficiencies in your controller designs as
flaws in the filter setup? Perhaps you just need to refactor your
controllers and use skip and :only/:except more liberally?
I don't know. I'm just thinking of the common use case, and looking
back I see many times where I had filters that needed to run only
once, but could run twice, and no filter at all that I needed to rerun.
Do you have any cases where you needed a filter to run more than once?
I'm not saying it's completely useless, just that it's improbable and
that most developers don't consider this when setting up filters.
Also, I think expecitly specifying that you want a filter to rerun is
very little work, and may even aid readability.
Least surprise and all that.
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
