I've definitely had a need for more improved around and after filters.
If an action is cached, any after or around filters will not execute
as processing is basically halted after the cached page is served.
It would be nice to have filters that are guaranteed to run regardless
of whatever happens during the execution of the action.
Is this something that you would be addressing with your improvements?
On 7/2/06, Martin Emde <[EMAIL PROTECTED]> wrote:
Hello all,
I've been working with the action_controller filter
code lately and I've noticed a lot of code repetition and a
lot of room for improvement without breaking existing filter usage. I plan
on submitting a patch that would clean this all up and add a few additional
features.
The main goal I am going for with the filter code is enabling "true" around
filters: A filter method that may run whatever it wants before or after the
action, including running the action within a block. This becomes incredibly
useful when you talk about something like this:
def filter(controller)
if session_user?
Data.with_scope( :find => { :conditions => ["user_id = ?",
controller.session[:user_id] ] } ) do
yield # this runs the action (or subsequent filters) making sure that
all finds for Data require that the use is an owner.
end
With this sort of syntax for filters, you can completely drop the idea of
"before filters" and "after filters." With scoping this easily lends itself
to the simplified CRUD controllers mentioned by DHH in his keynote speech at
RailsConf by keeping the controllers simple.
I think that filters and their supporting methods should be scoped out of
the controller. Adding a bunch of methods to the
controller that aren't actions and don't
assist actions isn't very clean:
I picture one of thefollowing uses being the most useful.
add_filter :filter => ProjectScope.new, :except => [:list,:index]
class ProjectScope
def filter(controller)
Project.with_scope( ..etc.. )
yield
end
end
end
add_filter :filter => :project_scope, :except => [:list, :index]
def project_scope
yield
# this way drops the clean filter scope in favor of
the simplicity of using controller methods.
end
I would also like to enable an add_filter call, passing a block, but the
only way to allow that method to use yield is to instance_eval (any input on
that would be good)
What I want from this list, if I could, is some opinions on things you wish
filters did. Anything you think would simplify filters, etc.
Something that would be cool is to define the types of filter usage and just
cater to each type of usage. We already have 'verify' which is just a
before_filter that checks things like params and request.method. Maybe we
can think of a way to express any other
usages that are comon, providing a simple
way to do the most comon filters. Right now I can think of
these cases. Please add any you can think of.
* validate or restrict access based on session
* scope or limit access based on params
* setup variables for usage in the actions or views.
* run methods that are called every time a action is called
* update record keeping objects
Sorry for the super long mail. I appreciate any input.
-Marty
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
