[qiang]

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!

[Rodrigo Coelho]

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 - df9]

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]

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.

[samdark]

How would an access control behavior look now?

[qiang]

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

[samdark]

Sounds good.

[yJeroen]

qiang, on 03 May 2012 - 01:28 PM, said:

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

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?