beforeRender and afterRender

In Yii 1.1, we have beforeRender and afterRender in CController. I’m wondering what do you use them for. Could you please elaborate how these become useful in your project? I need this information to determine whether or not we should support them in 2.0, or perhaps come up with a better solution. Thanks.

Personally, I have not used beforeRender nor [color=#1C2837][size=2]afterRender[/size][/color] my projects.

[font=Arial, sans-serif][size=2]I`ve used it as part of the communication betweenmodules.[/size][/font][size=3][/size]

[font=Arial, sans-serif][size=2] [/size][/font]

[font=Arial, sans-serif][size=2]Use case:[/size][/font]

[font=Arial, sans-serif][size=2]I’ve developed a user module which allows to maintain a user’sprofile. The only user fields this module provides in the ‘edit profile’ vieware the username, email, name and photo.[/size][/font]

[font=Arial, sans-serif][size=2]I’ve also developed a ‘social’ module which uses the afterRender event toadd more fields to the ‘Edit profile’ view.[/size][/font]

[font=Arial, sans-serif][size=2] [/size][/font]

[font=Arial, sans-serif][size=2]Within the ‘update’ action I’ve created a new event which is called after the default fields are saved. This allows to save the additional fields[/size][/font]

Sending customized headers could be another use case, especially when using Yii as an API framework but that could also be done using filters I guess

Personally I’ve never used it. That’s what I was able to find:

I am using it fairly often. :)

That’s probably because I come from CakePHP…

What is the alternative?

I used only beforeRender() to set meta tags.

I have seen samdark’s links. However I am curious. What other use case scenario are you using beforeRender / afterRender() ?


How exactly?

I am using it to perform tasks before the render phase.

It’s really convenient.

It’s easier than setting up a filter.

However, I can live with it being removed.

It was added in 2010.

And it has some flaws, because render is not guaranteed to be called - renderPartial and a simple echo are examples of that.

So, if it means that I need to add a filter to my base controller, I’m fine with it. ;)

I think it was used because there was no proper beforeAction event, just a method.

D’oh - I always mix those two functions up! :)

Yeah, with beforeAction, I really can’t think of any use for beforeRender.

I don’t recall having used [before,after]Render(). But I’d like to say the following:

  • I don’t mind keeping them. But if it’s a huge performance issue (which I doubt) I wouldn’t defend them till death. If removed and chaos ensues, they can always be added back later on I presume.

  • Assuming they’re kept, please add events for them, so that we can create behaviors that support them. I once reported Issue 2400 where I couldn’t do a clean solution (behavior) due to lack of events for these two methods.

  • Out of the three people (aside core devs) involved in that issue, 100% wanted events to be added for these methods. One of the best things about Yii is that it is pretty flexible. A part of that is naturally the event system, but it’s useless without events for key methods/actions.


IMHO I rather use beforeAction than beforeRender… I have never used that to be honest, and I cannot see any good reason to use it instead of other solutions

beforeRender should go because it is not guaranteed to be called anyway…

It’s just confusing and cluttering up the core.

I use afterRender() allot, mainly to register scripts and css files for the current controller/action.

This happens mainly because in the current Yii, you need to register most of the JS/CSS files from within the layout file(it has no use to do it in controller when you use themes because various themes use various assets), then, if you register new files from within the controller action will screw up the order of the scripts being rendered, and i found that the solution to avoid this issue is to register the scripts in afterRender().

Another solution for my problem would be to create a general behavior that would read a config file from the theme and will register the assets found in that file, but it seems overkill for this.

Anyway, bottom line, do not remove these methods, they are useful.

Can you rephrase that? I’m not sure I understand what you mean. It seems you are saying that unless everyone uses beforeRender() (i.e. it being “guaranteed” to be called under all circumstances) it should be removed. Presumably that is not what you meant :)

I don’t see what is confusing about it. beforeAction() is run before the requested action method is called, and beforeRender() is naturally called after the/any render() call in the action, but before the rendering is actually done. Seems straight forward to me.

Hi all,

well I’ve found an interesting case where I just needed it, but remembered the question you had asked months ago, before relying upon it. However, it’s not so trivial to discard it, let me explain: in the flow of work AFTER the massive assignation, we try to save a model, and afterwards either redirect or render, usually depending on whether there was a validation error when trying to save (or reviewing the $model->errors, or the $model->hasErrors(), there are several ways to do it). But let’s focus on the situation where there was an error, and one of your model attributes deserves a special attention, which you had already treated when the action begun, but BEFORE the massive assignment.

In such a case, if the user CHANGED the value of such attribute, but the $model->save() method generated an error, then the $POST value containing the new value will either reset the previous treatment, or the new value will be ignored (for example, if the treatment was saved in a variable, independently of the massive assignment).

Such error-proof situation can be solved with the beforeRender method, and is a place reserved for that matter.

There are, however, for the programmer using Yii, some alternative methods to achieve the same result, and the last one, which will be considered obvious after stating it, is not obvious when first facing the problem:

  1. Something like defining a callback function according to the case, and then call it with any available data what ever it might be in the moment of the call, might solve the problem

  2. Defining a method in the controller, such method will be in charge of the treatment, and drawing the control of the treated data in the view layer, for example in _form.php. The _form.php will include just a one-line statement calling that controller method, so the method will be called already in the rendering. Nonetheless, its simplicity (one line) will not harm to the pure nature of the view layer more than the usual php calling for example the CHtml class static functions.

Conclusion: although it might be replaced by other ways to solve the problem I met, thinking ahead that it might be eliminated, I discarded its usage and found other solutions which up to the same problem, seem to be as effective and harmless for the view. BUT the cost was that I had to call a controller function in a view file.

Suggested readings for newcomers in order to understand what I mean: you can read What is massive assignment

I hope it was useful,

best regards from Bogotá, Colombia,

David López

Investigación y Programación SAS

before/afterRender doesnt have much logic in it. If user needs such methods he can easily override the render methods in his own custom Controller.php he then extends.

I am totally for not cluttering code with methods that in reality dont get much use. Sure they make a good impression in Tutorials/Video but in real world we want lean codebase.

never used before/afterRender. Don’t even see how they are better than before/afterAction