Action Filter vs. Behavior


(Qiang Xue) #1

For 2.0, I am thinking to remove action filters in favor of behaviors. As you know, behaviors can respond to events of their owners. Using this mechanism, it is possible to make a behavior to work like a filter.

Of course, there are still some differences between filters and behaviors. Below are the ones that are not easy or straightforward enough to implement filters using behaviors:

  • Filters’ before and after methods are properly nested.
  • If an inner filter’s before method quits, the outer filters’ after methods still get chance to be executed.

Your opinion is welcome!


(Yii) #2

I was a bit worried that with the new event system (which is great) the filtering features upon certain events would be completely removed. I’m glad to see this.

I’m ok with having behaviors instead of action filters.


(Junior) #3

Hi, Qiang!

Could you please explain or provide more details about what are the intended benefits of removing the feature? Think that it would help ppl giving feedback. (like improve performance, simplify app flow…)

Thanks


(Qiang Xue) #4

My main consideration is to simplify the concepts, removing things that are unnecessary or redundant.

While filters are useful, they should not be limited to actions only. Theoretically, filters can be used in the whole request workflow. With events and behaviors, we can achieve this goal already.


(Alexander Makarov) #5

How would an access control behavior look now?


(Qiang Xue) #6

It will be similar to CAccessControlFilter, except that it needs to attach to the ‘authorize’ event of controller in its init() function.

The controller action work flow will consist of these events: authorize, beforeAction, beforeRender, afterRender, afterAction


(Alexander Makarov) #7

Sounds good.


(Jeroendenhaan) #8

Question: Will you use ouput buffer to force the right order of beforeRender <output> afterRender? That way the events are even triggered if you use echo in the controller action.

Or will these two events only be implemented in the CController::render(), like it is now?


(Egorpromo) #9

Concept behind behavior is very difficult. Why do you need remove simple filters (or so called "events" that rise on certain controller event)? With filters I can do simple and usefull thing: create some filter (filter-class), use some model in this filter and do usefull functionality making use of this model. I can do usefull functionality in needed places:before action execution, after action execution and so on. For example it can be redirection to another page if it is used before action. So it is obvious and I can use one model and one filter-class for all controllers in my project (because I can set one filter for all controllers in the same time via one or two lines of my php code).

When I read documentation I don’t understand that filters are the same behaviors. I think filters are closed to events. So I am confused :blink: when read this post. IMHO: I think if you remove “filters” you make some useless stuff or something bad. :o


(Qiang Xue) #10

We still have ActionFilter base class which you can extend to create your filter classes.

The only thing changed is how you declare the filters in controller. In 1.1, you use filters(), while in 2.0 you use behaviors().


(Egorpromo) #11

Please make good description and documentation what is Event system for. It is many times confused with ‘behaviours’ and ‘filters’. And we can act in your discussions. Thanks!