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.
[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]
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.
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.
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:
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
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